"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Michael Tobis wrote: >> Also there's the question of typo-driven bugs, where an attempted >> rebinding of "epsilon" instead cerated a reference called "epselon". /cerated/created/ >> (The epselon bug) This is the bane of fortran, and after generations it >> was generally agreed that optionally one could require all references >> to be declared (implicit none). [snip] >> Experienced Pythonistas are oddly resistant to even contemplating >> this change [snip] >> I also don't fully understand the profound aversion to this idea. I don't know if my aversion is profound, and don't think it odd, but I will try to help your understanding, while consenting to contemplating a change ;-). 1. I seem to have a copy-editor mind. Catching and mentally correcting 'cerated' took me less than a second. Being a touch-typist, I catch most of my keying errors as I go, within a few keystrokes. Then I re-read and catch more before submitting -- code or clp postings. I also find for myself that typing the wrong word (usually spelled correctly) is as much a problem as typing the wrong letter. 2. In my own experience, declarations were always tied to type declarations. Name-only declarations to only catch typos is a new and different idea for me. (Type declarations are a different issue, but I really like generic programming and duck 'typing'.) 3. While redundancy can aid error catching, it can also aid error commission. First, neglecting to declare a name would become a crime causing rejection of a program even though it is otherwise perfect. (More laws = more crime.) Second, if someone misdeclares 'epselon' and then, 200 lines later, writes 'epsilon = 1e-10', the declaration is again a problem, not a solution. And the 'name not declared' message will take you to the wrong place to fix the problem -- maybe even to the wrong file. In other words, nannies can be a nuisance. 4. Name declarations will only catch a subset of name typos -- those that create a new name instead of duplicating another declared one. And these should also be easier to catch by eye -- at least for the original writer who has a mental list of valid names. Name declarations will not catch 'x2' mistyped as 'x3' in a program that declares both. So there is no substitute for careful reading and testing. 5. Having users compile a list for the compiler to check strikes me as the wrong (or at least obsolete) solution to the fairly narrow problem of catching keying errors that create an 'invalid' name. Having to type out all names before coding, or having to run up and down a file to add each new name to the namelist, is a nuisance. Let the computer do it! (Which it eventually does anyway.) To catch bad name errors sooner, which is definitely better, have a checker program make and list and ask "are these all intended?" Or have the editor do so and immediately (when a word-ending char is entered) highlight or color the first occurence of a non-keyword, non-builtin name. This would also catch undefined names used in an expression. >> Ream (LEO's author) pointed out to me the Edward-Tufte-ness of Python. >> No wasted ink (except maybe the colons, which I do sometimes find >> myself forgetting on long edits...) 6. I am also a fan of Tufte. To colon or not to colon compound statement header lines was apparently a close call for Guido. The rule requiring colons is both a help and a hindrance. > *If* the rebinding issue were to be addressed for bare names > and the right-most name in a compound name (the only place where it is > currently an issue), > I imagine it would be by introducing a rebinding augmented > assignment operator rather than by introducing variable declarations. This would be better, and could be considered for Python 3. But it would also introduce a new possibility for error. And I think the better way to go is leave the language clean and have more edit-time checking both for syntax and PyLint-PyChecker type checks. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list