On Mon, 18 Feb 2002, David Ascher wrote: > I think that you're making useful points, but I think that it's worth > stepping even further back and deciding what the reflection API should > be like from a "what's it for" POV? Exactly! However, having a meta-discussion on meta-reflection is a little too abstract for the disinterested to jump in on. However most people who read python-dev use and come to rely on using __dict__ as The Python Reflection API for instance attributes. > This relates to much of the discussion about what dir() should do on > new-style classes, as well as why some Python objects have 'members', > some have 'methods', etc. Sure, except that I've _NEVER_ assumed dir() was anything more than a quick-and-dirty ultra-high level hack that was occaisonally useful for doing reflection. One call does not a reflection API make. > In my opinon, __dict__ is mostly an implementation detail, and it makes > sense to me that the slot names dont' show up in there (after all, it's > not a dictionary!). I think so too, though I don't want to ram my own views down people's throats on the matter. However, it is potentially valid to view __dict__ as the one true reflection API for getting access to all attributes. This isn't too outlandish since it effectively is in Python 2.2. Pickle and cPickle 2.2 (among several dozen other examples I've found) are currently implemented assuming this. If we wanted to keep this existing API we could support reflection on slots by extending object instances with only slot attributes to share a common read-only __dict__. New style class instances with per-instance __dict__'s should start with a mutable copy when instantiated. For the record, I don't think this is the right way to go, even though it is a valid way way of defining the Python reflection API. > What I'd propose is that the inspect module grow some "abstract" > reflection APIs which make it possible for folks who don't need to know > about implementation details to get away with it. Great idea! I've already got a stack of suggestions and patches that clean up other various bits of it. However, there was an unstated and important question left out of my last e-mail: We need to decide if slots are really 'attributes' or "something else". The "something else" being akin to __set/getattr__ virtual attributes, pure properties, and other techniques that will almost always require explicit hooks to into reflection APIs. My preference is the former, that slot declarations simply affect the allocation choices made by an object, and not the semantics of what may be done with that object (modulo issues when per-instance dicts are not allocated). Thanks, -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
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