[Python-Dev] More flexible namespaces.

[M.-A. Lemburg]

Mark Hammond wrote:
> 
> [Marc]
> > [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.]
> 
> Good point - although surely that would simply mean (certain) optimisations
> can't be performed for code executing in that environment?  How to detect
> this at "optimization time" may be a little difficult :-)
> 
> However, this is the primary purpose of this thread - to workout _if_ it is
> a good idea, as much as working out _how_ to do it :-)
> 
> > 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.
> 
> My only problem with Marc's proposal is that there already _is_ an
> established mapping protocol, and this doesnt use it; instead it invents a
> new one with the benefit being potentially less code breakage.

...and that's the key point: you get the intended features and
the core code will not have to be changed in significant ways.
Basically, I think these kind of core extensions should be done
in generic ways, e.g. by letting the eval/exec machinery accept
subclasses of dictionaries, rather than trying to raise the
abstraction level used and slowing things down in general
just to be able to use the feature on very few occasions.

> And without attempting to sound flippant, I wonder how many extension
> modules will be affected?  Module init code certainly assumes the module
> __dict__ is a dictionary, but none of my code assumes anything about other
> namespaces.  Marc's extensions may be a special case, as AFAIK they inject
> objects into other dictionaries (ie, new builtins?).  Again, not trying to
> downplay this too much, but if it is only a problem for Marc's more
> esoteric extensions, I dont feel that should hold up an otherwise solid
> proposal.

My mxTools extension does the assignment in Python, so it wouldn't
be affected. The others only do the usual modinit() stuff.

Before going any further on this thread we may have to ponder a little
more on the objectives that we have. If it's only case-insensitive
lookups then I guess a simple compile time switch exchanging the
implementations of string hash and compare functions would do the
trick. If we're after doing wild things like lookups accross
networks, then a more specific approach is needed.

So what is it that we want in 1.6 ?

> [Chris, I think?]
> > > 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
> 
> I disagree here.  Consider Alice, and similar projects, where a (arguably
> misplaced, but nonetheless) requirement is that the embedded language be
> case-insensitive.  Period.  The Alice people are somewhat special in that
> they had the resources to change the interpreters guts.  Most people wont,
> and will look for a different language to embedd.
> 
> Of course, I agree with you for the specific cases you are talking - COM,
> Active Scripting etc.  Indeed, everything I would use this for would prefer
> to keep the local function semantics identical.

As I understand the needs in COM and AS you are talking about
object attributes, right ? Making these case-insensitive is
a job for a proxy or a __getattr__ hack.
 
> > > 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" ;-)
> 
> I think we are missing the point a little.  If we focus on COM, we may come
> up with a different answer.  Indeed, if we are to focus on COM integration
> with Python, there are other areas I would prefer to start with :-)
> 
> IMO, we should attempt to come up with a more flexible namespace mechanism
> that is in the style of Python, and will not noticeably slowdown Python.
> Then COM etc can take advantage of it - much in the same way that Python's
> existing namespace model existed pre-COM, and COM had to take advantage of
> what it could!
> 
> Of course, a key indicator of the likely success is how well COM _can_ take
> advantage of it, and how much Alice could have taken advantage of it - I
> cant think of any other yardsticks?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                            Y2000: 242 days left
Business:                                      http://www.lemburg.com/
Python Pages:                 http://starship.python.net/crew/lemburg/