[Python-Dev] Patch to use dict subclasses in eval(), exec

[David Ascher]

Guido van Rossum wrote:
>>I wonder how many reasonable real-life scenarios actually exist for
>>this feature?
>>
>>My personal use would be for COM, to implement case-insensitive
>>namespaces.  In some cases, case-insensitivity is actually part of
>>the implementation specification, and I can imagine other scenarios
>>where case insensitive namespaces are "reasonable" even in the face
>>of Python's excellent decision not to go this route.
>>
>>I wonder is this is actually the root of many requests to see this
>>feature implemented?  If not, it would be interesting to see what
>>the competing desires really are.
> 
> 
> Excellent observation.  Perhaps the people who want this can get
> together and write a PEP that explains the motivation and why the
> alternatives don't work?  (E.g. when you need case-insensitive
> variable names, perhaps it's just as easy to preprocess the source
> code?)

I can think of two 'real world' use cases for this patch that I remember.

1) When I was consulting for a finite element modeling company that was using 
Python to manipulate _very_ large objects through a database.  I don't recall 
the details, but basically they wanted to be able to control database connection 
lifetimes in a way that wasn't possible at the time (Python 1.4 or so, I think 
=).  These days I think that proxies would probably be leveraged to provide the 
capability, but namespace lookup would still be useful -- one objection they had 
to using proxies is that they didn't want their users to think in terms of 
objects with attributes -- they wanted their users to say:

   a = b + c

and have the system figure out at runtime whether to evaluate b, a DB connection 
needed to be established, or not.  None of the alternatives I thought of at the 
time "worked" for various reasons.  Sorry I'm so vague, it's been a long time. 
(I don't even remember how the problem was resolved).

2) The other case where I would have used this is in building a high-power 
interactive shell for scientific users doing modeling (think Matlab on 
steroids), where I wanted the interpreter to be able to resolve names at runtime 
from pickled states -- that way the memory load was dependent on actual usage, 
but the "impression" to the user would have been that the system "never forgot".

In both of these cases, Guido would be right in saying that that's not Python, 
but that's somewhat irrelevant -- the end-users would have had a "better" user 
experience with the feature on, and other aspects of the system would have made 
it quite clear that this wasn't vanilla Python.

I like the feature, not necessarily for inclusion in core Python but as a way of 
experimenting with alternate universes in a research mode:  "What would a 
PHP-like 'isset()' feel like?" "Could we do something akin to Tcl's TclObj dual 
representations?"  Name resolution has always felt like the least "hookable" of 
Python's mechanisms (as opposed to attribute lookup, exception handling, etc.), 
and I wonder what good things could come of making it more open to experimentation.

--david

PS: Thinking of PHP, the fact that I can look up variables defined in sessions 
or cookies or whatnot really really easily is one of the reasons I'm liking PHP 
more than Python for web programming these days.  I don't know enough of the 
technical details of the web to know automatically where what data is stored and 
in what format -- and PHP doesn't make me.  Maybe web folks would use the 
dict-subclass feature to emulate this aspect of PHP.