Class Variable Question

[Steve Holden]

"Douglas Alan" <nessus at mit.edu> wrote in message
news:lc4rvpih6y.fsf at gaffa.mit.edu...
> "Alex Martelli" <aleaxit at yahoo.com> writes:
>
> > "Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> wrote:
>
> >>> Your C++ compiler doesn't catch all the typos you can make where
> >>> you type '+' while meaning to type '-', or '>' intending '<', etc,
> >>> for example.
>
> > > Of course. No language catches such typos.
>
> > > It doesn't imply that catching detectable typos (e.g. using names
> > > which are not defined) is worthless!
>
> > No, it just puts that worth in perspective.  It's worth _something_,
> > sure -- but not very much.
>
> You are just dead wrong here, Alex.  Perhaps it's not worth much to
> *you*, in which case you should speak for yourself.  You are not
> speaking for *me*, however, because I know precisely how much it is
> worth to me, and it's worth a *lot*.  You can't deign to tell me how
> much something is worth to me because you have no way of knowing, now
> do you?
>
> This doesn't mean I don't recognize that there are often trade-offs
> between safety and expressive power.  I love Python for its expressive
> power.  I love Lisp for having even more expressive power.
> (Procedural macros, I love you!)  I often curse dynamic languages for
> not catching certain bugs for me at compile time.  Consequently I love
> C++ for helping me make programs that require very little time
> debugging.  On the other hand, I curse C++ for constraining me in all
> sorts of ways that really get under my skin.  If I were forced to
> program in only one language, C++ wouldn't be the one.
>
> If you want to believe that there's One True Answer, feel free, but
> keep it to yourself.  The rest of us realize that life is about
> trade-offs.
>
I hardly think Alex is a "One True Answer" type, given that he frequently
reminds us about features of other languages that make them, in some ways,
"better" than Python.

> Regarding the specific proposal in question -- to require declaring a
> variable before using it -- counter to what you say, this does *not*
> result in any less flexibility or expressive power.  It may result
> sometimes in a bit more typing, but that is it.  There may be many
> good reasons to exclude such a feature from the language at this
> point, backwards compatability being a salient one, but this doesn't
> mean that many people wouldn't find this to be a very useful feature
> to have, and that it wouldn't reduce the debugging load of many
> programmers.  It would certainly significantly reduce mine, since this
> type of typo is one that I'm particularly prone to, and it often
> results in bugs that are rather difficult to track down.
>
Indeed Icon did have just such a declaration, despite its assignmnet
semantics being very similar to those of Python, and unless I misremember
there was even a compile mode equivalent to VB*'s "option explicit".

> Just because you don't make this type of typo a lot, doesn't mean the
> rest of us are so fortunate.  But this is one of the main reasons that
> Python appeals to the "rest of us", as opposed to Perl.  Perl is much
> less typo resistant.  A small typo in Perl is very likely to cause the
> program to do something different and wrong, rather than causing an
> immediately detectible error.  This, in my opinion (and in the opinion
> of the legendary David Moon), is bad programming language design.  A
> language should be as resistant to typos as it is convenient to make
> it.  When the programmer makes a typo, it should in most cases cause
> the program to generate an obvious error.  To disagree with this
> premise is to agree with the Perl philosophy, rather than the Python
> philosophy.  Thank goodness Python wasn't designed with the philosophy
> that unit tests should be used to catch all typos.  If it were, I'd
> hate Python as much as I hate Perl.
>
Well, hate is a counter-producive emotion about a programming language -
that just means you let it live rent-free in your head when it doesn't need
to!

However, I am a little concerned that if "option explicit" or its equivalent
became available then many novices would try to use it and then not
understand why code which uses __setattr__() to create name bindings on the
fly ceased to work.

While I clearly can't question the value of such a feature to *you* [without
expecting an argument ;^], my own feeling is that it doesn't add that much
to the language. All languages have good and bad sides. If you can't learn
to live with this wart then I'm sure a PEP and a patch would be considered.
I can't imagine it would be a huge fix, and those who feel the same as you
would be undyingly grateful.

regards
 StevE