Re: [Python-Dev] Very Strange Argument Handling Behavior
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'}
Or would we? If it's OK to mutate kwargs inside the function to contain
a non-string key, why isn't it OK to pass a non-string key in?
Because we can easily enough add the kwargs type check to CPython to
improve cross-implementation compatibility, while we can't easily check
individual assignments.
I understand that it couldn't be generated using keyword argument
syntax, but I don't see why we discriminate against f(**dict(...)) to
limit it to what could be generated using keyword argument syntax. Is
this such a big deal?
The language spec is intended to allow the use of string-only
dictionaries for namespaces. CPython happens to use normal dictionaries
and then optimises them heavily when they only contain string keys, but
other implementations are meant to be allowed to use a separate type
that doesn't permit arbitrary keys.
In cases where it is easy for CPython to check for purely string keys,
that's probably worth doing (especially now it has been noted that the
common case of that check passing can be made fast using the existing
string keys only optimisation tools).
There's also a consistency argument here, in that CPython already
performs this check for Python functions, so it is anomalous that there
are ways to do this without triggering the TypeError.
More exotic namespace abuse is generally harder to detect, and almost
certainly not worth the hassle of flagging on CPython itself (such code
will still fail on implementations that actually use string-key only
namespaces).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 new dictionary merging `x` and `y`. And that's how (and why) I use it, it's simpler (and — I believe — more readable) to write `z = dict(x, **y)` than `z = dict(x); z.update(y)`, since Python doesn't overload addition as it does for lists: l3 = l1 + l2 works and is equivalent to l3 = list(l1); l3.extend(l2) but there is no easy way to say that with dicts, at the moment. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
Steve Holden steve at 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', 'that': 'Raymond'}
I think that according to the proposal, the above snippet would be OK, but
def f(**kwargs):
kwargs[1] = 'dummy'
g(**kwargs)
would fail at the call of g.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 4:38 PM, Steve Holden st...@holdenweb.com 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'}
Or would we? If it's OK to mutate kwargs inside the function to contain
a non-string key, why isn't it OK to pass a non-string key in?
Because Python promises that the object the callee sees as 'kwargs' is
just a dict. But the requirement for what the caller passes in is
different: it must pass in a dict whose keys represent argument names.
If you want an API where you can pass in an arbitrary dict to be
received unchanged, don't use **kw. Remember that the caller can
independently decide whether or not to use the **kw notation -- there
is no implied correspondence between the caller's use of **kw and the
callee's use of it. Note this example:
def f(a, b, **k):
print(a, b, k)
d = {'a': 1, 'b': 2, 'c': 3}
f(**d)
This will print
1 2 {'c': 3}
Note that the k received by f is not the same as the d passed in! (And
yet d of course is not modified by the operation.)
I understand that it couldn't be generated using keyword argument
syntax, but I don't see why we discriminate against f(**dict(...)) to
limit it to what could be generated using keyword argument syntax. Is
this such a big deal?
Is portability of code to Jython, IronPython, PyPy a big deal?
According to a slide you recently posted to the PSF board list, it is.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
Guido van Rossum wrote:
On Fri, Apr 16, 2010 at 4:38 PM, Steve Holden st...@holdenweb.com 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'}
Or would we? If it's OK to mutate kwargs inside the function to contain
a non-string key, why isn't it OK to pass a non-string key in?
Because Python promises that the object the callee sees as 'kwargs' is
just a dict. But the requirement for what the caller passes in is
different: it must pass in a dict whose keys represent argument names.
If you want an API where you can pass in an arbitrary dict to be
received unchanged, don't use **kw. Remember that the caller can
independently decide whether or not to use the **kw notation -- there
is no implied correspondence between the caller's use of **kw and the
callee's use of it. Note this example:
def f(a, b, **k):
print(a, b, k)
d = {'a': 1, 'b': 2, 'c': 3}
f(**d)
This will print
1 2 {'c': 3}
Note that the k received by f is not the same as the d passed in! (And
yet d of course is not modified by the operation.)
Good point, and one I hadn't thought of. I was blithely assuming that
the dict seen by the called function was always what was passed as the
dict argument.
I understand that it couldn't be generated using keyword argument
syntax, but I don't see why we discriminate against f(**dict(...)) to
limit it to what could be generated using keyword argument syntax. Is
this such a big deal?
Is portability of code to Jython, IronPython, PyPy a big deal?
According to a slide you recently posted to the PSF board list, it is.
And I haven't changed my mind since. Thanks for the comprehensive response.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Sat, Apr 17, 2010 at 5:41 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Steve Holden steve at 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', 'that': 'Raymond'}
I think that according to the proposal, the above snippet would be OK, but
def f(**kwargs):
kwargs[1] = 'dummy'
g(**kwargs)
would fail at the call of g.
And that is already the status quo. Try it out in your friendly Python
interpreter.
The *only* thing that should be *changed* is for the dict() builtin to
insist that if it receives a dict containing keyword arguments the
keys must all be strings. This *only* affects the dict() builtin. It
has keyword arguments so that instead of {'foo': 1, 'bar': 2} you can
write dict(foo=1, bar=2), which arguably is more readable because it
doesn't have so many quotes. OTOH calling dict(x, **y) is a weird
hack. Note that if you wrote a wrapper function in Python around
dict() with the same behavior there would be no way to prevent the
check that all the keys are strings.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 wrong. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan ncogh...@gmail.com 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) while still be a valid Python implementation. I guess I was wrong. Actually I don't know about that. Is there language anywhere in the language reference that says this? What do IronPython, Jython, PyPy actually do? In any case my line of reasoning in this case isn't affected by this; as I pointed out in my reply to Steve, the relation between the **k passed in by the caller and the **k received by the callee is less direct than you might think. The proposed change *only* affects the dict() builtin; any change in the type of **k seen by the callee would potentially affect all user-defined functions. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
2010/4/17 Guido van Rossum gu...@python.org: On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan ncogh...@gmail.com 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) while still be a valid Python implementation. I guess I was wrong. Actually I don't know about that. Is there language anywhere in the language reference that says this? What do IronPython, Jython, PyPy actually do? Similar to CPython, PyPy has dict versions optimized for strings, which fall back to the general version when given non-string keys. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
Benjamin wrote: 2010/4/17 Guido van Rossum gu...@python.org: On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan ncogh...@gmail.com 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) while still be a valid Python implementation. I guess I was wrong. Actually I don't know about that. Is there language anywhere in the language reference that says this? What do IronPython, Jython, PyPy actually do? Similar to CPython, PyPy has dict versions optimized for strings, which fall back to the general version when given non-string keys. IronPython as well. The only place we use a string only dict is for new-style classes whose dict's are wrapped in a dictproxy. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Sat, Apr 17, 2010 at 11:38 AM, Dino Viehland di...@microsoft.com wrote: Benjamin wrote: 2010/4/17 Guido van Rossum gu...@python.org: On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan ncogh...@gmail.com 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) while still be a valid Python implementation. I guess I was wrong. Actually I don't know about that. Is there language anywhere in the language reference that says this? What do IronPython, Jython, PyPy actually do? Similar to CPython, PyPy has dict versions optimized for strings, which fall back to the general version when given non-string keys. IronPython as well. The only place we use a string only dict is for new-style classes whose dict's are wrapped in a dictproxy. And yet that breaks some code :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
Maciej wrote: On Sat, Apr 17, 2010 at 11:38 AM, Dino Viehland di...@microsoft.com wrote: Benjamin wrote: 2010/4/17 Guido van Rossum gu...@python.org: On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan ncogh...@gmail.com 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) while still be a valid Python implementation. I guess I was wrong. Actually I don't know about that. Is there language anywhere in the language reference that says this? What do IronPython, Jython, PyPy actually do? Similar to CPython, PyPy has dict versions optimized for strings, which fall back to the general version when given non-string keys. IronPython as well. The only place we use a string only dict is for new-style classes whose dict's are wrapped in a dictproxy. 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 compatible. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Sat, Apr 17, 2010 at 12:03 PM, Dino Viehland di...@microsoft.com wrote: Maciej wrote: On Sat, Apr 17, 2010 at 11:38 AM, Dino Viehland di...@microsoft.com wrote: Benjamin wrote: 2010/4/17 Guido van Rossum gu...@python.org: On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan ncogh...@gmail.com 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) while still be a valid Python implementation. I guess I was wrong. Actually I don't know about that. Is there language anywhere in the language reference that says this? What do IronPython, Jython, PyPy actually do? Similar to CPython, PyPy has dict versions optimized for strings, which fall back to the general version when given non-string keys. IronPython as well. The only place we use a string only dict is for new-style classes whose dict's are wrapped in a dictproxy. 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 compatible. :) There was one thing in sqlalchemy tests, not sure exactly why. There were also other things that I've seen, but consequently it was decided that it's only accidentally working on CPython and namespace should contain string-only keys. Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 compatible. :) This would be a lose anyway, since the CPython specifications suggest that you should not rely on being able to change locals() (or at least shouldn't expect that such changes are actually reflected in the local namespace). regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Sat, Apr 17, 2010 at 1:03 PM, Steve Holden st...@holdenweb.com 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 compatible. :) This would be a lose anyway, since the CPython specifications suggest that you should not rely on being able to change locals() (or at least shouldn't expect that such changes are actually reflected in the local namespace). You can override __new__ of a type subclass to achieve the same effect (or even directly call type.__new__ with strange dict as an argument). Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Very Strange Argument Handling Behavior
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)
Traceback (most recent call last):
File stdin, line 1, in module
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.
Thanks,
Alex
--
I disapprove of what you say, but I will defend to the death your
right to say it. -- Voltaire
The people's good is the highest law. -- Cicero
Code can always be simpler than you think, but never as simple as you
want -- Me
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 stdin, line 1, in module
TypeError: f() keywords must be strings
Argument names must be strings. In your example 1 must be at least '1'.
Oleg.
--
Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 implemented in Python, non-string arguments are always
rejected, but C functions (like the dict constructor) don't have to
reject them. I don't see any benefit in allowing them, but it's probably
not worth breaking code by disallowing them either.
I couldn't find this documented. Perhaps we should just say don't rely
on being able to pass non-string keywords somewhere?
- Hagen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 9:04 AM, Hagen Fürstenau ha...@zhuliguan.net 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 seems to be rather why dict(**{1:3}) doesn't.
For functions implemented in Python, non-string arguments are always
rejected, but C functions (like the dict constructor) don't have to
reject them. I don't see any benefit in allowing them, but it's probably
not worth breaking code by disallowing them either.
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
whether other implementations should be required to follow suit,
though---maybe this should be regarded as an implementation-defined
detail?
Mark
[1]
http://stackoverflow.com/questions/38987/how-can-i-merge-two-python-dictionaries-as-a-single-expression
)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 3:33 PM, Guido van Rossum gu...@python.org wrote:
On Fri, Apr 16, 2010 at 7:15 AM, Nick Coghlan ncogh...@gmail.com 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 in the language reference to
that effect may be worthwhile just to make that stance official.
That is just going to cause some programs to have a portability
surprise. I think one or the other should be fixed. I am fine with
declaring dict({}, **{1:3}) illegal, since after all it is abuse of
the ** mechanism. We should deprecate it in at least one version
though.
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.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 12:57 AM, Alex Gaynor alex.gay...@gmail.com 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)
...
kwargs = {1: 3}
dict({}, **kwargs)
{1: 3}
f(**kwargs)
Traceback (most recent call last):
File stdin, line 1, in module
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.
I ran into same issue with Django on Jython yesterday [1] since Jython
too gives TypeError for 'dict({}, **kwargs)'.
Thanks,
Raghu
[1] http://bugs.jython.org/issue1600
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
Mark Dickinson dickinsm at 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 spirit the moratorium applies more to language additions than to removals/limitations. The goal being that alternate implementation stop chasing a moving target in terms of features. So IMVHO it is fine for 3.2. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 3:57 PM, Antoine Pitrou solip...@pitrou.net wrote: Mark Dickinson dickinsm at 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 spirit the moratorium applies more to language additions than to removals/limitations. The goal being that alternate implementation stop chasing a moving target in terms of features. So IMVHO it is fine for 3.2. 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 Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On 16/04/2010 17:06, Mark Dickinson wrote:
On Fri, Apr 16, 2010 at 3:57 PM, Antoine Pitrousolip...@pitrou.net wrote:
Mark Dickinsondickinsmat 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 spirit the moratorium applies more to language additions than
to removals/limitations. The goal being that alternate implementation stop
chasing a moving target in terms of features.
So IMVHO it is fine for 3.2.
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?)
Same as Jython and PyPy:
IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.4927
Type help, copyright, credits or license for more information.
dict(**{1: 'hi'})
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: expected string for dictionary argument got 1
Michael
I've opened http://bugs.python.org/issue8419
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Friday, April 16, 2010, at 04:57PM, Antoine Pitrou solip...@pitrou.net wrote: Mark Dickinson dickinsm at 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 spirit the moratorium applies more to language additions than to removals/limitations. The goal being that alternate implementation stop chasing a moving target in terms of features. So IMVHO it is fine for 3.2. What about 2.7, should it be deprecated there as well? Ronald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 as well:
IronPython 2.6.1 DEBUG (2.6.10920.0) on .NET 2.0.50727.4927
Type help, copyright, credits or license for more information.
def f(**kwargs):
... print(kwargs)
...
kwargs = {1: 3}
dict({}, **kwargs)
Traceback (most recent call last):
File stdin, line unknown, in module
TypeError: expected string for dictionary argument got 1
d = {1:2}
d.update({3:4}, **{5:6})
Traceback (most recent call last):
File stdin, line unknown, in module
TypeError: expected string for dictionary argument got 5
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 8:35 AM, Stefan Behnel stefan...@behnel.de 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?
Not really. It's hard to imagine(*) an implementation that naturally
can represent strings that look like identifiers but not other strings
-- typically, identifier-ness must be explicitly checked. But it's
easy to imagine an implementation that only allows strings and not
other values.
___
(*) I didn't say impossible. I don't really care about any
counter-examples you may come up with -- in practice they don't
matter. But the type *does* matter in practice.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 8:22 AM, Ronald Oussoren ronaldousso...@mac.com wrote: On Friday, April 16, 2010, at 04:57PM, Antoine Pitrou solip...@pitrou.net wrote: Mark Dickinson dickinsm at 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 spirit the moratorium applies more to language additions than to removals/limitations. The goal being that alternate implementation stop chasing a moving target in terms of features. So IMVHO it is fine for 3.2. What about 2.7, should it be deprecated there as well? I think so. Compatibility with PyPy, Jython and IronPython is only going to become more important. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 like IronPython reports a type error as well:
IronPython 2.6.1 DEBUG (2.6.10920.0) on .NET 2.0.50727.4927
Type help, copyright, credits or license for more information.
def f(**kwargs):
... print(kwargs)
...
kwargs = {1: 3}
dict({}, **kwargs)
Traceback (most recent call last):
File stdin, line unknown, inmodule
TypeError: expected string for dictionary argument got 1
d = {1:2}
d.update({3:4}, **{5:6})
Traceback (most recent call last):
File stdin, line unknown, inmodule
TypeError: expected string for dictionary argument got 5
If the current CPython behavior is deprecated in 3.2, then I think
IronPython should keep its current behavior (and future Cpython
behavior) in IP 3.2 and not change it for one version.
tjr
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 another function. Do we want to validate the keys of every
kwds dict on every call? Why do we even care?
If I'm understanding the proposal correctly, it means that
every existing application using **kwds will pay a price, either
by breaking (because it uses non-string keys) or by running
slower (so that every call can be checked to make sure it
didn't use string keys).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
2010/4/16 Raymond Hettinger raymond.hettin...@gmail.com:
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 another function. Do we want to validate the keys of every
kwds dict on every call? Why do we even care?
If I'm understanding the proposal correctly, it means that
every existing application using **kwds will pay a price, either
by breaking (because it uses non-string keys) or by running
slower (so that every call can be checked to make sure it
didn't use string keys).
We already pay that price for any Python function, so I'm not sure
what difference adding to C, too, makes.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 2:11 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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.
Diasagree. The real benefit is better cross-implementation portability.
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 dict on every call? Why do we even care?
If I'm understanding the proposal correctly, it means that
every existing application using **kwds will pay a price, either
by breaking (because it uses non-string keys) or by running
slower (so that every call can be checked to make sure it
didn't use string keys).
It already does this for Python functions. So there is no cost (and no
change in the language semantics) except for the specific idiom
involving dict, which was incorrectly taking a shortcut.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 3:11 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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.
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 dict on every call? Why do we even care?
If I'm understanding the proposal correctly, it means that
every existing application using **kwds will pay a price, either
by breaking (because it uses non-string keys) or by running
slower (so that every call can be checked to make sure it
didn't use string keys).
Raymond
On the other hand, we (as in alternative python implementations) are
paying the price because people use it, even if only accidentally. If
CPython detects such cases and complain early, it would be much easier
for applications to stay cross-interpreter compatible (and I don't
think it's a huge burden for them to get rid of that, django already
did).
Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 2:22 PM, Maciej Fijalkowski fij...@gmail.com wrote:
On Fri, Apr 16, 2010 at 3:11 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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.
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 dict on every call? Why do we even care?
If I'm understanding the proposal correctly, it means that
every existing application using **kwds will pay a price, either
by breaking (because it uses non-string keys) or by running
slower (so that every call can be checked to make sure it
didn't use string keys).
Raymond
On the other hand, we (as in alternative python implementations) are
paying the price because people use it, even if only accidentally. If
CPython detects such cases and complain early, it would be much easier
for applications to stay cross-interpreter compatible (and I don't
think it's a huge burden for them to get rid of that, django already
did).
+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.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 dict on every call? Why do we even care? 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, rather than going through the slower PyObject_ functions. Consequently, validating **kwds should be cheap. I don't know if the the current validating of **kwds with Python functions already leverages that hack or not. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
2010/4/16 Daniel Stutzbach dan...@stutzbachenterprises.com: 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 dict on every call? Why do we even care? 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, rather than going through the slower PyObject_ functions. Consequently, validating **kwds should be cheap. 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. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 2:11 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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.
Diasagree. The real benefit is better cross-implementation portability.
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.
Isn't there anyway to make this a one-time check instead
of a PyLint style validation check running on every invocation
of a function or method using **kwds?
Or perhaps there can be a switch or flag to enable developers to
check for non-standard uses of **kwds. That way, they can clean-up
their programs but not make the end users pay for the checks every time
they run an application that has already been cleaned-up.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 4:51 PM, Benjamin Peterson benja...@python.orgwrote: 2010/4/16 Daniel Stutzbach dan...@stutzbachenterprises.com: 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, rather than going through the slower PyObject_ functions. 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. It would be enough to make the common case fast (1 pointer comparison). The error case would need to check all of the keys, true, but that's not really a performance concern. Unless you're saying you often create a dictionary, add non-string keys, remove the non-string keys, then pass it as a **kwds? ;-) -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 anyway. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
Raymond Hettinger raymond.hettinger at 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 performance being brutally butchered and chopped into small pieces on the altar of inter-implementation compatibility ;) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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, rather than going through the slower PyObject_ functions. Consequently, validating **kwds should be cheap. Good thinking. That would definitely be better than scanning the full dict on every call. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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
directly if possible, rather than going through the slower PyObject_
functions.
Consequently, validating **kwds should be cheap.
Good thinking.
That would definitely be better than scanning the full dict on every call.
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'}
Or would we? If it's OK to mutate kwargs inside the function to contain
a non-string key, why isn't it OK to pass a non-string key in?
I understand that it couldn't be generated using keyword argument
syntax, but I don't see why we discriminate against f(**dict(...)) to
limit it to what could be generated using keyword argument syntax. Is
this such a big deal?
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 call the string compare/hash functions
directly if possible, rather than going through the slower PyObject_
functions.
Consequently, validating **kwds should be cheap.
Good thinking.
That would definitely be better than scanning the full dict on every call.
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'}
Or would we?
Nobody is proposing barring that.
If it's OK to mutate kwargs inside the function to contain
a non-string key, why isn't it OK to pass a non-string key in?
Because they are completely different operations.
Michael
I understand that it couldn't be generated using keyword argument
syntax, but I don't see why we discriminate against f(**dict(...)) to
limit it to what could be generated using keyword argument syntax. Is
this such a big deal?
regards
Steve
--
http://www.ironpythoninaction.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 TypeError: Keyword dict contains non-string keys, but upon examination, the dict clearly does not contain any such thing? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
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 make of a situation where Python says TypeError: Keyword dict contains non-string keys, but upon examination, the dict clearly does not contain any such thing? No, if the dictionary is not marked as an all-string dict it can fallback to checking. The common case (dict marked as all strings) is fast. Michael -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On Fri, Apr 16, 2010 at 2:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Fri, Apr 16, 2010 at 2:11 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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.
Diasagree. The real benefit is better cross-implementation portability.
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.
Isn't there anyway to make this a one-time check instead
of a PyLint style validation check running on every invocation
of a function or method using **kwds?
Or perhaps there can be a switch or flag to enable developers to
check for non-standard uses of **kwds. That way, they can clean-up
their programs but not make the end users pay for the checks every time
they run an application that has already been cleaned-up.
Please stop worrying.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
