[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4