[Python-Dev] Patch to use dict subclasses in eval(), exec
David Ascher
DavidA@ActiveState.com
Tue, 29 Oct 2002 10:20:28 -0800
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.