Mailing List Archive

> To cut a long story short, I would like eval and exec to be capable of
> working with arbitrary mapping objects rather than only dictionaries. The
> general idea is that I can provide a class with mapping semantics, and pass
> this to exec/eval.

I agree that this would be seriously cool. It will definitely be in
Python 2.0; it's already in JPython.

Quite a while ago, Ian Castleden sent me patches for 1.5.1 to do this.
It was a lot of code and I was indeed worried about slowing things
down too much (and also about checking that he got all the endcases
right).

Ian did benchmarks and found that the new code was consistently
slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the
"Python IS slow" thread notwithstanding :-); or perhaps someone can
have a look at it and squeeze some more time out of it? I'll gladly
forward the patches.

--Guido van Rossum (home page: http://www.python.org/~guido/)

> > To cut a long story short, I would like eval and exec to be capable of
> > working with arbitrary mapping objects rather than only dictionaries. The
> > general idea is that I can provide a class with mapping semantics, and pass
> > this to exec/eval.
>
> I agree that this would be seriously cool. It will definitely be in
> Python 2.0; it's already in JPython.

Seriously cool is an understatement.

--david

> Ian did benchmarks and found that the new code was consistently
> slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the
> "Python IS slow" thread notwithstanding :-); or perhaps someone can

As long as we get someone working on a consistent 3-6% speedup in other
areas this wont be a problem :-)

I will attach it to my long list - but Im going to put all my efforts here
into Unicode first, and probably the threading stuff second :-)

Mark.

Guido van Rossum wrote:
...
> Ian did benchmarks and found that the new code was consistently
> slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the
> "Python IS slow" thread notwithstanding :-); or perhaps someone can
> have a look at it and squeeze some more time out of it? I'll gladly
> forward the patches.

I'd really like to look into that.
Also I wouldn't worry too much about speed, since this is
such a cool feature. It might even be a speedup in some cases
which otherwise would need more complex handling.

May I have a look?

ciao - chris

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home

Mark Hammond wrote:
>
> Here is a bit of an idea that I first came up with some years ago. Guido's
> response at the time was "sounds reasonable as long as we dont slow the
> normal case down".
>
> To cut a long story short, I would like eval and exec to be capable of
> working with arbitrary mapping objects rather than only dictionaries. The
> general idea is that I can provide a class with mapping semantics, and pass
> this to exec/eval.

This involves a whole lot of changes: not only in the Python core,
but also in extensions that rely on having real dictionaries available.

Since you put out to 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

> This would give us 2 seriously cool features (that I want <wink>), should
> anyone decide to write code that enables them:
>
> * Case insensitive namespaces. This would be very cool for COM, and as far
> as I know would please the Alice people. May open up more embedding
> opportunities that are lost if people feel strongly about this issue.

This is covered by 1 and 2.

> * Dynamic name lookups. At the moment, dynamic attribute lookups are
> simple, but dynamic name lookups are hard. If I execute code "print foo",
> foo _must_ pre-exist in the namespace. There is no reasonable way I can
> some up with so that I can fetch "foo" as it is requested (raising the
> NameError if necessary). This would also be very cool for some of the COM
> work - particularly Active Scripting.

This is something for 3.

I guess it wouldn't cause any significant slow-down and can be
imlemented with much less code than the "change all PyDict_GetItem
to PyObject_GetItem" thingie.

The real thing could then be done for 2.0 where PyDict_Check()
would presumably not rely on an adress but some kind of inheritance
scheme indicating that the object is in fact a dictionary.

Cheers,
--
Marc-Andre Lemburg Y2000: 245 days left
---------------------------------------------------------------------
: Python Pages >>> http://starship.skyport.net/~lemburg/ :
---------------------------------------------------------

> From: Christian Tismer <tismer@appliedbiometrics.com>

> I'd really like to look into that.
> Also I wouldn't worry too much about speed, since this is
> such a cool feature. It might even be a speedup in some cases
> which otherwise would need more complex handling.
>
> May I have a look?

Sure!

