[Python-Dev] More flexible namespaces.

[M.-A. Lemburg]

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/