Inconsistent script/console behaviour

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Inconsistent script/console behaviour

anatoly techtonik
Currently if you work in console and define a function and then
immediately call it - it will fail with SyntaxError.
For example, copy paste this completely valid Python script into console:

def some():
  print "XXX"
some()

There is an issue for that that was just closed by Eric. However, I'd
like to know if there are people here that agree that if you paste a
valid Python script into console - it should work without changes.
--
anatoly t.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

Guido van Rossum
On Fri, Sep 23, 2011 at 4:25 PM, anatoly techtonik <[hidden email]> wrote:

> Currently if you work in console and define a function and then
> immediately call it - it will fail with SyntaxError.
> For example, copy paste this completely valid Python script into console:
>
> def some():
>  print "XXX"
> some()
>
> There is an issue for that that was just closed by Eric. However, I'd
> like to know if there are people here that agree that if you paste a
> valid Python script into console - it should work without changes.

You can't fix this without completely changing the way the interactive
console treats blank lines. None that it's not just that a blank line
is required after a function definition -- you also *can't* have a
blank line *inside* a function definition.

The interactive console is optimized for people entering code by
typing, not by copying and pasting large gobs of text.

If you think you can have it both, show us the code.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

Yuval Greenfield
In reply to this post by anatoly techtonik

I agree that it should and it doesn't. I also recall that not having empty lines between function/class definitions can cause indentation errors when pasting to the console on my windows machine.

--Yuval

On Sep 23, 2011 7:26 PM, "anatoly techtonik" <[hidden email]> wrote:
> Currently if you work in console and define a function and then
> immediately call it - it will fail with SyntaxError.
> For example, copy paste this completely valid Python script into console:
>
> def some():
> print "XXX"
> some()
>
> There is an issue for that that was just closed by Eric. However, I'd
> like to know if there are people here that agree that if you paste a
> valid Python script into console - it should work without changes.
> --
> anatoly t.
> _______________________________________________
> Python-Dev mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ubershmekel%40gmail.com

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

Terry Reedy
In reply to this post by anatoly techtonik
On 9/23/2011 7:25 PM, anatoly techtonik wrote:

> Currently if you work in console and define a function and then
> immediately call it - it will fail with SyntaxError.
> For example, copy paste this completely valid Python script into console:
>
> def some():
>    print "XXX"
> some()
>
> There is an issue for that that was just closed by Eric. However, I'd
> like to know if there are people here that agree that if you paste a
> valid Python script into console - it should work without changes.

For this kind of multi-line, multi-statemenmt pasting, open an IDLE edit
window for tem.py (my name) or such, paste, run with F5. I have found
that this works for me than direct pasting.

A interactive lisp interpreter can detect end-of-statement without a
blank line by matching a closing paren to the open paren that starts
every expression.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

briancurtin
On Fri, Sep 23, 2011 at 18:49, Terry Reedy <[hidden email]> wrote:
> A interactive lisp interpreter can detect end-of-statement without a blank
> line by matching a closing paren to the open paren that starts every
> expression.

Braces-loving programmers around the world are feverishly writing a
PEP as we speak.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

Georg Brandl-2
In reply to this post by Guido van Rossum
Am 24.09.2011 01:32, schrieb Guido van Rossum:

> On Fri, Sep 23, 2011 at 4:25 PM, anatoly techtonik <[hidden email]> wrote:
>> Currently if you work in console and define a function and then
>> immediately call it - it will fail with SyntaxError.
>> For example, copy paste this completely valid Python script into console:
>>
>> def some():
>>  print "XXX"
>> some()
>>
>> There is an issue for that that was just closed by Eric. However, I'd
>> like to know if there are people here that agree that if you paste a
>> valid Python script into console - it should work without changes.
>
> You can't fix this without completely changing the way the interactive
> console treats blank lines. None that it's not just that a blank line
> is required after a function definition -- you also *can't* have a
> blank line *inside* a function definition.

While the former could be changed (I think), the latter certainly cannot.
So it's probably not worth changing established behavior.

Georg

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

Yuval Greenfield

