[Python-Dev] performance of {} versus dict()
Hi All,
A colleague pointed me at Doug's excellent article here:
http://www.doughellmann.com/articles/misc/dict-performance/index.html
...which made me a little sad, I suspect I'm not the only one who finds:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
...easier to read than:
a_dict = {
'x':1,
'y':2,
'z':3,
...
}
What can we do to speed up the former case?
Here's comparison for different versions of CPython:
$ python2.5 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
raw times: 2.96 2.49 2.47 2.42 2.42
100 loops, best of 5: 2.42 usec per loop
$ python2.5 -m timeit -n 100 -r 5 -v
"{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}"
raw times: 1.69 1.71 1.68 1.68 1.68
100 loops, best of 5: 1.68 usec per loop
$ python2.6 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
raw times: 2.41 2.41 2.42 2.44 2.41
100 loops, best of 5: 2.41 usec per loop
$ python2.6 -m timeit -n 100 -r 5 -v
"{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}"
raw times: 1.51 1.51 1.52 1.51 1.51
100 loops, best of 5: 1.51 usec per loop
$ python2.7 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
raw times: 2.32 2.31 2.31 2.32 2.31
100 loops, best of 5: 2.31 usec per loop
$ python2.7 -m timeit -n 100 -r 5 -v
"{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}"
raw times: 1.49 1.49 1.77 1.76 1.55
100 loops, best of 5: 1.49 usec per loop
So, not the 6 times headline figure that Doug quotes, but certainly a
difference. Can someone with Python 3 handy compare there too?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Am 14.11.2012 10:12, schrieb Chris Withers:
Can someone with Python 3 handy compare there too?
C:\Python27\python -m timeit -n 100 -r 5 -v
"dict(a=1, b=2, c=3, d=4, e=5, f=6, g=7)"
raw times: 0.918 0.924 0.922 0.928 0.926
100 loops, best of 5: 0.918 usec per loop
C:\Python27\python -m timeit -n 100 -r 5 -v
"{'a':1, 'b':2, 'c':3, 'd':4, 'e':5, 'f':6, 'g':7}"
raw times: 0.48 0.49 0.482 0.496 0.497
100 loops, best of 5: 0.48 usec per loop
C:\Python32\python -m timeit -n 100 -r 5 -v
"dict(a=1, b=2, c=3, d=4, e=5, f=6, g=7)"
raw times: 0.898 0.891 0.892 0.899 0.891
100 loops, best of 5: 0.891 usec per loop
C:\Python32\python -m timeit -n 100 -r 5 -v
"{'a':1, 'b':2, 'c':3, 'd':4, 'e':5, 'f':6, 'g':7}"
raw times: 0.444 0.463 0.461 0.464 0.461
100 loops, best of 5: 0.444 usec per loop
C:\Python32_64\python -m timeit -n 100 -r 5 -v
"dict(a=1, b=2, c=3, d=4, e=5, f=6, g=7)"
raw times: 0.908 0.923 0.927 0.912 0.923
100 loops, best of 5: 0.908 usec per loop
C:\Python32_64\python -m timeit -n 100 -r 5 -v
"{'a':1, 'b':2, 'c':3, 'd':4, 'e':5, 'f':6, 'g':7}"
raw times: 0.484 0.446 0.501 0.45 0.442
100 loops, best of 5: 0.442 usec per loop
C:\Python33_64\python -m timeit -n 100 -r 5 -v
"dict(a=1, b=2, c=3, d=4, e=5, f=6, g=7)"
raw times: 1.02 1.07 1.03 1.11 1.07
100 loops, best of 5: 1.02 usec per loop
C:\Python33_64\python -m timeit -n 100 -r 5 -v
"{'a':1, 'b':2, 'c':3, 'd':4, 'e':5, 'f':6, 'g':7}"
raw times: 0.444 0.449 0.455 0.452 0.46
100 loops, best of 5: 0.444 usec per loop
Tested on Win7/64 bit. Python 2.7 is the 32-bit version, 3.2 is
installed as 32-bit and 64-bit versions and 3.3 only as 64-bit version.
In any case, the difference is even a bit stronger than what you
experience and it seems that all versions perform roughly similar.
Uli
**
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Hans Robert Dapprich, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den
Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte
benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte
Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf
weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte
�nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht
verantwortlich.
**
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 14/11/2012 09:58, Merlijn van Deen wrote:
On 14 November 2012 10:12, Chris Withers wrote:
...which made me a little sad
Why did it make you sad? dict() takes 0.2µs, {} takes 0.04µs. In other
words: you can run dict() _five million_ times per second, and {}
twenty-five million times per second. That is 'a lot' and 'a lot'. It
also means you are unlikely to notice the difference in real-world
code. Just use the one you feel is clearer in the situation, and don't
worry about micro-optimalization.
I'm inclined to agree, but it makes me sad for two reasons:
- it's something that people get hung up on, for better or worse. (if it
wasn't, Doug wouldn't have written his article)
- it can make a difference, for example setting up a dict with many keys
at the core of a type loop.
Without looking at implementation, they should logically perform the same...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Zitat von Chris Withers : a_dict = dict( x = 1, y = 2, z = 3, ... ) What can we do to speed up the former case? It should be possible to special-case it. Rather than creating a new dictionary from scratch, one could try to have the new dictionary the same size as the original one, and copy all entries. I also wonder whether the PyArg_ValidateKeywordArguments call is really necessary: if this is not a proper keyword dictionary, dict creation could still proceed in a reasonable way. I don't know how much this would gain, though. You still have to create two dictionary objects. For a better speedup, try def xdict(**kwds): return kwds (possibly written in C for even more speed) Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Le Wed, 14 Nov 2012 10:00:59 +,
Chris Withers a écrit :
> On 14/11/2012 09:58, Merlijn van Deen wrote:
> > On 14 November 2012 10:12, Chris Withers
> > wrote:
> >> ...which made me a little sad
> >
> > Why did it make you sad? dict() takes 0.2µs, {} takes 0.04µs. In
> > other words: you can run dict() _five million_ times per second,
> > and {} twenty-five million times per second. That is 'a lot' and 'a
> > lot'. It also means you are unlikely to notice the difference in
> > real-world code. Just use the one you feel is clearer in the
> > situation, and don't worry about micro-optimalization.
>
> I'm inclined to agree, but it makes me sad for two reasons:
>
> - it's something that people get hung up on, for better or worse. (if
> it wasn't, Doug wouldn't have written his article)
>
> - it can make a difference, for example setting up a dict with many
> keys at the core of a type loop.
Well, please post examples of *real-world* use cases where it makes a
difference.
Otherwise, you're asking us to add hacks to the implementation just to
make you feel good, which is quite unacceptable.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 112, Issue 23
Chris Withers wrote:
> On 14/11/2012 09:58, Merlijn van Deen wrote:
> > On 14 November 2012 10:12, Chris Withers wrote:
> >> ...which made me a little sad
> >
> > Why did it make you sad? dict() takes 0.2?s, {} takes 0.04?s. In other
> > words: you can run dict() _five million_ times per second, and {}
> > twenty-five million times per second. That is 'a lot' and 'a lot'. It
> > also means you are unlikely to notice the difference in real-world
> > code. Just use the one you feel is clearer in the situation, and don't
> > worry about micro-optimalization.
>
> I'm inclined to agree, but it makes me sad for two reasons:
>
> - it's something that people get hung up on, for better or worse. (if it
> wasn't, Doug wouldn't have written his article)
>
> - it can make a difference, for example setting up a dict with many keys
> at the core of a type loop.
>
> Without looking at implementation, they should logically perform the
> same...
>
> Well, without looking at the implementation, you could form any opinion you
like about how they should perform. Still you could speculate that dict()
will
require a builtins name lookup, and that the process of passing keyword
arguments
might itself involve constructing a dictionary, so must inherently take at
least
a little longer than compiling a {} literal.
Peter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 14/11/12 21:00, Chris Withers wrote:
On 14/11/2012 09:58, Merlijn van Deen wrote:
On 14 November 2012 10:12, Chris Withers wrote:
...which made me a little sad
Why did it make you sad? dict() takes 0.2µs, {} takes 0.04µs. In other
words: you can run dict() _five million_ times per second, and {}
twenty-five million times per second. That is 'a lot' and 'a lot'. It
also means you are unlikely to notice the difference in real-world
code. Just use the one you feel is clearer in the situation, and don't
worry about micro-optimalization.
I'm inclined to agree, but it makes me sad for two reasons:
- it's something that people get hung up on, for better or worse. (if it
wasn't, Doug wouldn't have written his article)
People get hung up on all sorts of things. I would hate to think we would
complicate the implementation to pander to pointless micro-optimization.
I'm sure that there are many far more important things than this.
- it can make a difference, for example setting up a dict with many keys
at the core of a type loop.
Ah yes, the semi-mythical "tight loop".
I've never come across one of these tight loops that creates a dict with
many keys in a tight loop, and then apparently fails to actually use it
for anything useful. For if it did, surely the actual work done with the
dict is going to outweigh the setup cost for all but the most trivial
applications. I find it hard to get uptight about a small inefficiency
in trivial applications that don't do much.
Show me a non-toy use-case where creating dicts is an actual bottleneck,
and I'll revise my position.
Without looking at implementation, they should logically perform the same...
I disagree. Calling dict() has to do a name lookup, and then a function
call. That alone is almost 2.5 times as expensive as creating a dict
literal on my machine:
[steve@ando ~]$ python3.3 -m timeit "d = {}"
1000 loops, best of 3: 0.17 usec per loop
[steve@ando ~]$ python3.3 -m timeit "d = dict()"
100 loops, best of 3: 0.416 usec per loop
Then you have the function call itself, which engages the argument parsing
mechanism, which does more work than dict literal syntax. For example, it
checks for duplicate keyword arguments, while dict literals happily accept
duplicate keys.
It's hardly a surprise that dict() is slower than {}.
--
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Distutils] [Catalog-sig] accept the wheel PEPs 425, 426, 427
On Nov 14, 2012, at 2:23 AM, Ronald Oussoren wrote: > > On 13 Nov, 2012, at 17:21, Antoine Pitrou wrote: > >> Le Tue, 13 Nov 2012 16:10:30 +0100, >> Ronald Oussoren a écrit : >>> >>> On 13 Nov, 2012, at 16:00, Daniel Holth wrote: I want to remove distutils from the standard library. >>> >>> Why? Distutils may not be perfect, but is usable for basic packages. >>> It could even be enhanced to support these peps and be even more >>> useable, although patches for that would run into the self-imposed >>> freeze of distutils development. >> >> It wouldn't be totally unreasonable to start a project named >> "distutils2" to build the next-generation distutils library. >> >> Oops :-) > > Or carefully enhance distutils itself. Rewriting distutils in one go seems > to be too ambitious with the limited resources available to do so. That has been tried already (setuptools, distribute, distutils2). Instead, try bento (http://cournape.github.com/Bento/). Hilariously everyone I've showed it to is immediately put off by the indentation based syntax (who would use such a thing?) but the project has a few years of effort behind it and is well designed. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 8:12 PM, Chris Withers wrote:
> I suspect I'm not the only one who finds:
>
> a_dict = dict(
> x = 1,
> y = 2,
> z = 3,
> ...
> )
>
> ...easier to read than:
>
> a_dict = {
> 'x':1,
> 'y':2,
> 'z':3,
> ...
> }
>
> What can we do to speed up the former case?
Perhaps an alternative question: What can be done to make the latter
less unpalatable? I personally prefer dict literal syntax to a dict
constructor call, but no doubt there are a number of people who feel
as you do. In what way(s) do you find the literal syntax less
readable, and can some simple (and backward-compatible) enhancements
help that?
I've seen criticisms (though I don't recall where) of Python,
comparing it to JavaScript/ECMAScript, that complain of the need to
quote the keys. IMO this is a worthwhile downside, as it allows you to
use variables as the keys, rather than requiring (effectively) literal
strings. But it does make a dict literal that much more "noisy" than
the constructor.
ChrisA
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
2012/11/14 : > > Zitat von Chris Withers : > > >> a_dict = dict( >> x = 1, >> y = 2, >> z = 3, >> ... >> ) > > >> What can we do to speed up the former case? > > > It should be possible to special-case it. Rather than creating > a new dictionary from scratch, one could try to have the new dictionary > the same size as the original one, and copy all entries. > > I also wonder whether the PyArg_ValidateKeywordArguments call is really > necessary: if this is not a proper keyword dictionary, dict creation > could still proceed in a reasonable way. In the common case PyArg_ValidateKeywordArguments should be a simple check. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Chris Angelico, 14.11.2012 14:18:
> On Wed, Nov 14, 2012 at 8:12 PM, Chris Withers wrote:
>> I suspect I'm not the only one who finds:
>>
>> a_dict = dict(
>> x = 1,
>> y = 2,
>> z = 3,
>> ...
>> )
>>
>> ...easier to read than:
>>
>> a_dict = {
>> 'x':1,
>> 'y':2,
>> 'z':3,
>> ...
>> }
>>
>> What can we do to speed up the former case?
>
> Perhaps an alternative question: What can be done to make the latter
> less unpalatable? I personally prefer dict literal syntax to a dict
> constructor call, but no doubt there are a number of people who feel
> as you do. In what way(s) do you find the literal syntax less
> readable, and can some simple (and backward-compatible) enhancements
> help that?
>
> I've seen criticisms (though I don't recall where) of Python,
> comparing it to JavaScript/ECMAScript, that complain of the need to
> quote the keys. IMO this is a worthwhile downside, as it allows you to
> use variables as the keys, rather than requiring (effectively) literal
> strings. But it does make a dict literal that much more "noisy" than
> the constructor.
If that bothers you in a specific case, I recommend using the constructor
instead of a literal.
Stefan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Distutils] [Catalog-sig] accept the wheel PEPs 425, 426, 427
On 14 November 2012 12:04, Daniel Holth wrote: > That has been tried already (setuptools, distribute, distutils2). Instead, > try bento (http://cournape.github.com/Bento/). > > Hilariously everyone I've showed it to is immediately put off by the > indentation based syntax (who would use such a thing?) but the project has > a few years of effort behind it and is well designed. > > Ironically, given the thread, it doesn't support the metadata PEPs, so packages installed with bento aren't visible to pip, etc. Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Distutils] [Catalog-sig] accept the wheel PEPs 425, 426, 427
Well, you can build eggs with Bento, and I have a patch that allows it to build wheels, in both cases it will produce pip-compatible metadata. The Bento author has his own informed opinions about the way packaging should work which do not necessarily include the packaging PEPs. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers wrote:
> Hi All,
>
> A colleague pointed me at Doug's excellent article here:
> ...which made me a little sad, I suspect I'm not the only one who finds:
>
> a_dict = dict(
> x = 1,
> y = 2,
> z = 3,
> ...
> )
>
> ...easier to read than:
>
> a_dict = {
> 'x':1,
> 'y':2,
> 'z':3,
> ...
> }
Hey, it makes me a little sad that dict breaks convention by allowing
the use of unquoted characters (which everywhere else looks like
variable names) just for a silly typing optimization.
mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 10:12:54AM -0600, Mark Adam
wrote:
> On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers wrote:
> > Hi All,
> >
> > A colleague pointed me at Doug's excellent article here:
> > ...which made me a little sad, I suspect I'm not the only one who finds:
> >
> > a_dict = dict(
> > x = 1,
> > y = 2,
> > z = 3,
> > ...
> > )
> >
> > ...easier to read than:
> >
> > a_dict = {
> > 'x':1,
> > 'y':2,
> > 'z':3,
> > ...
> > }
>
> Hey, it makes me a little sad that dict breaks convention by allowing
> the use of unquoted characters (which everywhere else looks like
> variable names) just for a silly typing optimization.
It doesn't. It's a call (function call or or a class instantiation)
and it's not dict-specific: function(a=1, b=None)...
Oleg.
--
Oleg Broytmanhttp://phdru.name/[email protected]
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 14.11.12 11:12, Chris Withers wrote:
which made me a little sad, I suspect I'm not the only one who finds:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
easier to read than:
a_dict = {
'x':1,
'y':2,
'z':3,
...
}
PEP 8 recommends:
a_dict = dict(
x=1,
y=2,
z=3,
...
)
and
a_dict = {
'x': 1,
'y': 2,
'z': 3,
...
}
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 14/11/2012 4:23pm, Serhiy Storchaka wrote:
PEP 8 recommends:
a_dict = dict(
x=1,
y=2,
z=3,
...
)
and
a_dict = {
'x': 1,
'y': 2,
'z': 3,
...
}
In which section? I can't see such a recommendation.
--
Richard
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 10:12 AM, Mark Adam wrote:
> On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers wrote:
>> Hi All,
>>
>> A colleague pointed me at Doug's excellent article here:
>> ...which made me a little sad, I suspect I'm not the only one who finds:
>>
>> a_dict = dict(
>> x = 1,
>> y = 2,
>> z = 3,
>> ...
>> )
>>
>> ...easier to read than:
>>
>> a_dict = {
>> 'x':1,
>> 'y':2,
>> 'z':3,
>> ...
>> }
>
> Hey, it makes me a little sad that dict breaks convention by allowing
> the use of unquoted characters (which everywhere else looks like
> variable names) just for a silly typing optimization.
What convention and typing optimization is this? I hope you aren't
suggesting it should be dict("x"=1) or dict("x":1)?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 2012-11-14, at 17:42 , Richard Oudkerk wrote:
> On 14/11/2012 4:23pm, Serhiy Storchaka wrote:
>> PEP 8 recommends:
>>
>> a_dict = dict(
>> x=1,
>> y=2,
>> z=3,
>> ...
>> )
>>
>> and
>>
>> a_dict = {
>> 'x': 1,
>> 'y': 2,
>> 'z': 3,
>> ...
>> }
>
> In which section? I can't see such a recommendation.
Whitespace in Expressions and Statements > Other Recommendations
3rd bullet:
—
Don't use spaces around the = sign when used to indicate a keyword argument or
a default parameter value.
Yes:
def complex(real, imag=0.0):
return magic(r=real, i=imag)
No:
def complex(real, imag = 0.0):
return magic(r = real, i = imag)
—
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 11:02 AM, Xavier Morel wrote:
>
> On 2012-11-14, at 17:42 , Richard Oudkerk wrote:
>
>> On 14/11/2012 4:23pm, Serhiy Storchaka wrote:
>>> PEP 8 recommends:
>>>
>>> a_dict = dict(
>>> x=1,
>>> y=2,
>>> z=3,
>>> ...
>>> )
>>>
>>> and
>>>
>>> a_dict = {
>>> 'x': 1,
>>> 'y': 2,
>>> 'z': 3,
>>> ...
>>> }
>>
>> In which section? I can't see such a recommendation.
>
> Whitespace in Expressions and Statements > Other Recommendations
>
> 3rd bullet:
>
> —
> Don't use spaces around the = sign when used to indicate a keyword argument
> or a default parameter value.
>
> Yes:
>
> def complex(real, imag=0.0):
> return magic(r=real, i=imag)
>
> No:
>
> def complex(real, imag = 0.0):
> return magic(r = real, i = imag)
That's not a recommendation to use the **kwargs style.
mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 11:00 AM, Brian Curtin wrote:
> On Wed, Nov 14, 2012 at 10:12 AM, Mark Adam wrote:
>> On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers
>> wrote:
>>> Hi All,
>>>
>>> A colleague pointed me at Doug's excellent article here:
>>> ...which made me a little sad, I suspect I'm not the only one who finds:
>>>
>>> a_dict = dict(
>>> x = 1,
>>> y = 2,
>>> z = 3,
>>> ...
>>> )
>>>
>>> ...easier to read than:
>>>
>>> a_dict = {
>>> 'x':1,
>>> 'y':2,
>>> 'z':3,
>>> ...
>>> }
>>
>> Hey, it makes me a little sad that dict breaks convention by allowing
>> the use of unquoted characters (which everywhere else looks like
>> variable names) just for a silly typing optimization.
>
> What convention and typing optimization is this? I hope you aren't
> suggesting it should be dict("x"=1) or dict("x":1)?
Try the canonical {'x':1}. Only dict allows the special
initialization above. Other collections require an iterable. I'm guessing
**kwargs initialization was only used because it is so simple to
implement, but that's not necessarily a heuristic for good language design.
mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, 14 Nov 2012 11:10:15 -0600, Mark Adam wrote:
> On Wed, Nov 14, 2012 at 11:00 AM, Brian Curtin wrote:
> > On Wed, Nov 14, 2012 at 10:12 AM, Mark Adam
> > wrote:
> >> On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers
> >> wrote:
> >>> Hi All,
> >>>
> >>> A colleague pointed me at Doug's excellent article here:
> >>> ...which made me a little sad, I suspect I'm not the only one who finds:
> >>>
> >>> a_dict = dict(
> >>> x = 1,
> >>> y = 2,
> >>> z = 3,
> >>> ...
> >>> )
> >>>
> >>> ...easier to read than:
> >>>
> >>> a_dict = {
> >>> 'x':1,
> >>> 'y':2,
> >>> 'z':3,
> >>> ...
> >>> }
> >>
> >> Hey, it makes me a little sad that dict breaks convention by allowing
> >> the use of unquoted characters (which everywhere else looks like
> >> variable names) just for a silly typing optimization.
> >
> > What convention and typing optimization is this? I hope you aren't
> > suggesting it should be dict("x"=1) or dict("x":1)?
>
> Try the canonical {'x':1}. Only dict allows the special
> initialization above. Other collections require an iterable. I'm guessing
> **kwargs initialization was only used because it is so simple to
> implement, but that's not necessarily a heuristic for good language design.
Maybe it's not good design, but I'll bet you that if it didn't do that,
there would be lots of instances of this scattered around various
codebases:
def makedict(**kw):
return kw
--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 11:27 AM, R. David Murray wrote: > Maybe it's not good design, but I'll bet you that if it didn't do that, > there would be lots of instances of this scattered around various > codebases: > > def makedict(**kw): > return kw Now that's a good solution and probably solves the OP speed problem. mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 14/11/2012 5:02pm, Xavier Morel wrote: In which section? I can't see such a recommendation. Whitespace in Expressions and Statements > Other Recommendations 3rd bullet: — Don't use spaces around the = sign when used to indicate a keyword argument or a default parameter value. Oops, I did not even notice that difference. I thought Serhiy was talking about indenting the closing ')' and '}'. -- Richard ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 2012-11-14, at 18:08 , Mark Adam wrote: > > That's not a recommendation to use the **kwargs style. And nobody said it was. It's a recommendation to not put spaces around the equals sign when using keyword arguments which is the correction Serhiy applied to the original code (along with adding a space after the colon in the literal dict, also a PEP8 recommendation). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 2012-11-14, at 18:10 , Mark Adam wrote:
>
> Try the canonical {'x':1}. Only dict allows the special
> initialization above. Other collections require an iterable.
Other collections don't have a choice, because it would often be
ambiguous. Dicts do not have that issue.
> I'm guessing
> **kwargs initialization was only used because it is so simple to
> implement, but that's not necessarily a heuristic for good language design.
In this case it very much is, it permits easily merging two dicts in a
single expression or cloning-with-replacement. It also mirrors the
signature of dict.update which I think is a Good Thing.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 12:12 PM, Xavier Morel wrote:
> On 2012-11-14, at 18:10 , Mark Adam wrote:
>>
>> Try the canonical {'x':1}. Only dict allows the special
>> initialization above. Other collections require an iterable.
>
> Other collections don't have a choice, because it would often be
> ambiguous. Dicts do not have that issue.
mkay
>> I'm guessing
>> **kwargs initialization was only used because it is so simple to
>> implement, but that's not necessarily a heuristic for good language design.
>
> In this case it very much is, it permits easily merging two dicts in a
> single expression or cloning-with-replacement. It also mirrors the
> signature of dict.update which I think is a Good Thing.
Merging of two dicts is done with dict.update. How do you do it on
initialization? This doesn't make sense.
mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Distutils] [Catalog-sig] accept the wheel PEPs425, 426, 427
Mmmm, interesting point and worth a discussion about different roles (developer, system admin, final user etc.) having different needs. I believe distutils is used as tool primarily (setup.py bdist_rpm/msi to create installable objects, setup.py bdist_sdist to manage the source code etc.): this complicates the landscape. Some developer has expectation (wrong IMHO) to replace a whole lot of tools with it (downloaders/installers/package managers/etc.): this is an uphill struggle against already widely deployed systems (dpkg/yum/even windows has something!). I think Tarek did some work in the past and the result is visible in the "The Hitchhiker’s Guide to Packaging" but I've no idea where it went in the end ... only is left is a punch-in-the-eye page (http://www.python.org/doc) :D These days I'm stuck with the old KISS approach and I write a setup.py to create "packages" and a makefile to create doc, run tests etc. I'm fairly happy with that. Thanks On Wed 14/11/12 08:32, "Ronald Oussoren" [email protected] wrote: > > I'm not convinced that distutils is untestable. A major problem with > distutils is that its API is barely documented, which effectly makes > all of it public API (simular to asyncore). IIRC that's the main > reason why distutils is frozen right now: with a lot of changes to distutils > people started to complain that this could break there there distutils > scripts. > The lack of a specification also makes testing harder, as it is > unclear what should be tested. > > Ronald > > ___ > Distutils-SIG maillist - [email protected] > http://mail.python.org/mailman/listinfo/distutils-sig > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 2012-11-14, at 19:54 , Mark Adam wrote: > > Merging of two dicts is done with dict.update. No, dict.update merges one dict (or two) into a third one. > How do you do it on > initialization? This doesn't make sense. dict(d1, **d2) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Thu, Nov 15, 2012 at 12:18:38AM +1100, Chris Angelico
wrote:
> On Wed, Nov 14, 2012 at 8:12 PM, Chris Withers wrote:
> > I suspect I'm not the only one who finds:
> >
> > a_dict = dict(
> > x = 1,
> > y = 2,
> > z = 3,
> > ...
> > )
> >
> > ...easier to read than:
> >
> > a_dict = {
> > 'x':1,
> > 'y':2,
> > 'z':3,
> > ...
> > }
> >
> > What can we do to speed up the former case?
>
> Perhaps an alternative question: What can be done to make the latter
> less unpalatable? I personally prefer dict literal syntax to a dict
> constructor call, but no doubt there are a number of people who feel
> as you do. In what way(s) do you find the literal syntax less
> readable, and can some simple (and backward-compatible) enhancements
> help that?
>
> I've seen criticisms (though I don't recall where) of Python,
> comparing it to JavaScript/ECMAScript, that complain of the need to
> quote the keys. IMO this is a worthwhile downside, as it allows you to
> use variables as the keys, rather than requiring (effectively) literal
> strings. But it does make a dict literal that much more "noisy" than
> the constructor.
On the other had it's more powerful. You can write {'class': 'foo'}
but cannot dict(class='bar'). {1: '1'} but not dict(1='1').
Oleg.
--
Oleg Broytmanhttp://phdru.name/[email protected]
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel wrote: > On 2012-11-14, at 19:54 , Mark Adam wrote: >> >> Merging of two dicts is done with dict.update. > > No, dict.update merges one dict (or two) into a third one. No. I think you need to read the docs. >> How do you do it on >> initialization? This doesn't make sense. > > dict(d1, **d2) That's not valid syntax is it? mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, 14 Nov 2012 14:53:11 -0600
Mark Adam wrote:
> On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel wrote:
> > On 2012-11-14, at 19:54 , Mark Adam wrote:
> >>
> >> Merging of two dicts is done with dict.update.
> >
> > No, dict.update merges one dict (or two) into a third one.
>
> No. I think you need to read the docs.
>
> >> How do you do it on
> >> initialization? This doesn't make sense.
> >
> > dict(d1, **d2)
>
> That's not valid syntax is it?
Why don't you try it for yourself:
>>> d1 = {1:2}
>>> d2 = {3:4}
>>> dict(d1, **d2)
{1: 2, 3: 4}
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 2012-11-14 20:53, Mark Adam wrote: On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel wrote: On 2012-11-14, at 19:54 , Mark Adam wrote: Merging of two dicts is done with dict.update. No, dict.update merges one dict (or two) into a third one. No. I think you need to read the docs. How do you do it on initialization? This doesn't make sense. dict(d1, **d2) That's not valid syntax is it? No. You can have dict(d1) and dict(**d2), but not dict(d1, **d2). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 2012-11-14 21:20, MRAB wrote: On 2012-11-14 20:53, Mark Adam wrote: On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel wrote: On 2012-11-14, at 19:54 , Mark Adam wrote: Merging of two dicts is done with dict.update. No, dict.update merges one dict (or two) into a third one. No. I think you need to read the docs. How do you do it on initialization? This doesn't make sense. dict(d1, **d2) That's not valid syntax is it? No. You can have dict(d1) and dict(**d2), but not dict(d1, **d2). Oops, wrong! :-( (I see now where I went wrong...) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 3:20 PM, MRAB wrote: > On 2012-11-14 20:53, Mark Adam wrote: >> >> On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel >> wrote: >>> >>> On 2012-11-14, at 19:54 , Mark Adam wrote: Merging of two dicts is done with dict.update. >>> >>> >>> No, dict.update merges one dict (or two) into a third one. >> >> >> No. I think you need to read the docs. >> How do you do it on initialization? This doesn't make sense. >>> >>> >>> dict(d1, **d2) >> >> >> That's not valid syntax is it? >> > No. > > You can have dict(d1) and dict(**d2), but not dict(d1, **d2). Yes you can. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
MRAB wrote:
On 2012-11-14 20:53, Mark Adam wrote:
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel
wrote:
On 2012-11-14, at 19:54 , Mark Adam wrote:
Merging of two dicts is done with dict.update.
No, dict.update merges one dict (or two) into a third one.
No. I think you need to read the docs.
How do you do it on
initialization? This doesn't make sense.
dict(d1, **d2)
That's not valid syntax is it?
No.
You can have dict(d1) and dict(**d2), but not dict(d1, **d2).
To (mis-)quote Antoine:
>--> d1 = {1:2}
>--> d2 = {'3':4}
>--> dict(d1, **d2)
> {1: 2, '3': 4}
Apparently it is valid syntax. Just make sure you keys for the ** operator are
valid strings. :)
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
>
> To (mis-)quote Antoine:
> >--> d1 = {1:2}
> >--> d2 = {'3':4}
> >--> dict(d1, **d2)
> > {1: 2, '3': 4}
>
> Apparently it is valid syntax. Just make sure you keys for the **
> operator are valid strings. :)
>
>
or not:
>>> dict(**{'not a valid identifier': True, 1: True})
{1: True, 'not a valid identifier': True}
brandon
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 3:40 PM, Brandon W Maister wrote:
>
>>
>> To (mis-)quote Antoine:
>> >--> d1 = {1:2}
>> >--> d2 = {'3':4}
>> >--> dict(d1, **d2)
>> > {1: 2, '3': 4}
>>
>> Apparently it is valid syntax. Just make sure you keys for the **
>> operator are valid strings. :)
>>
>
> or not:
>
dict(**{'not a valid identifier': True, 1: True})
> {1: True, 'not a valid identifier': True}
Just because the string says it's not valid doesn't mean it's not valid.
Anyway, can this thread go to python-ideas or python-list now?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 2012-11-14, at 21:53 , Mark Adam wrote: > On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel wrote: >> On 2012-11-14, at 19:54 , Mark Adam wrote: >>> >>> Merging of two dicts is done with dict.update. >> >> No, dict.update merges one dict (or two) into a third one. > > No. I think you need to read the docs. I know what the docs say. dict.update requires an existing dict and (as mutator methods usually do in Python) doesn't return anything. Thus it merges a dict (or two) into a third one (the subject of the call). >>> How do you do it on >>> initialization? This doesn't make sense. >> >> dict(d1, **d2) > > That's not valid syntax is it? Of course it is, why would it not be? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Chris Angelico wrote:
Perhaps an alternative question: What can be done to make the latter
less unpalatable?
* We could introduce a new syntax such as {a = 1, b = 2}.
* If the compiler were allowed to recognise builtins, it could
turn dict(a = 1, b = 2) into {'a':1, 'b':2} automatically.
--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
On 14/11/2012 10:11, [email protected] wrote: Zitat von Chris Withers : a_dict = dict( x = 1, y = 2, z = 3, ... ) What can we do to speed up the former case? It should be possible to special-case it. Rather than creating a new dictionary from scratch, one could try to have the new dictionary the same size as the original one, and copy all entries. Indeed, Doug, what are your views on this? Also, did you have a real-world example where this speed difference was causing you a problem? I don't know how much this would gain, though. You still have to create two dictionary objects. For a better speedup, try def xdict(**kwds): return kwds Hah, good call, this trumps both of the other options: $ python2.7 -m timeit -n 100 -r 5 -v "{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}" raw times: 1.45 1.45 1.44 1.45 1.45 100 loops, best of 5: 1.44 usec per loop $ python2.6 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' raw times: 2.37 2.36 2.36 2.37 2.37 100 loops, best of 5: 2.36 usec per loop$ python2.6 -m timeit -n 100 -r 5 -v 'def md(**kw): return kw; md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' raw times: 0.548 0.533 0.55 0.577 0.539 100 loops, best of 5: 0.533 usec per loop For the naive observer (ie: me!), why is that? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 14/11/2012 21:40, Greg Ewing wrote:
* If the compiler were allowed to recognise builtins, it could
turn dict(a = 1, b = 2) into {'a':1, 'b':2} automatically.
That would be my naive suggestion, I am prepared to be shot down in
flames ;-)
Would be even more awesome if it could end up with the magical
performance of "def md(**kw): return kw"...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
On 14/11/2012 22:37, Chris Withers wrote: On 14/11/2012 10:11, [email protected] wrote: def xdict(**kwds): return kwds Hah, good call, this trumps both of the other options: $ python2.7 -m timeit -n 100 -r 5 -v "{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}" raw times: 1.45 1.45 1.44 1.45 1.45 100 loops, best of 5: 1.44 usec per loop $ python2.6 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' raw times: 2.37 2.36 2.36 2.37 2.37 100 loops, best of 5: 2.36 usec per loop$ python2.6 -m timeit -n 100 -r 5 -v 'def md(**kw): return kw; md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' raw times: 0.548 0.533 0.55 0.577 0.539 100 loops, best of 5: 0.533 usec per loop Before anyone shoots me, yes, wrong python for two of them: $ python2.7 -m timeit -n 100 -r 5 -v "{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}" raw times: 1.49 1.49 1.5 1.49 1.48 100 loops, best of 5: 1.48 usec per loop $ python2.7 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' raw times: 2.35 2.36 2.41 2.42 2.35 100 loops, best of 5: 2.35 usec per loop $ python2.7 -m timeit -n 100 -r 5 -v 'def md(**kw): return kw; md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' raw times: 0.507 0.515 0.516 0.529 0.524 100 loops, best of 5: 0.507 usec per loop Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 2012-11-14 21:40, Greg Ewing wrote:
Chris Angelico wrote:
Perhaps an alternative question: What can be done to make the latter
less unpalatable?
* We could introduce a new syntax such as {a = 1, b = 2}.
* If the compiler were allowed to recognise builtins, it could
turn dict(a = 1, b = 2) into {'a':1, 'b':2} automatically.
That would be a transformation of the AST, although it assumes that
'dict' hasn't been rebound.
Should there be the option of a warning if a builtin is rebound? Or the
option of the transformation plus a warning if the builtin is rebound?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
$ pypy -m timeit 'dict()'
10 loops, best of 3: 0.000811 usec per loop
$ pypy -m timeit '{}'
10 loops, best of 3: 0.000809 usec per loop
$ pypy -m timeit 'def md(**kw): return kw; md()'
1 loops, best of 3: 0.0182 usec per loop
$ pypy -m timeit -s 'def md(**kw): return kw' 'md()'
10 loops, best of 3: 0.00136 usec per loop
If the difference between dict() and {} is hurting your code why are
you still using CPython.
On Wednesday, November 14, 2012 at 5:51 PM, MRAB wrote:
> On 2012-11-14 21:40, Greg Ewing wrote:
> > Chris Angelico wrote:
> > > Perhaps an alternative question: What can be done to make the latter
> > > less unpalatable?
> > >
> >
> >
> > * We could introduce a new syntax such as {a = 1, b = 2}.
> >
> > * If the compiler were allowed to recognise builtins, it could
> > turn dict(a = 1, b = 2) into {'a':1, 'b':2} automatically.
> >
>
> That would be a transformation of the AST, although it assumes that
> 'dict' hasn't been rebound.
>
> Should there be the option of a warning if a builtin is rebound? Or the
> option of the transformation plus a warning if the builtin is rebound?
> ___
> Python-Dev mailing list
> [email protected] (mailto:[email protected])
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
On 2012-11-14, at 23:43 , Chris Withers wrote: > On 14/11/2012 22:37, Chris Withers wrote: >> On 14/11/2012 10:11, [email protected] wrote: >>> def xdict(**kwds): >>> return kwds >> >> Hah, good call, this trumps both of the other options: >> >> $ python2.7 -m timeit -n 100 -r 5 -v >> "{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}" >> raw times: 1.45 1.45 1.44 1.45 1.45 >> 100 loops, best of 5: 1.44 usec per loop >> $ python2.6 -m timeit -n 100 -r 5 -v >> 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' >> raw times: 2.37 2.36 2.36 2.37 2.37 >> 100 loops, best of 5: 2.36 usec per loop$ python2.6 -m timeit -n >> 100 -r 5 -v 'def md(**kw): return kw; md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' >> raw times: 0.548 0.533 0.55 0.577 0.539 >> 100 loops, best of 5: 0.533 usec per loop > > Before anyone shoots me, yes, wrong python for two of them: > > $ python2.7 -m timeit -n 100 -r 5 -v > "{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}" > raw times: 1.49 1.49 1.5 1.49 1.48 > 100 loops, best of 5: 1.48 usec per loop > > $ python2.7 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' > raw times: 2.35 2.36 2.41 2.42 2.35 > 100 loops, best of 5: 2.35 usec per loop > > $ python2.7 -m timeit -n 100 -r 5 -v 'def md(**kw): return kw; > md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' > raw times: 0.507 0.515 0.516 0.529 0.524 > 100 loops, best of 5: 0.507 usec per loop The last one is kind-of weird, it seems to be greatly advantaged by the local lookup: > python2.7 -m timeit -n 100 -r 5 -v > "{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}" raw times: 0.676 0.683 0.682 0.698 0.691 100 loops, best of 5: 0.676 usec per loop > python2.7 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' > raw times: 1.64 1.66 1.4 1.44 1.44 100 loops, best of 5: 1.4 usec per loop > python2.7 -m timeit -n 100 -r 5 -v 'def md(**kw): return kw; > md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' raw times: 0.188 0.203 0.201 0.195 0.202 100 loops, best of 5: 0.188 usec per loop > python2.7 -m timeit -n 100 -r 5 -v -s 'def md(**kw): return kw' > 'md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' raw times: 0.871 0.864 0.863 0.889 0.871 100 loops, best of 5: 0.863 usec per loop ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 15/11/12 05:54, Mark Adam wrote:
Merging of two dicts is done with dict.update. How do you do it on
initialization? This doesn't make sense.
Frequently.
my_prefs = dict(default_prefs, setting=True, another_setting=False)
Notice that I'm not merging one dict into another, but merging two dicts
into a third.
(Well, technically, one of the two comes from keyword arguments rather
than an actual dict, but the principle is the same.)
The Python 1.5 alternative was:
my_prefs = {}
my_prefs.update(default_prefs)
my_prefs['setting'] = True
my_prefs['another_setting'] = False
Blah, I'm so glad I don't have to write Python 1.5 code any more. Even
using copy only saves a line:
my_prefs = default_prefs.copy()
my_prefs['setting'] = True
my_prefs['another_setting'] = False
--
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Notice that {'x':1} and dict(x=1) are different beasts: The first one
compiles directly to BUILD_MAP. The second one loads a reference to 'dict'
from globals() and calls the constructor. The two are not the same.
2012/11/15 Steven D'Aprano
> On 15/11/12 05:54, Mark Adam wrote:
>
> Merging of two dicts is done with dict.update. How do you do it on
>> initialization? This doesn't make sense.
>>
>
> Frequently.
>
> my_prefs = dict(default_prefs, setting=True, another_setting=False)
>
>
> Notice that I'm not merging one dict into another, but merging two dicts
> into a third.
>
> (Well, technically, one of the two comes from keyword arguments rather
> than an actual dict, but the principle is the same.)
>
> The Python 1.5 alternative was:
>
> my_prefs = {}
> my_prefs.update(default_prefs)
> my_prefs['setting'] = True
> my_prefs['another_setting'] = False
>
>
> Blah, I'm so glad I don't have to write Python 1.5 code any more. Even
> using copy only saves a line:
>
> my_prefs = default_prefs.copy()
> my_prefs['setting'] = True
> my_prefs['another_setting'] = False
>
>
>
>
> --
> Steven
>
> __**_
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> lukas.lueg%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Thu, Nov 15, 2012 at 10:36 AM, Steven D'Aprano wrote:
> On 15/11/12 05:54, Mark Adam wrote:
>
>> Merging of two dicts is done with dict.update. How do you do it on
>> initialization? This doesn't make sense.
>
>
> Frequently.
>
> my_prefs = dict(default_prefs, setting=True, another_setting=False)
>
>
> Notice that I'm not merging one dict into another, but merging two dicts
> into a third.
Side point: Wouldn't it be quite logical to support dict addition?
>>> {"a":1}+{"b":2}
Traceback (most recent call last):
File "", line 1, in
{"a":1}+{"b":2}
TypeError: unsupported operand type(s) for +: 'dict' and 'dict'
It would make sense for this to result in {"a":1,"b":2}.
ChrisA
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 11/14/2012 4:12 AM, Chris Withers wrote:
To somewhat paraphrase: '''
I prefer 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' to
"{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}".
I am sad that the former takes +-2 times as long to run (in 2.7).
Is the difference about the same in 3.x?
What can we do to speed up the former case?
'''
My responses, trying not to duplicate others.
1. Visual preference depends on the viewer. I prefer the dict display,
perhaps because I am more accustomed to it.
2. The two types of expressions have overlapping but distinct use cases.
This differences include that dict can be wrapped or replaced, while
displays cannot.
3. a) 3.x has dict comprehensions. How do they stack up? b) If one were
really initializing multiple dicts with the same starting items, and one
were really concerned about speed, should one calculate the common base
dict just once and then copy? Win7 64 with 3.3.0:
>>> repeat("dict(a=1, b=2, c=3, d=4, e=5)")
[0.6200045004915467, 0.6212762582470646, 0.6114683222573376]
>>> repeat("{'a': 1, 'b': 2, 'c': 3, 'd': 4, 'e': 5}")
[0.27170026972208233, 0.2594874604131968, 0.25977058559879584]
>>> repeat("d.copy()", "d={'a': 1, 'b': 2, 'c': 3, 'd': 4, 'e': 5}")
[0.25768296004457625, 0.243041299387869, 0.2421860830290825]
>>> repeat("{str(i):i for i in range(10)}")
[4.914327732926495, 4.874041570524014, 4.871596119002334]
>>> repeat("{'0':0, '1':1, '2':2, '3':3, '4':4, '5':5, '6':6, '7':7,
'8':8, '9':9}")
[0.5207065648769458, 0.5000415004344632, 0.49980294978922757]
>>> repeat("d.copy()", "d={'0':0, '1':1, '2':2, '3':3, '4':4, '5':5,
'6':6, '7':7, '8':8, '9':9}")
[0.571671864980317, 0.5516194699132484, 0.5514937389677925]
Assuming no overlooked errors in the above...
a) Dict comprehensions are much slower than calls, which makes the calls
look good by comparison. b) Copying is not worthwhile.
4. There are about 3000 issues on the tracker. Nearly all are worth more
attention than this ;-).
--
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 5:40 PM, Chris Angelico wrote: > On Thu, Nov 15, 2012 at 10:36 AM, Steven D'Aprano wrote: >> On 15/11/12 05:54, Mark Adam wrote: >> Notice that I'm not merging one dict into another, but merging two dicts >> into a third. > > Side point: Wouldn't it be quite logical to support dict addition? > Yes, but then you'd be in my old argument that dict should inherit from set. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Chris Angelico writes:
> >>> {"a":1}+{"b":2}
> It would make sense for this to result in {"a":1,"b":2}.
The test is not "does this sometimes make sense?" It's "does this
ever result in nonsense, and if so, do we care?"
Here, addition is usually commutative. Should {'a':1}+{'a':2} be the
same as, or different from, {'a':2}+{'a':1}, or should it be an error?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Thu, Nov 15, 2012 at 1:28 PM, Stephen J. Turnbull wrote:
> Chris Angelico writes:
>
> > >>> {"a":1}+{"b":2}
>
> > It would make sense for this to result in {"a":1,"b":2}.
>
> The test is not "does this sometimes make sense?" It's "does this
> ever result in nonsense, and if so, do we care?"
>
> Here, addition is usually commutative. Should {'a':1}+{'a':2} be the
> same as, or different from, {'a':2}+{'a':1}, or should it be an error?
>>> "a"+"b"
'ab'
>>> "b"+"a"
'ba'
I would say that the two dictionary examples are equally allowed to
give different results - that they should be equivalent to (shallow)
copy followed by update(), but possibly more efficiently.
ChrisA
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On Wed, Nov 14, 2012 at 8:28 PM, Stephen J. Turnbull wrote:
> Chris Angelico writes:
>
> > >>> {"a":1}+{"b":2}
>
> > It would make sense for this to result in {"a":1,"b":2}.
>
> The test is not "does this sometimes make sense?" It's "does this
> ever result in nonsense, and if so, do we care?"
>
> Here, addition is usually commutative. Should {'a':1}+{'a':2} be the
> same as, or different from, {'a':2}+{'a':1}, or should it be an error?
Easy: dict should have a (user substitutable) collision function that
is called in these cases. This would allow significant functionality
with practically no cost. In addition, it could be implemented in
such a way as to offer significant speedups (when using dict.update
for example) over any possible hand-written substitutes (since it's
only run on key collisions and otherwise uses an underlying loop coded
in C).
mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Chris Angelico writes:
> On Thu, Nov 15, 2012 at 1:28 PM, Stephen J. Turnbull
> wrote:
> > Chris Angelico writes:
> >
> > > >>> {"a":1}+{"b":2}
> >
> > > It would make sense for this to result in {"a":1,"b":2}.
> >
> > The test is not "does this sometimes make sense?" It's "does this
> > ever result in nonsense, and if so, do we care?"
> >
> > Here, addition is usually commutative. Should {'a':1}+{'a':2} be the
> > same as, or different from, {'a':2}+{'a':1}, or should it be an error?
>
> >>> "a"+"b"
> 'ab'
> >>> "b"+"a"
> 'ba'
>
> I would say that the two dictionary examples are equally allowed to
> give different results - that they should be equivalent to (shallow)
> copy followed by update(), but possibly more efficiently.
I wouldn't. A string is a sequence of uninterpreted letters, and
necessarily ordered. In fact, that's about all you can say about
strings in general. I would prefer that concatenation be expressed by
juxtaposition, but that's troublesome for machine parsing (especially
error recovery). My intuition is elastic enough to admit exceptional
cases where the essential ordered nature of the objects being "added"
is more important than the customary interpretation of the operator
symbol, so interpreting string addition as concatenation doesn't
bother me. Furthermore, in string addition both operands affect the
result in proportion to their content, though differently.
Dictionaries aren't ordered, and their "elements" have structure
(key-value pairs). It would definitely bother me if dictionary
addition weren't commutative, and it's worse that an operand affects
the outcome in an all-or-nothing way.
Also, "update" is more appropriately expressed by an extended
assignment operator. Defining "+" in terms of "+=" as you propose
just doesn't seem right to me.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Mark Adam writes: > Easy: dict should have a (user substitutable) collision function that > is called in these cases. "I smell overengineering." > This would allow significant functionality with practically no > cost. We already have that functionality if we want it; just define an appropriate mapping class. I don't need or want it, so I can ignore it, but I suspect to get anywhere with this proposal you're going to need to show that this "significant functionality" needs to be in syntax. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Zitat von Chris Withers :
On 14/11/2012 21:40, Greg Ewing wrote:
* If the compiler were allowed to recognise builtins, it could
turn dict(a = 1, b = 2) into {'a':1, 'b':2} automatically.
That would be my naive suggestion, I am prepared to be shot down in
flames ;-)
In general, special-casing builtins in the compiler is not possible
in Python. You cannot know statically that 'dict' really refers to
the builtin. Something may shadow the name at run-time, making dict
refer to some other callable.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
Zitat von Chris Withers :
$ python2.7 -m timeit -n 100 -r 5 -v
"{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}"
raw times: 1.49 1.49 1.5 1.49 1.48
100 loops, best of 5: 1.48 usec per loop
$ python2.7 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
raw times: 2.35 2.36 2.41 2.42 2.35
100 loops, best of 5: 2.35 usec per loop
$ python2.7 -m timeit -n 100 -r 5 -v 'def md(**kw): return kw;
md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
raw times: 0.507 0.515 0.516 0.529 0.524
100 loops, best of 5: 0.507 usec per loop
For the naive observer (ie: me!), why is that?
It's faster than calling dict() because the dict code will
create a second dictionary, and discard the keywords dictionary.
It's (probably) faster than the dictionary display, because
the {} byte code builds the dictionary one-by-one, whereas
the keywords dictionary is built in a single step (taking
all keys and values from the evaluation stack).
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Zitat von Chris Angelico :
On Thu, Nov 15, 2012 at 1:28 PM, Stephen J. Turnbull
wrote:
Chris Angelico writes:
> >>> {"a":1}+{"b":2}
> It would make sense for this to result in {"a":1,"b":2}.
The test is not "does this sometimes make sense?" It's "does this
ever result in nonsense, and if so, do we care?"
Here, addition is usually commutative. Should {'a':1}+{'a':2} be the
same as, or different from, {'a':2}+{'a':1}, or should it be an error?
"a"+"b"
'ab'
"b"+"a"
'ba'
I would say that the two dictionary examples are equally allowed to
give different results - that they should be equivalent to (shallow)
copy followed by update(), but possibly more efficiently.
Can this be moved to python-ideas, please?
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Donald Stufft, 15.11.2012 00:00:
> $ pypy -m timeit 'dict()'
> 10 loops, best of 3: 0.000811 usec per loop
>
> $ pypy -m timeit '{}'
> 10 loops, best of 3: 0.000809 usec per loop
>
> $ pypy -m timeit 'def md(**kw): return kw; md()'
> 1 loops, best of 3: 0.0182 usec per loop
>
> $ pypy -m timeit -s 'def md(**kw): return kw' 'md()'
> 10 loops, best of 3: 0.00136 usec per loop
Yep, I really like the fact that optimisers can fold stupid benchmarks into
no-ops. I wonder why it fails so badly in the latter two cases, though. You
should bring that to the attention of the PyPy developers, they might want
to fix it.
Stefan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 15/11/2012 06:32, Stefan Behnel wrote:
Donald Stufft, 15.11.2012 00:00:
$ pypy -m timeit 'dict()'
10 loops, best of 3: 0.000811 usec per loop
$ pypy -m timeit '{}'
10 loops, best of 3: 0.000809 usec per loop
$ pypy -m timeit 'def md(**kw): return kw; md()'
1 loops, best of 3: 0.0182 usec per loop
$ pypy -m timeit -s 'def md(**kw): return kw' 'md()'
10 loops, best of 3: 0.00136 usec per loop
Yep, I really like the fact that optimisers can fold stupid benchmarks into
no-ops. I wonder why it fails so badly in the latter two cases, though. You
should bring that to the attention of the PyPy developers, they might want
to fix it.
Agreed, but Donald, please try with a bunch of keys rather than an empty
dict...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
Chris Withers, 15.11.2012 08:14:
> On 15/11/2012 06:32, Stefan Behnel wrote:
>> Donald Stufft, 15.11.2012 00:00:
>>> $ pypy -m timeit 'dict()'
>>> 10 loops, best of 3: 0.000811 usec per loop
>>>
>>> $ pypy -m timeit '{}'
>>> 10 loops, best of 3: 0.000809 usec per loop
>>>
>>> $ pypy -m timeit 'def md(**kw): return kw; md()'
>>> 1 loops, best of 3: 0.0182 usec per loop
>>>
>>> $ pypy -m timeit -s 'def md(**kw): return kw' 'md()'
>>> 10 loops, best of 3: 0.00136 usec per loop
>>
>> Yep, I really like the fact that optimisers can fold stupid benchmarks into
>> no-ops. I wonder why it fails so badly in the latter two cases, though. You
>> should bring that to the attention of the PyPy developers, they might want
>> to fix it.
>
> Agreed, but Donald, please try with a bunch of keys rather than an empty
> dict...
Right. If that makes a difference, it's another bug.
Stefan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance of {} versus dict()
On 15.11.12 01:47, Terry Reedy wrote: 4. There are about 3000 issues on the tracker. Nearly all are worth more attention than this ;-). This is the best conclusion of this thread. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