(I've forwarded Christian the files per separate mail.)

I'm also interested in your opinion on how well thought-out and robust
the patches are -- I've never found the time to do a good close
reading of them.

--Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
>
> > From: Christian Tismer <tismer@appliedbiometrics.com>
> > May I have a look?
>
> Sure!
>
> (I've forwarded Christian the files per separate mail.)

Thanks a lot!

> I'm also interested in your opinion on how well thought-out and robust
> the patches are -- I've never found the time to do a good close
> reading of them.

Yes, it is quite long and not so very easy to digest.
At first glance, most of the changes are replacements of
dict access with mapping access where we pay for the extra
indirection.
It depends on how often this feature will really replace
dicts. If dicts are more common, I'd like to figure out
how much code bloat extra special casing for dicts would give.

Puha - thanks - chris

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home

Gordon McMillan wrote:
>
> Guido wrote:
>
> > > From: Christian Tismer <tismer@appliedbiometrics.com>
> >
> > > I'd really like to look into that.
> > > Also I wouldn't worry too much about speed, since this is
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > such a cool feature. It might even be a speedup in some cases
> > > which otherwise would need more complex handling.
> > >
> > > May I have a look?
> >
> > Sure!
> >
> > (I've forwarded Christian the files per separate mail.)
>
> I don't know who you sent that to, but it couldn't possibly have been
> Christian!

:-) :-) truely not if I had'n other things in mind.

I know that I will not get more than 30-40 percent by compiling
the interpreter away, so I will not even spend time at a
register machine right now. Will also not follow the ideas of
P2C any longer, doesn't pay off.
Instead, If I can manage to create something like static binding
snapshots, then I could resolve many of the lookups and internal
method indirections, for time critical applications.
For all the rest, Python is pretty much fast enough.

I've begun to write s special platform dependant version
which allows me to do all the things which can't go into the dist.
For instance, I just saved some 10 percent by dynamically
patching some of the ParseTuple and BuildObject calls out of the
core code (ahem). I hope Python will stay as clean as it is,
allowing me to try all kinds of tricks for one machine class.

ciao - chris.speedy

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home

Guido wrote:

> > From: Christian Tismer <tismer@appliedbiometrics.com>
>
> > I'd really like to look into that.
> > Also I wouldn't worry too much about speed, since this is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > such a cool feature. It might even be a speedup in some cases
> > which otherwise would need more complex handling.
> >
> > May I have a look?
>
> Sure!
>
> (I've forwarded Christian the files per separate mail.)

I don't know who you sent that to, but it couldn't possibly have been
Christian!

- Gordon

Christian Tismer writes:
>Instead, If I can manage to create something like static binding
>snapshots, then I could resolve many of the lookups and internal
>method indirections, for time critical applications.

The usual assumption is that the lookups are what takes time.
Now, are we sure of that assumption? I'd expect the lookup code to be
like:

1) Get hash of name
2) Retrieve object from dictionary
3) Do something with the object.

Now, since string objects cache their hash value, 1) should usually be
just "if (obj->cached_hash_value!=-1) return obj->cached_hash_value";
a comparision and a return. Step 2) should be very fast, barring a
bad hash function. So perhaps most of the time is spent in 3),
creating new local dicts, stack frames, and what not. (Yes, I know
that doing this on every reference to an object is part of the
problem.) I also wonder about the costs of all the Py_BuildValue and
Py_ParseTuple calls going on under the hood. A performance
improvement project would definitely be a good idea for 1.6, and a
good sub-topic for python-dev.

Incidentally, what's the verdict on python-dev archives:
public or not?

--
A.M. Kuchling http://starship.python.net/crew/amk/
Despair says little, and is patient.
-- From SANDMAN: "Season of Mists", episode 0

"Andrew M. Kuchling" wrote:
>
> Christian Tismer writes:
> >Instead, If I can manage to create something like static binding
> >snapshots, then I could resolve many of the lookups and internal
> >method indirections, for time critical applications.
>
> The usual assumption is that the lookups are what takes time.
> Now, are we sure of that assumption? I'd expect the lookup code to be
> like:
>
> 1) Get hash of name
> 2) Retrieve object from dictionary
> 3) Do something with the object.
...
Right, but when you become more restrictive, you can do
lots, lots more. If I also allow to fix the type of an object,
I can go under the hood of the Python API, so you could
add some points 4) 5) 6) here.
But I shouldn't have talked before I can show something.
And at the time, I don't restrict myself to write clean
code, but try very machine specific things which I
don't believe should go into Python at all.