Could you elaborate on what would be wrong if function definitions ended only after an explicitly less indented line? The only problem that comes to mind is global scope "if" statements that wouldn't execute when expected (we actually might need to terminate them with a dedented "pass").

On Sep 24, 2011 4:26 AM, "Georg Brandl" <[hidden email]> wrote:
> Am 24.09.2011 01:32, schrieb Guido van Rossum:
>> On Fri, Sep 23, 2011 at 4:25 PM, anatoly techtonik <[hidden email]> wrote:
>>> Currently if you work in console and define a function and then
>>> immediately call it - it will fail with SyntaxError.
>>> For example, copy paste this completely valid Python script into console:
>>>
>>> def some():
>>> print "XXX"
>>> some()
>>>
>>> There is an issue for that that was just closed by Eric. However, I'd
>>> like to know if there are people here that agree that if you paste a
>>> valid Python script into console - it should work without changes.
>>
>> You can't fix this without completely changing the way the interactive
>> console treats blank lines. None that it's not just that a blank line
>> is required after a function definition -- you also *can't* have a
>> blank line *inside* a function definition.
>
> While the former could be changed (I think), the latter certainly cannot.
> So it's probably not worth changing established behavior.
>
> Georg
>
> _______________________________________________
> Python-Dev mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ubershmekel%40gmail.com

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

Georg Brandl-2
You're right that in principle for function definitions there is no ambiguity.
But you also presented the downfall of that proposal: all multi-clause
statements will still need an explicit way of termination, and of course the
"pass" would be exceedingly ugly, not to mention much more confusing than the
current way.

Georg

Am 24.09.2011 11:53, schrieb Yuval Greenfield:

> Could you elaborate on what would be wrong if function definitions ended only
> after an explicitly less indented line? The only problem that comes to mind is
> global scope "if" statements that wouldn't execute when expected (we actually
> might need to terminate them with a dedented "pass").
>
> On Sep 24, 2011 4:26 AM, "Georg Brandl" <[hidden email]
> <mailto:[hidden email]>> wrote:
>> Am 24.09.2011 01:32, schrieb Guido van Rossum:
>>> On Fri, Sep 23, 2011 at 4:25 PM, anatoly techtonik <[hidden email]
> <mailto:[hidden email]>> wrote:
>>>> Currently if you work in console and define a function and then
>>>> immediately call it - it will fail with SyntaxError.
>>>> For example, copy paste this completely valid Python script into console:
>>>>
>>>> def some():
>>>> print "XXX"
>>>> some()
>>>>
>>>> There is an issue for that that was just closed by Eric. However, I'd
>>>> like to know if there are people here that agree that if you paste a
>>>> valid Python script into console - it should work without changes.
>>>
>>> You can't fix this without completely changing the way the interactive
>>> console treats blank lines. None that it's not just that a blank line
>>> is required after a function definition -- you also *can't* have a
>>> blank line *inside* a function definition.
>>
>> While the former could be changed (I think), the latter certainly cannot.
>> So it's probably not worth changing established behavior.




_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

Guido van Rossum
I see a lot of flawed "proposals". This is clearly a python-ideas
discussion. (Anatoly, take note -- please post your new gripe there.)

In the mean time, there's a reasonable work-around if you have to
copy/paste a large block of formatted code:

>>> exec('''
   .
   .
   .
<put anything you like here>
   .
   .
   .
''')
>>>

The only thing that you can't put in there is a triple-quoted string
using single quotes.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

Chris Withers
In reply to this post by Guido van Rossum
On 24/09/2011 00:32, Guido van Rossum wrote:
> The interactive console is optimized for people entering code by
> typing, not by copying and pasting large gobs of text.
>
> If you think you can have it both, show us the code.

Anatoly wants ipython's new qtconsole.

This "does the right thing" because it's a GUI app and so can manipulate
the content on paste...

Not sure if you can do that in a console app...

cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

