Movatterモバイル変換
[0]ホーム
Class Variable Question
Steve Holdensholden at holdenweb.com
Mon Apr 16 07:53:36 EDT 2001
"Douglas Alan" <nessus at mit.edu> wrote in messagenews: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 frequentlyreminds 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 assignmnetsemantics being very similar to those of Python, and unless I misrememberthere 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 needto!However, I am a little concerned that if "option explicit" or its equivalentbecame available then many novices would try to use it and then notunderstand why code which uses __setattr__() to create name bindings on thefly ceased to work.While I clearly can't question the value of such a feature to *you* [withoutexpecting an argument ;^], my own feeling is that it doesn't add that muchto the language. All languages have good and bad sides. If you can't learnto 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 youwould be undyingly grateful.regards StevE
More information about the Python-listmailing list
[8]ページ先頭