On Nov 14, 2012, at 5:37 PM, Chris Withers wrote:
> On 14/11/2012 10:11, mar...@v.loewis.de 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
Stefan Behnel wrote:
This should work as long as this still creates a copy of d at some point:
d = {...}
dict(**d)
It will -- the implementation of the function call opcode always
creates a new keyword dict for passing to the called function.
--
Greg
__
On 15/11/2012 4:21pm, Terry Reedy wrote:
I was thinking that CPython could check the ref count of the input
keyword dict to determine whether it is newly created and can be
returned or is pre-existing and must be copied. But it seems not so.
>>> def d(**x): return sys.getrefcount(x)
>>> impor
On 11/15/2012 9:58 AM, Stefan Behnel wrote:
Greg Ewing, 15.11.2012 11:48:
mar...@v.loewis.de wrote:
It's faster than calling dict() because the dict code will
create a second dictionary, and discard the keywords dictionary.
Perhaps in the case where dict() is called with keyword
args only, it
Stefan Behnel behnel.de> writes:
> Right. If that makes a difference, it's another bug.
>
> Stefan
>
>
It's fixed, with, I will note, fewer lines of code than many messages in this
thread:
https://bitbucket.org/pypy/pypy/changeset/c30cb1dcb7a9adc32548fd14274e4995
Alex
__
Greg Ewing, 15.11.2012 11:48:
> mar...@v.loewis.de wrote:
>> It's faster than calling dict() because the dict code will
>> create a second dictionary, and discard the keywords dictionary.
>
> Perhaps in the case where dict() is called with keyword
> args only, it could just return the passed-in ke
mar...@v.loewis.de wrote:
It's faster than calling dict() because the dict code will
create a second dictionary, and discard the keywords dictionary.
Perhaps in the case where dict() is called with keyword
args only, it could just return the passed-in keyword
dictionary instead of creating anot
Hi,
I posted this (by accident) off the list:
> 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, mar...@v.loewis.de wrote:
def xdict(**kwds):
return kwds
>>>
>>> Hah, good call, this trumps both of the other options
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
Python-Dev@python.org
http://mail.python.o
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
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, b
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
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
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
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-ca
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
appropr
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
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?"
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?"
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
sam
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 sup
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
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=F
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
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 t
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, mar...@v.loewis.de 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
>> "{
$ 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
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)
On 14/11/2012 22:37, Chris Withers wrote:
On 14/11/2012 10:11, mar...@v.loewis.de 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.
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 t
On 14/11/2012 10:11, mar...@v.loewis.de 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
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.
--
G
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 r
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:
>
>
> 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 val
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 do
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 on
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 yo
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
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 y
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?
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:
> >
> >
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 ma
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
>
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
> **kw
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
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 d
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 probab
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 ex
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 no
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 = {
>>>
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 s
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,
>>
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
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_di
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(
> >
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
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,
>>
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 h
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 sp
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,
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 r
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 or
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 sec
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
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:
66 matches
Mail list logo
