>You could read up on __getattr__, __getattribute__, and > >friends in the Language References section 3.3.2: > Customizing attribute access
"and friends" include descriptors, so that the discussion about properties here had actually led me into some better understanding of this realm of Python. It ties together a bit, in that in reviewing my own code and my own use of properties I see I did use it mostly in comformity with the example outlined in Guido's article on new style classes, and to solve a problem not unrelated to the one I am trying to solve by a "blended class". Specifically, vpython will try to draw anything you send to it, but if you send it a vector outside of some range relative to the current zoom level, the display fritzes. So in retrieving a vector (which I consider an attribute) for purposes of rendering, I was setting a constraint that would be sufficient to avoid the fritz, while keeping the actual values of the vector pure, for the purposes of further calculation. IOW I am managing the retrievel of data from an attribute. Another friend of __getattr__ is __slots__. I was confused by slots as well early on, as I think were many others. I satsified myself - if no one else - that my confusion was in part generated by a general confusion, including some confusion in the What's New in Python2.X (when __slots__ first appeared). It is not too surprising that there can be some degree of misinprepation of Guido's intention in adding a feature to the language. The problem is exasperated when an example of the mechanical use of something like properties is presented - and confused (by folks at my level ,at least) as an actual use case of the feature. I do think this happened with getters and setters and properties, and think there may be some pedagogical lesson in this somewhere. Extending the point - one reason that I think Java cannot work well (or as well) as an introductory language is that it forces one to mechanically understand attribute access modification (and such like) well before one can be expected to understand in any authentic manner the use cases. The result is seditious and wide ranging, because we then settle on an approach where expectations as to authenticity are generally lowered. Much preferable to understand the feature, its mechanics, and its use case as one process. I get there my not concerning myself about features I don't need, until I think I need them. And then determine whether it actually solves my problem. If I manage the mechanics, and it solves my problem - I have my use case. But of course I have a context - my interests. I think teaching programming outside a context - as an abstract discipline - is unavoidably problematic in this regard. Web and network programming, scientific programming, algorithomics, business programming, graphics and entertainment programming ... all provide a context and a context implies use cases. I am not convinced "programming" as a stand-alone subject cannot be optimum as an approach. But I guess that postion runs counter to enough established realities as to be essentially meaningless. My specialty. I do think Python lends itself well to a pedagogoical approach that gives context - whatever it might be - due weight. Which is what brings me here , at least indirectly. And why I am committed to annoy everyone until everyone sees everything my way. ;) Art _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
