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.
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