Christian Tismer wrote: > > David Ascher wrote: > [Marc:> > > > Since you put out the objectives, I'd like to propose a little > > > different approach... > > > > > > 1. Have eval/exec accept any mapping object as input > > > > > > 2. Make those two copy the content of the mapping object into real > > > dictionaries > > > > > > 3. Provide a hook into the dictionary implementation that can be > > > used to redirect KeyErrors and use that redirection to forward > > > the request to the original mapping objects > > I don't think that this proposal would give so much new > value. Since a mapping can also be implemented in arbitrary > ways, say by functions, a mapping is not necessarily finite > and might not be changeable into a dict. [Disclaimer: I'm not really keen on having the possibility of letting code execute in arbitrary namespace objects... it would make code optimizations even less manageable.] You can easily support infinite mappings by wrapping the function into an object which returns an empty list for .items() and then use the hook mentioned in 3 to redirect the lookup to that function. The proposal allows one to use such a proxy to simulate any kind of mapping -- it works much like the __getattr__ hook provided for instances. > [David:> > > Interesting counterproposal. 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? > > Case-independant namespaces seem to be a minor point, > nice to have for interfacing to other products, but then, > in a function, I see no benefit in changing the semantics > of function locals? The lookup of foreign symbols would > always be through a mapping object. If you take COM for > instance, your access to a COM wrapper for an arbitrary > object would be through properties of this object. After > assignment to a local function variable, why should we > support case-insensitivity at all? > > I would think mapping objects would be a great > simplification of lazy imports in COM, where > we would like to avoid to import really huge > namespaces in one big slurp. Also the wrapper code > could be made quite a lot easier and faster without > so much getattr/setattr trapping. What do lazy imports have to do with case [in]sensitive namespaces ? Anyway, how about a simple lazy import mechanism in the standard distribution, i.e. why not make all imports lazy ? Since modules are first class objects this should be easy to implement... > Does btw. anybody really want to see case-insensitivity > in Python programs? I'm quite happy with it as it is, > and I would even force the use to always use the same > case style after he has touched an external property > once. Example for Excel: You may write "xl.workbooks" > in lowercase, but then you have to stay with it. > This would keep Python source clean for, say, PyLint. "No" and "me too" ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: Y2000: 243 days left Business: http://www.lemburg.com/ Python Pages: http://starship.python.net/crew/lemburg/
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