anatoly techtonik
In reply to this post by Georg Brandl-2
On Sat, Sep 24, 2011 at 11:27 AM, Georg Brandl <[hidden email]> wrote:
Am <a href="tel:24.09.2011%2001" value="+12409201101">24.09.2011 01:32, schrieb Guido van Rossum:
> On Fri, Sep 23, 2011 at 4:25 PM, anatoly techtonik <[hidden email]> wrote:
>> Currently if you work in console and define a function and then
>> immediately call it - it will fail with SyntaxError.
>> For example, copy paste this completely valid Python script into console:
>>
>> def some():
>>  print "XXX"
>> some()
>>
>> There is an issue for that that was just closed by Eric. However, I'd
>> like to know if there are people here that agree that if you paste a
>> valid Python script into console - it should work without changes.
>
> You can't fix this without completely changing the way the interactive
> console treats blank lines. None that it's not just that a blank line
> is required after a function definition -- you also *can't* have a
> blank line *inside* a function definition.

While the former could be changed (I think), the latter certainly cannot.
So it's probably not worth changing established behavior.

I've just hit this UX bug once more, but now I more prepared. Despite
Guido's proposal to move into python-ideas, I continue discussion here,
because:

1. It is not a proposal, but a defect (well, you may argue, but please, don't)
2. This thread has a history of analysis of what's going wrong in console
3. This thread also has developer's decision that answers the question
    "why it's so wrong?" and "why it can't/won't be fixed"
4. Yesterday I've heard from a Java person that Python is hard to pick up
    and remembered how I struggled with indentation myself trying to
    'learn by example' in console

Right now I am trying to cope with point (3.). To summarize, let's speak code
that is copy/pasted into console. Two things that will make me happy if they
behave consistently in console from .py file:

---ex1---
def some():
    print "XXX"
some()
---/ex1---

--ex1.output--
[ex1.py]
XXX
[console]
  File "<stdin>", line 3
    some()
       ^
SyntaxError: invalid syntax
--/ex1.output--


--ex2--
def some():
pass
--/ex2--

--ex2.output--
[ex2.py]
  File "./ex2.py", line 2
    pass
       ^
IndentationError: expected an indented block
[console]
  File "<stdin>", line 2
    pass
       ^
IndentationError: expected an indented block
--/ex2.output--


The second example already works as expected. Why it is not possible to fix ex1? Guido said:

> You can't fix this without completely changing the way the interactive
> console treats blank lines.

But the fix doesn't require changing the way interactive console treats blank lines at all. It only requires to finish current block when a dedented line is encountered and not throwing obviously confusing SyntaxError. At the very least it should not say it is SyntaxError, because the code is pretty valid Python code. If it appears to be invalid "Python Console code" - the error message should say that explicitly. That would be a correct user-friendly fix for this UX issue, but I'd still like the behavior to be fixed - i.e. "allow dedented lines end current block in console without SyntaxError". Right now I don't see the reasons why it is not possible.

Please speak code when replying about use cases/examples that will be broken - I didn't quite get the problem with "global scope if" statements.
-- 
anatoly t. 

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

Giampaolo Rodola'-3
Il 15 dicembre 2011 09:58, anatoly techtonik <[hidden email]> ha scritto:
> 1. It is not a proposal, but a defect (well, you may argue, but please, don't)>

You can't copy/paste multiline scripts into system shell either,
unless you append "\".
It's likely that similar problems exists in a lot of other interactive
shells (ruby?).
And that makes sense to me, because they are supposed to be used interactively.
It might be good to change this? Maybe.
Is the current behavior objectively wrong? No, in my opinion.

--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent script/console behaviour

Terry Reedy
In reply to this post by anatoly techtonik
On 12/15/2011 3:58 AM, anatoly techtonik wrote:

> 1. It is not a proposal, but a defect (well, you may argue, but please,
> don't)

You state a controversial opinion as a fact and then request that others
not discuss it. To me, this is a somewhat obnoxious hit-and-run tactic.
If you do not want the point discussed, don't bring it up.

Anyway, I will follow your request and not argue. Since that opinion is
a central point, not discussing it does not leave much to say.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

A new dict for Xmas?

Mark Shannon-3
In reply to this post by Giampaolo Rodola'-3
Hi all,

The current dict implementation is getting pretty old,
isn't it time we had a new one (for xmas)?

I have a new dict implementation which allows sharing of keys between
objects of the same class.
You can check it out here:
http://bitbucket.org/markshannon/hotpy_new_dict

Performance:

For numerical applications, with few instances of user-defined classes,
performance is pretty much unchanged, degrading about 1% for pystones.

For applications that create lots of instances of user-defined classes,
performance is improved and memory savings are large.

For the gcbench benchmark (from unladen swallow),
cpython with the new dict is about 9% faster and, more importantly,
reduces memory use from 99 Mbytes to 61Mbytes (a 38% reduction).

All tests were done on my ancient 32 bit intel linux  machine,
please try it out on your machines and let me know what sort of results
you get.

By the way it passes all the tests,
but there are strange interactions with weakrefs and the GC.
(Try running the tests, you'll see what I mean)


Cheers,
Mark
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: A new dict for Xmas?

Antoine Pitrou
On Thu, 15 Dec 2011 22:18:18 +0000
Mark Shannon <[hidden email]> wrote:
>
> For the gcbench benchmark (from unladen swallow),
> cpython with the new dict is about 9% faster and, more importantly,
> reduces memory use from 99 Mbytes to 61Mbytes (a 38% reduction).
>
> All tests were done on my ancient 32 bit intel linux  machine,
> please try it out on your machines and let me know what sort of results
> you get.

Benchmark results under a Core i5, 64-bit Linux:

Report on Linux localhost.localdomain 2.6.38.8-desktop-8.mga #1 SMP Fri
Nov 4 00:05:53 UTC 2011 x86_64 x86_64 Total CPU cores: 4

### call_method ###
Min: 0.292352 -> 0.274041: 1.07x faster
Avg: 0.292978 -> 0.277124: 1.06x faster
Significant (t=17.31)
Stddev: 0.00053 -> 0.00351: 6.5719x larger

### call_method_slots ###
Min: 0.284101 -> 0.273508: 1.04x faster
Avg: 0.285029 -> 0.274534: 1.04x faster
Significant (t=26.86)
Stddev: 0.00068 -> 0.00135: 1.9969x larger

### call_simple ###
Min: 0.225191 -> 0.222104: 1.01x faster
Avg: 0.227443 -> 0.222776: 1.02x faster
Significant (t=9.53)
Stddev: 0.00181 -> 0.00056: 3.2266x smaller

### fastpickle ###
Min: 0.482402 -> 0.493695: 1.02x slower
Avg: 0.486077 -> 0.496568: 1.02x slower
Significant (t=-5.35)
Stddev: 0.00340 -> 0.00276: 1.2335x smaller

### fastunpickle ###
Min: 0.394846 -> 0.433733: 1.10x slower
Avg: 0.397362 -> 0.436318: 1.10x slower
Significant (t=-23.73)
Stddev: 0.00234 -> 0.00283: 1.2129x larger

### float ###
Min: 0.052567 -> 0.051377: 1.02x faster
Avg: 0.053812 -> 0.052669: 1.02x faster
Significant (t=3.72)
Stddev: 0.00110 -> 0.00107: 1.0203x smaller

### json_dump ###
Min: 0.381395 -> 0.391053: 1.03x slower
Avg: 0.381937 -> 0.393219: 1.03x slower
Significant (t=-7.15)
Stddev: 0.00043 -> 0.00350: 8.1447x larger

### json_load ###
Min: 0.347112 -> 0.369763: 1.07x slower
Avg: 0.347490 -> 0.370317: 1.07x slower
Significant (t=-69.64)
Stddev: 0.00045 -> 0.00058: 1.2717x larger

### nbody ###
Min: 0.238068 -> 0.219208: 1.09x faster
Avg: 0.238951 -> 0.220000: 1.09x faster
Significant (t=36.09)
Stddev: 0.00076 -> 0.00090: 1.1863x larger

### nqueens ###
Min: 0.262282 -> 0.252576: 1.04x faster
Avg: 0.263835 -> 0.254497: 1.04x faster
Significant (t=7.12)
Stddev: 0.00117 -> 0.00269: 2.2914x larger

### regex_effbot ###
Min: 0.060298 -> 0.057791: 1.04x faster
Avg: 0.060435 -> 0.058128: 1.04x faster
Significant (t=17.82)
Stddev: 0.00012 -> 0.00026: 2.1761x larger

### richards ###
Min: 0.148266 -> 0.143755: 1.03x faster
Avg: 0.150677 -> 0.145003: 1.04x faster
Significant (t=5.74)
Stddev: 0.00200 -> 0.00094: 2.1329x smaller

### silent_logging ###
Min: 0.057191 -> 0.059082: 1.03x slower
Avg: 0.057335 -> 0.059194: 1.03x slower
Significant (t=-17.40)
Stddev: 0.00020 -> 0.00013: 1.4948x smaller

### unpack_sequence ###
Min: 0.000046 -> 0.000042: 1.10x faster
Avg: 0.000048 -> 0.000044: 1.09x faster
Significant (t=128.98)
Stddev: 0.00000 -> 0.00000: 1.8933x smaller


gcbench first showed no memory consumption difference (using "ps -u").
I then removed the "stretch tree" (which apparently reserves memory
upfront) and I saw a ~30% memory saving as well as a 20% performance
improvement on large sizes.

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: A new dict for Xmas?

Mark Shannon-3
Antoine Pitrou wrote:

> On Thu, 15 Dec 2011 22:18:18 +0000
> Mark Shannon <[hidden email]> wrote:
>> For the gcbench benchmark (from unladen swallow),
>> cpython with the new dict is about 9% faster and, more importantly,
>> reduces memory use from 99 Mbytes to 61Mbytes (a 38% reduction).
>>
>> All tests were done on my ancient 32 bit intel linux  machine,
>> please try it out on your machines and let me know what sort of results
>> you get.
>
> Benchmark results under a Core i5, 64-bit Linux:
>
> Report on Linux localhost.localdomain 2.6.38.8-desktop-8.mga #1 SMP Fri
> Nov 4 00:05:53 UTC 2011 x86_64 x86_64 Total CPU cores: 4
>
> ### call_method ###
> Min: 0.292352 -> 0.274041: 1.07x faster
> Avg: 0.292978 -> 0.277124: 1.06x faster
> Significant (t=17.31)
> Stddev: 0.00053 -> 0.00351: 6.5719x larger
>
> ### call_method_slots ###
> Min: 0.284101 -> 0.273508: 1.04x faster
> Avg: 0.285029 -> 0.274534: 1.04x faster
> Significant (t=26.86)
> Stddev: 0.00068 -> 0.00135: 1.9969x larger
>
> ### call_simple ###
> Min: 0.225191 -> 0.222104: 1.01x faster
> Avg: 0.227443 -> 0.222776: 1.02x faster
> Significant (t=9.53)
> Stddev: 0.00181 -> 0.00056: 3.2266x smaller
>
> ### fastpickle ###
> Min: 0.482402 -> 0.493695: 1.02x slower
> Avg: 0.486077 -> 0.496568: 1.02x slower
> Significant (t=-5.35)
> Stddev: 0.00340 -> 0.00276: 1.2335x smaller
>
> ### fastunpickle ###
> Min: 0.394846 -> 0.433733: 1.10x slower
> Avg: 0.397362 -> 0.436318: 1.10x slower
> Significant (t=-23.73)
> Stddev: 0.00234 -> 0.00283: 1.2129x larger
>
> ### float ###
> Min: 0.052567 -> 0.051377: 1.02x faster
> Avg: 0.053812 -> 0.052669: 1.02x faster
> Significant (t=3.72)
> Stddev: 0.00110 -> 0.00107: 1.0203x smaller
>
> ### json_dump ###
> Min: 0.381395 -> 0.391053: 1.03x slower
> Avg: 0.381937 -> 0.393219: 1.03x slower
> Significant (t=-7.15)
> Stddev: 0.00043 -> 0.00350: 8.1447x larger
>
> ### json_load ###
> Min: 0.347112 -> 0.369763: 1.07x slower
> Avg: 0.347490 -> 0.370317: 1.07x slower
> Significant (t=-69.64)
> Stddev: 0.00045 -> 0.00058: 1.2717x larger
>
> ### nbody ###
> Min: 0.238068 -> 0.219208: 1.09x faster
> Avg: 0.238951 -> 0.220000: 1.09x faster
> Significant (t=36.09)
> Stddev: 0.00076 -> 0.00090: 1.1863x larger
>
> ### nqueens ###
> Min: 0.262282 -> 0.252576: 1.04x faster
> Avg: 0.263835 -> 0.254497: 1.04x faster
> Significant (t=7.12)
> Stddev: 0.00117 -> 0.00269: 2.2914x larger
>
> ### regex_effbot ###
> Min: 0.060298 -> 0.057791: 1.04x faster
> Avg: 0.060435 -> 0.058128: 1.04x faster
> Significant (t=17.82)
> Stddev: 0.00012 -> 0.00026: 2.1761x larger
>
> ### richards ###
> Min: 0.148266 -> 0.143755: 1.03x faster
> Avg: 0.150677 -> 0.145003: 1.04x faster
> Significant (t=5.74)
> Stddev: 0.00200 -> 0.00094: 2.1329x smaller
>
> ### silent_logging ###
> Min: 0.057191 -> 0.059082: 1.03x slower
> Avg: 0.057335 -> 0.059194: 1.03x slower
> Significant (t=-17.40)
> Stddev: 0.00020 -> 0.00013: 1.4948x smaller
>
> ### unpack_sequence ###
> Min: 0.000046 -> 0.000042: 1.10x faster
> Avg: 0.000048 -> 0.000044: 1.09x faster
> Significant (t=128.98)
> Stddev: 0.00000 -> 0.00000: 1.8933x smaller

Thanks for running the benchmarks.
It's probably best not to attach to much significance to
a few percent her and there, but its good to see that performance is OK.

>
>
> gcbench first showed no memory consumption difference (using "ps -u").
> I then removed the "stretch tree" (which apparently reserves memory
> upfront) and I saw a ~30% memory saving as well as a 20% performance
> improvement on large sizes.

I should say how I did my memory tests.
I did a search using ulimit to limit the maximum amount of memory the
process was allowed. The given numbers were the minimum required to
complete, I did not remove the "stretch tree".

Cheers,
Mark.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: A new dict for Xmas?

Gregory Ewing
In reply to this post by Mark Shannon-3
Mark Shannon wrote:

> I have a new dict implementation which allows sharing of keys between
> objects of the same class.

We already have the __slots__ mechanism for memory savings.
Have you done any comparisons with that?

Seems to me that __slots__ ought to save even more memory,
since it eliminates the per-instance dict altogether rather
than just the keys half of it.

--
Greg
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: A new dict for Xmas?

Mark Shannon-3
Greg Ewing wrote:
> Mark Shannon wrote:
>
>> I have a new dict implementation which allows sharing of keys between
>> objects of the same class.
>
> We already have the __slots__ mechanism for memory savings.
> Have you done any comparisons with that?
>

You can't make Python programmers use slots, neither can you
automatically change existing programs.

Are you suggesting that because the __slots__ mechanism exists,
the dict implementation doesn't have to be efficient?

> Seems to me that __slots__ ought to save even more memory,
> since it eliminates the per-instance dict altogether rather
> than just the keys half of it.
>

Of course using __slots__ saves more memory,
but people don't use them much.

Cheers,
Mark.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: A new dict for Xmas?

Terry Reedy
On 12/16/2011 5:03 AM, Mark Shannon wrote:

> Of course using __slots__ saves more memory,
> but people don't use them much.

Do you think the stdlib should be using __slots__ more?

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: A new dict for Xmas?

Mark Shannon-3
Terry Reedy wrote:
> On 12/16/2011 5:03 AM, Mark Shannon wrote:
>
>> Of course using __slots__ saves more memory,
>> but people don't use them much.
>
> Do you think the stdlib should be using __slots__ more?

For some things yes, but where it's critical slots are already used.
Take the ordered dict, the nodes in that use slots.

The advantage of improving things in the VM is that
we don't have to rewrite half of the stdlib.

Cheers,
Mark.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
12