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 >[EMAIL PROTECTED] > >_______________________________________________ >Edu-sig mailing list >Edu-sig@python.org >http://mail.python.org/mailman/listinfo/edu-sig > > > _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