> I also wonder about the costs of all the Py_BuildValue and
> Py_ParseTuple calls going on under the hood. A performance
> improvement project would definitely be a good idea for 1.6, and a
> good sub-topic for python-dev.

I wasn't sure, so I first wrote a module which does statistics
on that, and I found a lot of these calls. Some are even
involved in ceval's code, where things like "(OOOO)" is parsed
all over again and again. Now I think this is ok in most cases.
But in some places these are very bad: If your builtin function
soes so very few work.
Take len(): This uses ParseTuple, which calls a function to
find out its object, then calls a function to get the object,
then takes the len, and builds the result. But since everything
has a length, checking for no NULL pointer and grabbing the len
produces even shorter code. This applies to many places as well.
But right now, I don't change the core, but build hacky little
extension modules which squeak such things out at runtime.
No big deal yet, but maybe it could pay off to introduce
format strings which make them more suitableto be used
in macro substitutions.

sorry if I was too elaborate, this is so much fun :-)

ciao - chris

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home

> Since you put out to 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

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?

--david

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

Why not? I pictured case insensitive namespaces working so that they
retain the case of the first assignment, but all lookups would be
case-insensitive.

Ohh - right! Python itself would need changing to support this. I suppose
that faced with code such as:

def func():
if spam:
Spam=1

Python would generate code that refers to "spam" as a local, and "Spam" as
a global.

Is this why you feel it wont work?

Mark.

David Ascher wrote:
[Marc:>
> > Since you put out to 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.

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

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.

my 0.02 Euro - chris

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home

On Sun, 2 May 1999, Mark Hammond wrote:

> > 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?
>
> Why not? I pictured case insensitive namespaces working so that they
> retain the case of the first assignment, but all lookups would be
> case-insensitive.
>
> Ohh - right! Python itself would need changing to support this. I suppose
> that faced with code such as:
>
> def func():
> if spam:
> Spam=1
>
> Python would generate code that refers to "spam" as a local, and "Spam" as
> a global.
>
> Is this why you feel it wont work?

I hadn't thought of that, to be truthful, but I think it's more generic.
[.FWIW, I never much cared for the tag-variables-at-compile-time
optimization in CPython, and wouldn't miss it if were lost.]

The point is that if I eval or exec code which calls a function specifying
some strange mapping as the namespaces (global and current-local) I
presumably want to also specify how local namespaces work for the
function calls within that code snippet. That means that somehow Python
has to know what kind of namespace to use for local environments, and not
use the standard dictionary. Maybe we can simply have it use a
'.clear()'ed .__copy__ of the specified environment.

exec 'foo()' in globals(), mylocals

would then call foo and within foo, the local env't would be
mylocals.__copy__.clear().

Anyway, something for those-with-the-patches to keep in mind.

--david

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/

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

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/

Guido van Rossum wrote:
>
> > From: Christian Tismer <tismer@appliedbiometrics.com>
>
> > I'd really like to look into that.
> > Also I wouldn't worry too much about speed, since this is
> > such a cool feature. It might even be a speedup in some cases
> > which otherwise would need more complex handling.
> >
> > May I have a look?
>
> Sure!
>
> (I've forwarded Christian the files per separate mail.)
>
> I'm also interested in your opinion on how well thought-out and robust
> the patches are -- I've never found the time to do a good close
> reading of them.

Coming back from the stackless task with is finished now,
I popped this task from my stack.

I had a look and it seems well-thought and robust so far.
To make a more trustable claim, I would need to build and test it.

Is this still of interest, or should I drop it?
The follow-ups in this thread indicated that the opinions
about flexible namespaces were quite mixed. So,
should I waste time in building and testing or better save it?

chris

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home