[Python-Dev] More flexible namespaces.
MHammond at skippinet.com.au
Mon May 3 02:52:41 CEST 1999
> [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
[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?
More information about the Python-Dev