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
