What do you think about this code: class A: locals()[42] = 98 Seems people rely on it working. Do we consider it part of python language? (Note that you cannot do the same with getattr/setattr which checks if argument is a string) Cheers, fijal
On Tue, Jun 10, 2008 at 8:10 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
What do you think about this code:
class A: locals()[42] = 98
Seems people rely on it working. Do we consider it part of python language? (Note that you cannot do the same with getattr/setattr which checks if argument is a string)
Seems like a bug to me, but I don't think there is much we can do about it short of making locals a custom dict which rejects none string keys. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."
Benjamin Peterson wrote:
On Tue, Jun 10, 2008 at 8:10 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
What do you think about this code:
class A: locals()[42] = 98
Seems people rely on it working. Do we consider it part of python language? (Note that you cannot do the same with getattr/setattr which checks if argument is a string)
Seems like a bug to me, but I don't think there is much we can do about it short of making locals a custom dict which rejects none string keys.
Given that the documentation has for a long time said: """locals( ) Update and return a dictionary representing the current local symbol table. Warning: The contents of this dictionary should not be modified; changes may not affect the values of local variables used by the interpreter. """ it would be hard for the people who have relied on this behavior to complain if it stopped working. Basically retaining this behavior is pandering to people who have ignored the language specification! regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
What do you think about this code:
class A: locals()[42] = 98
Seems people rely on it working. Do we consider it part of python language? (Note that you cannot do the same with getattr/setattr which checks if argument is a string)
Seems like a bug to me, but I don't think there is much we can do about it short of making locals a custom dict which rejects none string keys.
I see no reason to invent a new custom dict to prevent people from doing something they find to be useful. If you can't segfault with it, who cares. Also, adding another custom type just makes it more difficult to remember what is returned by locals() or globals(). Raymond
On Tue, Jun 10, 2008 at 9:18 PM, Raymond Hettinger <python@rcn.com> wrote:
I see no reason to invent a new custom dict to prevent people from doing something they find to be useful. If you can't segfault with it, who cares.
Don't worry; I'm not suggesting it. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."
Maciej Fijalkowski wrote:
What do you think about this code:
class A: locals()[42] = 98
Seems people rely on it working.
I apologize for my ignorance, but who? Could you please cite something reputable that relies on this detail? -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
On Wed, Jun 11, 2008 at 3:36 AM, Scott Dial <scott+python-dev@scottdial.com> wrote:
Maciej Fijalkowski wrote:
What do you think about this code:
class A: locals()[42] = 98
Seems people rely on it working.
I apologize for my ignorance, but who? Could you please cite something reputable that relies on this detail?
It's in tests of sqlalchemy. My question is among the lines "should I bug sqlalchemy guys to remove this, or should I change pypy to accept this".
On Tue, Jun 10, 2008 at 8:37 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Wed, Jun 11, 2008 at 3:36 AM, Scott Dial
I apologize for my ignorance, but who? Could you please cite something reputable that relies on this detail?
It's in tests of sqlalchemy. My question is among the lines "should I bug sqlalchemy guys to remove this, or should I change pypy to accept this".
If you have that power, I recommend you tell them to get rid of it. :) -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."
Greg Ewing wrote:
Maciej Fijalkowski wrote:
What do you think about this code:
class A: locals()[42] = 98
Seems people rely on it working. Do we consider it part of python language?
Modifying the dict returned by locals() is documented as NOT being guaranteed to work, isn't it?
Yep - it just happens to work for class and module level namespaces in CPython. Implementations are also permitted to restrict namespace dictionaries to only accept string keys (I believe Jython does this for performance reasons - CPython just optimised the hell out of normal dictionaries that happen to only contain string keys instead). So I don't see any reason for Maciej to mess with PyPy to support code which deliberately makes use of formally undefined behaviour. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
Greg Ewing wrote: Implementations are also permitted to restrict namespace dictionaries to only accept string keys (I believe Jython does this for performance reasons - CPython just optimised the hell out of normal dictionaries that happen to only contain string keys instead). Jython's current version (2.2) and back did indeed restrict these dictionaries to accept string keys only, but future versions will allow non-string keys (the trunk version already does). Many
On Wed, Jun 11, 2008 at 5:50 AM, Nick Coghlan <ncoghlan@gmail.com> wrote: frameworks use non-string keys in these dictionaries. -Frank
On Thu, Jun 12, 2008 at 8:19 PM, Frank Wierzbicki <fwierzbicki@gmail.com> wrote:
Greg Ewing wrote: Implementations are also permitted to restrict namespace dictionaries to only accept string keys (I believe Jython does this for performance reasons - CPython just optimised the hell out of normal dictionaries that happen to only contain string keys instead). Jython's current version (2.2) and back did indeed restrict these dictionaries to accept string keys only, but future versions will allow non-string keys (the trunk version already does). Many
On Wed, Jun 11, 2008 at 5:50 AM, Nick Coghlan <ncoghlan@gmail.com> wrote: frameworks use non-string keys in these dictionaries.
I think that's laudable from a compatibility POV, but at the same time I think frameworks should rethink such usage and switch to strings containing non-identifier characters, e.g. '$' or '.' or some such convention. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (9)
-
Benjamin Peterson -
Frank Wierzbicki -
Greg Ewing -
Guido van Rossum -
Maciej Fijalkowski -
Nick Coghlan -
Raymond Hettinger -
Scott Dial -
Steve Holden