Tony Nelson wrote: > At 4:46 PM +0100 6/9/08, Michael Foord wrote: > >> Alex Martelli wrote: >> >>> The problem is more general: what if a member (of some external >>> object we're proxying one way or another) is named print (in Python < >>> 3), or class, or...? To allow foo.print or bar.class would require >>> pretty big changes to Python's parser -- I have vague memories that >>> the issue was discussed ages ago (possibly in conjunction with some >>> early release of Jython) but never went anywhere much (including >>> proposals to automatically append an underscore to such IDs in the >>> proxying layer, etc etc). Maybe None in particular is enough of a >>> special case (if it just happens to be hugely often used in dotNET >>> libraries)? >>> >>> >> 'None' as a member does occur particularly frequently in the .NET world. >> >> A halfway house might be to state (something like): >> >> Python as a language disallows you from having names the same as >> keywords or 'None'. An implementation restriction specific to CPython is >> that the same restriction also applies to member names. Alternative >> implementations are free to not implement this restriction, with the >> caveat that code using reserved member names directly will be invalid >> syntax for CPython. >> > ... > > Or perhaps CPython should just stop trying to detect this at compile time. > Note that while assignment to ".None" is not allowed, setattr(foo, "None", > 1) then referencing ".None" is allowed. > > I'm +0 on this at the moment, but I can understand the desire for it. Maybe we should stop trying to check for this assignment on attributes? Currently there are separate checks for assignment to None: one for the "foo.None = ..." form, another for the "None = ..." form. Removing the check for the former looks like it would be a one-liner. Cheers, T
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4