On Thu, 2003-03-27 at 23:15, Guido van Rossum wrote: > > I really like this idea. If a patch appeared on SF soon, do you think > > 2.3 could include a warning for code that violates the rule? > > Maybe. Though you probably would only want to warn when this is done > to a .py module -- C extensions should be exempt. And the warning > should only warn about inserting names that are actually builtins. It seems like C extensions pose thorny problems that need to be solved. In particular, the C API says that module's have a dictionary and that adding a key creates global variable in the module. We'll have to break this one way or another, because we don't want to allow C extensions to add globals that shadow builtins. Right? There's a similar problem for Python code, but I imagine it's easy to come up with a dict proxy with the necessary restrictions along the lines of a new-style class dict proxy. How do we break the C API? There's lots of extension code that relies on getting the dict. My first guess is to add an exception that says setting a name that shadows a builtin has no effect. Then extend the getattr code and the module-dict-proxy to ignore those names. Jeremy
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