[Edu-sig] quantum instance

[Arthur]

> -----Original Message-----
> From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On
> Behalf Of John Zelle
> Sent: Sunday, September 18, 2005 11:03 PM
> To: edu-sig at python.org
> Subject: Re: [Edu-sig] quantum instance
> 
> 
> 
> Arthur wrote:
> 
> >
> > My only objection to it being there - in fact - is the lack of consensus
> as
> > to the compelling reason it is necessary.  There seems to be agreement,
> in
> > fact, on only this one aspect of the reason for its presence as a
> built_in
> > function.  The fact that the reason is compelling.
> >
> 
> I thought we already agreed that properties are a _convenience_. 

John had written -

"""
Properties exist 
precisely to make it simpler to call methods through attribute access 
syntax, period. My instinct is that, pre-properties, most programmers 
would not have resorted to the __getattr__ magic for these simple cases; 
they would just provide a method-call API (as I did for my graphics 
library). With properties, I would probably now take the other route.
"""

Properties - which were meant as a *mere convenience* - seem here to  be
influencing an outcome. To me, a not insignificant outcome. Not what one
thinks of when one thinks of mere convenience.

Kirby believes - is "adamantly" too strong -  that properties were added to
the language just so as to influence this kind of outcome. To bring Python
more in line with generally accepted OOP thinking and practice.  

That is not an unreasonable thing to believe when one considers the name of
the function, the general milieu of the influence of the leading languages
such as Java and C#.

I happen not, however, to believe it. 

Perhaps because I don't want to.

My thought is that it is highly preferable - except in highly unusual
circumstances - to call methods through method call syntax and to access
attributes through attribute access syntax.  For reasons that are only
obvious - we know better whether we are accessing something akin to a stored
value or, in contrast, calling for something akin to a calculation of a
value. Which is information. Information is good.

Knowing that there is authority in OOP theory that appears to be directly
contrary to my preference here. And not caring a whole lot.

The question is: 

Is the inclusion of properties into Python in fact to any extent as Kirby
(and you, I think) seem to interpret it - an implicit vote on this matter? 

That is the essential question I have been trying to pursue - not whether it
is more or less convenient.  It is more.  

But its cost is the extent to which it influences outcomes in unintended
directions. If it was intended to influence toward greater use of the
technique of calling methods through attribute access syntax, it is an
unambiguous win.  Because it  - witness your statement above - undoubtedly
does.

If one believes - as do I - that there was no such intention, then the
addition of properties has suffered from the fate of having unintended
consequences.  And in that sense cannot be viewed as an unambiguous win.

Art