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
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
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
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.
___
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 th
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 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 libra
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,
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:
63 matches
Mail list logo
