Hi all,
I ran into the follow behavior while making sure Django works
correctly on PyPy. The following behavior was observed in all tested
versions of CPython (2.5, 3.1):
>>> def f(**kwargs):
... print(kwargs)
...
>>> kwargs = {1: 3}
>>>
>>> dict({}, **kwargs)
{1: 3}
>>> f(**kwargs)
Tracebac
On Fri, Apr 16, 2010 at 12:57:06AM -0400, Alex Gaynor wrote:
> >>> def f(**kwargs):
> ... print(kwargs)
> ...
> >>> kwargs = {1: 3}
> >>>
> >>> dict({}, **kwargs)
> {1: 3}
> >>> f(**kwargs)
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: f() keywords must be strings
> This behavior seems pretty strange to me, indeed PyPy gives the
> TypeError for both attempts. I just wanted to confirm that it was in
> fact intentional.
Oleg already answered why f(**{1:3}) raises a TypeError. But your
question seems to be rather why dict(**{1:3}) doesn't.
For functions impl
On Fri, Apr 16, 2010 at 9:04 AM, Hagen Fürstenau wrote:
>> This behavior seems pretty strange to me, indeed PyPy gives the
>> TypeError for both attempts. I just wanted to confirm that it was in
>> fact intentional.
>
> Oleg already answered why f(**{1:3}) raises a TypeError. But your
> question
Mark Dickinson wrote:
> "dict(x, **y)" as an expression version of x.update(y) seems to be
> fairly well known[1], so disallowing non-string keyword arguments
> seems likely to break existing code, as well as (probably?) harming
> performance. So I can't see CPython changing here. I'm not sure
>
On Fri, Apr 16, 2010 at 7:15 AM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> "dict(x, **y)" as an expression version of x.update(y) seems to be
>> fairly well known[1], so disallowing non-string keyword arguments
>> seems likely to break existing code, as well as (probably?) harming
>> performa
On Fri, Apr 16, 2010 at 3:33 PM, Guido van Rossum wrote:
> On Fri, Apr 16, 2010 at 7:15 AM, Nick Coghlan wrote:
>> I would agree with leaving it implementation defined - I don't think
>> either PyPy or CPython should be forced to change their current
>> behaviour in relation to this. A minor note
On Fri, Apr 16, 2010 at 12:57 AM, Alex Gaynor wrote:
> Hi all,
>
> I ran into the follow behavior while making sure Django works
> correctly on PyPy. The following behavior was observed in all tested
> versions of CPython (2.5, 3.1):
>
def f(**kwargs):
> ... print(kwargs)
> ...
kwar
Mark Dickinson gmail.com> writes:
>
> Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
>
> Can this sneak in under the 'incorrect language semantics' exemption
> for PEP 3003 (the moratorium PEP)? If not, then deprecation
> presumably has to wait for 3.3.
It seems that in s
On Fri, Apr 16, 2010 at 3:57 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>>
>> Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
>>
>> Can this sneak in under the 'incorrect language semantics' exemption
>> for PEP 3003 (the moratorium PEP)? If not, then depr
On 16/04/2010 17:06, Mark Dickinson wrote:
On Fri, Apr 16, 2010 at 3:57 PM, Antoine Pitrou wrote:
Mark Dickinson gmail.com> writes:
Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
Can this sneak in under the 'incorrect language semantics' exemption
for PEP 300
On Friday, April 16, 2010, at 04:57PM, "Antoine Pitrou"
wrote:
>Mark Dickinson gmail.com> writes:
>>
>> Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
>>
>> Can this sneak in under the 'incorrect language semantics' exemption
>> for PEP 3003 (the moratorium PEP)? If no
Mark Dickinson wrote:
> Removing it certainly seems in keeping with the goal of making life
> easier for alternate implementations. (Out of curiosity, does anyone
> know what IronPython does here?)
>
> I've opened http://bugs.python.org/issue8419
It looks like IronPython reports a type error a
Guido van Rossum, 16.04.2010 16:33:
I am fine with
declaring dict({}, **{1:3}) illegal, since after all it is abuse of
the ** mechanism.
It's a bit like letting keys like 'not-an-identifier' pass through, though,
isn't it?
Stefan
___
Python-Dev ma
On Fri, Apr 16, 2010 at 8:35 AM, Stefan Behnel wrote:
> Guido van Rossum, 16.04.2010 16:33:
>>
>> I am fine with
>> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
>> the ** mechanism.
>
> It's a bit like letting keys like 'not-an-identifier' pass through, though,
> isn't it?
On Fri, Apr 16, 2010 at 8:22 AM, Ronald Oussoren wrote:
>
> On Friday, April 16, 2010, at 04:57PM, "Antoine Pitrou"
> wrote:
>>Mark Dickinson gmail.com> writes:
>>>
>>> Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
>>>
>>> Can this sneak in under the 'incorrect language s
On 4/16/2010 11:22 AM, Dino Viehland wrote:
Mark Dickinson wrote:
Removing it certainly seems in keeping with the goal of making life
easier for alternate implementations. (Out of curiosity, does anyone
know what IronPython does here?)
I've opened http://bugs.python.org/issue8419
It looks l
>> Guido van Rossum, 16.04.2010 16:33:
>>>
>>> I am fine with
>>> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
>>> the ** mechanism.
ISTM that making it illegal costs cycles with giving any real benefit.
It is reasonably common to accept **kwds and then pass it down
to ano
2010/4/16 Raymond Hettinger :
>
>>> Guido van Rossum, 16.04.2010 16:33:
I am fine with
declaring dict({}, **{1:3}) illegal, since after all it is abuse of
the ** mechanism.
>
> ISTM that making it illegal costs cycles with giving any real benefit.
> It is reasonably common to ac
On Fri, Apr 16, 2010 at 2:11 PM, Raymond Hettinger
wrote:
>
>>> Guido van Rossum, 16.04.2010 16:33:
I am fine with
declaring dict({}, **{1:3}) illegal, since after all it is abuse of
the ** mechanism.
>
> ISTM that making it illegal costs cycles with giving any real benefit.
D
On Fri, Apr 16, 2010 at 3:11 PM, Raymond Hettinger
wrote:
>
>>> Guido van Rossum, 16.04.2010 16:33:
I am fine with
declaring dict({}, **{1:3}) illegal, since after all it is abuse of
the ** mechanism.
>
> ISTM that making it illegal costs cycles with giving any real benefit.
>
On Fri, Apr 16, 2010 at 2:22 PM, Maciej Fijalkowski wrote:
> On Fri, Apr 16, 2010 at 3:11 PM, Raymond Hettinger
> wrote:
>>
Guido van Rossum, 16.04.2010 16:33:
>
> I am fine with
> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
> the ** mechanism.
>>
>> I
On Fri, Apr 16, 2010 at 4:11 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> ISTM that making it illegal costs cycles with giving any real benefit.
> It is reasonably common to accept **kwds and then pass it down
> to another function. Do we want to validate the keys of every
> kwds
2010/4/16 Daniel Stutzbach :
> On Fri, Apr 16, 2010 at 4:11 PM, Raymond Hettinger
> wrote:
>>
>> ISTM that making it illegal costs cycles with giving any real benefit.
>> It is reasonably common to accept **kwds and then pass it down
>> to another function. Do we want to validate the keys of ever
> On Fri, Apr 16, 2010 at 2:11 PM, Raymond Hettinger
> wrote:
>>
Guido van Rossum, 16.04.2010 16:33:
>
> I am fine with
> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
> the ** mechanism.
>>
>> ISTM that making it illegal costs cycles with giving any
On Fri, Apr 16, 2010 at 4:51 PM, Benjamin Peterson wrote:
> 2010/4/16 Daniel Stutzbach :
> > IIRC, there's a performance hack in dictobject.c that keeps track of
> whether
> > all of the keys are strings or not. The hack is designed so that lookup
> > operations can call the string compare/hash f
At 04:51 PM 4/16/2010 -0500, Benjamin Peterson wrote:
That won't work. You could put non-string keys in a dictionary and
remove them, but the dictionary would still be in the less optimized state.
That only means it's slower on uncommon cases and the case where
you're about to get an exception
Raymond Hettinger gmail.com> writes:
>
> Would hate for 100% of users will pay a performance penalty
> when most applications aren't abusing keyword dictionaries
> so they already work cross-platfrom.
Someone should provide actual measurements before we start a psychodrama about
Python performa
On Apr 16, 2010, at 2:42 PM, Daniel Stutzbach wrote:
>
> IIRC, there's a performance hack in dictobject.c that keeps track of whether
> all of the keys are strings or not. The hack is designed so that lookup
> operations can call the string compare/hash functions directly if possible,
> rathe
Raymond Hettinger wrote:
>
> On Apr 16, 2010, at 2:42 PM, Daniel Stutzbach wrote:
>>
>> IIRC, there's a performance hack in dictobject.c that keeps track of
>> whether all of the keys are strings or not. The hack is designed so
>> that lookup operations can call the string compare/hash functions
On 17/04/2010 01:38, Steve Holden wrote:
Raymond Hettinger wrote:
On Apr 16, 2010, at 2:42 PM, Daniel Stutzbach wrote:
IIRC, there's a performance hack in dictobject.c that keeps track of
whether all of the keys are strings or not. The hack is designed so
that lookup operations can c
Daniel Stutzbach wrote:
Unless you're saying you often create a dictionary, add non-string keys,
remove the non-string keys, then pass it as a **kwds? ;-)
I think the point is that it would create a very mysterious
potential failure mode. What would you make of a situation
where Python says "T
On 17/04/2010 02:43, Greg Ewing wrote:
Daniel Stutzbach wrote:
Unless you're saying you often create a dictionary, add non-string
keys, remove the non-string keys, then pass it as a **kwds? ;-)
I think the point is that it would create a very mysterious
potential failure mode. What would you
On Fri, Apr 16, 2010 at 2:56 PM, Raymond Hettinger
wrote:
>
>> On Fri, Apr 16, 2010 at 2:11 PM, Raymond Hettinger
>> wrote:
>>>
> Guido van Rossum, 16.04.2010 16:33:
>>
>> I am fine with
>> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
>> the ** mechanism
Steve Holden wrote:
> I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
>
def f(**kwargs):
> ... kwargs[1] = "dummy"
> ... print(kwargs)
> ...
f(this="Guido", that="Raymond", the_other="Steve")
> {'this': 'Guido', 1: 'dummy', 'the_other': 'Steve', 'that': 'Raymond'}
On 16 Apr 2010, at 23:31 , Guido van Rossum wrote:
>
> +1.
>
> Apparently dict(x, **y) is going around as "cool hack" for "call
> x.update(y) and return x". Personally I find it more despicable than
> cool.
This description doesn't make sense since `dict(x, **y)` returns not
an updated `x` but a
Steve Holden holdenweb.com> writes:
> I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
>
> >>> def f(**kwargs):
> ... kwargs[1] = "dummy"
> ... print(kwargs)
> ...
> >>> f(this="Guido", that="Raymond", the_other="Steve")
> {'this': 'Guido', 1: 'dummy', 'the_other': 'Steve'
On Fri, Apr 16, 2010 at 4:38 PM, Steve Holden wrote:
> I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
>
def f(**kwargs):
> ... kwargs[1] = "dummy"
> ... print(kwargs)
> ...
f(this="Guido", that="Raymond", the_other="Steve")
> {'this': 'Guido', 1: 'dummy', 'the_ot
Guido van Rossum wrote:
> On Fri, Apr 16, 2010 at 4:38 PM, Steve Holden wrote:
>> I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
>>
> def f(**kwargs):
>> ... kwargs[1] = "dummy"
>> ... print(kwargs)
>> ...
> f(this="Guido", that="Raymond", the_other="Steve")
>> {'t
On Sat, Apr 17, 2010 at 5:41 AM, Vinay Sajip wrote:
> Steve Holden holdenweb.com> writes:
>
>> I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
>>
>> >>> def f(**kwargs):
>> ... kwargs[1] = "dummy"
>> ... print(kwargs)
>> ...
>> >>> f(this="Guido", that="Raymond", the_other
Guido van Rossum wrote:
> Because Python promises that the object the callee sees as 'kwargs' is
> "just a dict".
Huh, I thought kwargs was allowed to be implemented as a
string-keys-only dict (similar to class and module namespaces) while
still be a valid Python implementation. I guess I was wron
On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan wrote:
> Guido van Rossum wrote:
>> Because Python promises that the object the callee sees as 'kwargs' is
>> "just a dict".
>
> Huh, I thought kwargs was allowed to be implemented as a
> string-keys-only dict (similar to class and module namespaces) w
2010/4/17 Guido van Rossum :
> On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan wrote:
>> Guido van Rossum wrote:
>>> Because Python promises that the object the callee sees as 'kwargs' is
>>> "just a dict".
>>
>> Huh, I thought kwargs was allowed to be implemented as a
>> string-keys-only dict (simi
Benjamin wrote:
> 2010/4/17 Guido van Rossum :
> > On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan
> wrote:
> >> Guido van Rossum wrote:
> >>> Because Python promises that the object the callee sees as 'kwargs'
> is
> >>> "just a dict".
> >>
> >> Huh, I thought kwargs was allowed to be implemented a
On Sat, Apr 17, 2010 at 11:38 AM, Dino Viehland wrote:
> Benjamin wrote:
>> 2010/4/17 Guido van Rossum :
>> > On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan
>> wrote:
>> >> Guido van Rossum wrote:
>> >>> Because Python promises that the object the callee sees as 'kwargs'
>> is
>> >>> "just a dict"
Maciej wrote:
> On Sat, Apr 17, 2010 at 11:38 AM, Dino Viehland
> wrote:
> > Benjamin wrote:
> >> 2010/4/17 Guido van Rossum :
> >> > On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan
> >> wrote:
> >> >> Guido van Rossum wrote:
> >> >>> Because Python promises that the object the callee sees as
> 'kw
On Sat, Apr 17, 2010 at 12:03 PM, Dino Viehland wrote:
> Maciej wrote:
>> On Sat, Apr 17, 2010 at 11:38 AM, Dino Viehland
>> wrote:
>> > Benjamin wrote:
>> >> 2010/4/17 Guido van Rossum :
>> >> > On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan
>> >> wrote:
>> >> >> Guido van Rossum wrote:
>> >> >>
Dino Viehland wrote:
> Maciej wrote:
[...]
>> And yet that breaks some code :-)
>
> Sure, if you do:
>
> class C(object):
> locals()[object()] = 42
>
> dir(C)
>
> You lose. Once I'm aware of some piece of code in the wild doing this
> then I'll be happy to change IronPython to be more comp
On Sat, Apr 17, 2010 at 1:03 PM, Steve Holden wrote:
> Dino Viehland wrote:
>> Maciej wrote:
> [...]
>>> And yet that breaks some code :-)
>>
>> Sure, if you do:
>>
>> class C(object):
>> locals()[object()] = 42
>>
>> dir(C)
>>
>> You lose. Once I'm aware of some piece of code in the wild doi
On Sun, 18 Apr 2010 07:47:08 am Maciej Fijalkowski wrote:
> On Sat, Apr 17, 2010 at 1:03 PM, Steve Holden
wrote:
> > Dino Viehland wrote:
> >> Maciej wrote:
> >
> > [...]
> >
> >>> And yet that breaks some code :-)
> >>
> >> Sure, if you do:
> >>
> >> class C(object):
> >> locals()[object()]
50 matches
Mail list logo
