[Edu-sig] quantum instance

[Arthur]

Scott David Daniels wrote:

>I understand that properties and decorators look like obscure magic.
>I ask you to suspend judgment on those (an act of faith), until you
>understand why such features seriously assist the readability of code
>and designs.  This act of faith can be based on a respect for the
>obvious effort somebody has gone to in other ways to make Python such
>a clear and simple language.
>  
>
No faith.  If that were me I'd be writing  "protected" before my methods 
knowing there was a damn good reason for it. That I was practicing good 
objected oriented design.  And that I was solving a problem I just 
didn't happen to know I had, but most assuredly did.

If language design decisions were not all about trade-offs, language 
design would be easy.  It would be as silly for me to suggest that 
properties and decorators do not bring advantages as it would be for you 
to suggest that those advantages come for free.

My argument though is with you, not Guido.  It is about use cases for 
existing features, not about the features themselves.  And in the 
particular case of properties, it was only in going back to Guido's own 
use case illustration that I begin to develop some comfort with why 
properties are there - why they are a neat solution to a limited set of 
problems.  I understand them now more in  terms  of  something akin to  
a GUI event, or a SQL trigger.  You  have a need  to know  when  
something  attempts to set or  get  a particular attribute. The relation 
to the actual attribute might be tenous.  It's an event.  It might begin 
a process that sends an e-mail to Mary. Who knows what. Its all quite 
practical and tangible stuff, though.

It has nothing yet, in my mind, to do with decoupling anything from 
anything else as a matter of good OOP design.

And to the extent you feel properties are well used in that regard, than 
you are developing your own use cases which may or may not be similar to 
Guido's ideas and implicit in the design of the language. And I guess I 
am suggesting you are suggesting too much by suggesting otherwise.


Art


Am I making any sense whatever?

Art


 But I still don't see the connection to XP programming, API design



>I don't object to your not wanting to use such constructs, but rather
>to your desire to remove them from the language (or veto adding them)
>in order to make it "simpler."  I'm sure others have said as much about
>the ridiculous idea of making a value for the square root of minus one,
>or for the incomprehensibly strained "line at infinity."
>
>When you ask what these features provide, I try to explain how they make
>it possible to write some very clear simple code.  I think Kirby will
>attest to the fact that decorators seriously improved the readability
>of his "hypertoons" code.  Decorators should be used sparingly, if at
>all.  That is not to say they shouldn't exist.  The key to understanding
>when decorators are useful can be summarized as "whenever you feel
>you are writing boilerplate your skin should itch."  This doesn't mean
>that you should not write boilerplate on occasion, but rather that you
>should be searching for a way around it.
>
>I tried to explain to you why I found properties such a useful addition.
>Their existence allows me to write code without the "protective
>generality" of always writing accessors and mutators in case, some two
>years hence, I need to change more than the single attribute on a
>mutation, or decide some value that I have been storing is much better
>left calculated.  This was unconvincing to you, but you responded
>more in the vein of "nobody should be allowed to use this, so the code
>I read is simpler."  I am surprised you accept exceptions (a relatively
>recent development in the design of computer languages).
>
>The rule I use in commenting code is that you should not comment use of
>features of a language in code written in that language.  Programmers
>who read code written in Python are responsible for learning Python, and
>there is no excuse for code like:
>     a = range(12)  # Make a list of integers between 0 and 11 inclusive
>The comment slows down your reading of the code and distracts you from
>reading the application itself.  The language is the given.  When you
>choose a language, you buy its tradeoffs.  If you cannot stand
>descriptors, insist on python 2.3.  When you ask what something is good
>for, and get given an explanation that turns out to not make your life
>simpler, don't presume that the examples given are therefore useless.
>You have not spent a career writing code that must be rewritten
>constantly (to accommodate changing requirements); properties help in
>that task, in part because you can avoid using them until necessary,
>with their existence in your back pocket.
>
> > Can we accept the less sophisticated approaches on equal footing?
>
>We can accept the less sophisticated approach to designing programs
>as workable.  Do you seriously think that when designing a language
>equal weight should be given to those that understand the implications
>of a decision and those who "go with their gut?"  It is one thing to
>make ivory tower decisions, and another to know the impact a decision
>might have.
>
>
>--Scott David Daniels
>Scott.Daniels at Acm.Org
>
>_______________________________________________
>Edu-sig mailing list
>Edu-sig at python.org
>http://mail.python.org/mailman/listinfo/edu-sig
>
>  
>