[Edu-sig] quantum instance

[ajsiegel@optonline.net]

>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