[Python-Dev] More flexible namespaces.

[Mark Hammond]

[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 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.

[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.

> > 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?

Mark.