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/