On Sun, 2 May 1999, Mark Hammond wrote: > > I'm not sure whether any of the > > proposals on > > the table really do what's needed for e.g. case-insensitive namespace > > handling. I can see how all of the proposals so far allow > > case-insensitive reference name handling in the global namespace, but > > don't we also need to hook into the local-namespace creation > > process to > > allow case-insensitivity to work throughout? > > Why not? I pictured case insensitive namespaces working so that they > retain the case of the first assignment, but all lookups would be > case-insensitive. > > Ohh - right! Python itself would need changing to support this. I suppose > that faced with code such as: > > def func(): > if spam: > Spam=1 > > Python would generate code that refers to "spam" as a local, and "Spam" as > a global. > > Is this why you feel it wont work? I hadn't thought of that, to be truthful, but I think it's more generic. [FWIW, I never much cared for the tag-variables-at-compile-time optimization in CPython, and wouldn't miss it if were lost.] The point is that if I eval or exec code which calls a function specifying some strange mapping as the namespaces (global and current-local) I presumably want to also specify how local namespaces work for the function calls within that code snippet. That means that somehow Python has to know what kind of namespace to use for local environments, and not use the standard dictionary. Maybe we can simply have it use a '.clear()'ed .__copy__ of the specified environment. exec 'foo()' in globals(), mylocals would then call foo and within foo, the local env't would be mylocals.__copy__.clear(). Anyway, something for those-with-the-patches to keep in mind. --david
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