> 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/)
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