[Greg Stein] > ... > In other words, I definitely would support a new class > object behavior that allows us to update a class' set of > bases and dictionary on the fly. This could then be used > to support my solution for the recursive type scenario (which, > in turn, means that we don't have to introduce Yet Another > Namespace into Python to hold type names). Parenthetically, I never grasped the appeal of the parenthetical comment. Yet Another Namespace for Yet Another Entirely New Purpose seems highly *desirable* to me! Trying to overload the current namespace set makes it so much harder to see that these are compile-time gimmicks, and users need to be acutely aware of that if they're to use it effectively. Note that I understand (& wholly agree with) the need for runtime introspection. different-things-different-rules-ly y'rs - tim
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