declarations summary

[Terry Reedy]

"Nick Coghlan" <ncoghlan at iinet.net.au> wrote in message 
news:42076A79.8090507 at iinet.net.au...

> 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