[Edu-sig] quantum instance
ajsiegel at optonline.net
Mon Sep 12 22:33:40 CEST 2005
>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
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
I do think Python lends itself well to a pedagogoical approach that gives context - whatever it might be -
Which is what brings me here , at least indirectly.
And why I am committed to annoy everyone until
everyone sees everything my way.
More information about the Edu-sig