Arthur wrote: > Back to where I started to get testy: > > properties and decorators > > I honestly believe that if I had seen them in my first Python Triangle > class I would have judged myself to be looking at a language that might > be swell - for somebody else. But a little too magical, > self-referential and self-involved - for my own taste. And would have > moved on.
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. 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