[Python-Dev] Patch to use dict subclasses in eval(), exec
Guido van Rossum
guido@python.org
Tue, 29 Oct 2002 13:29:16 -0500
> 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 think (2) could be resolved using "ghosts" -- this is what Zope's
persistency mechanism uses. The names must be present, but their
content is loaded on demand. I expect that (1) probably could also be
solved this way.
> 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.
That's a good question.
> --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.
But why not make it an attribute lookup? That's how Zope (again :-)
deals with this. Remember acquisition? :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)