"no variable or argument declarations are necessary."

Steven D'Aprano steve at REMOVETHIScyber.com.au
Mon Oct 3 12:48:31 EDT 2005


On Mon, 03 Oct 2005 13:58:33 +0000, Antoon Pardon wrote:

> Op 2005-10-03, Duncan Booth schreef <duncan.booth at invalid.invalid>:
>> Antoon Pardon wrote:
>>
>>> A language where variable have to be declared before use, would allow
>>> to give all misspelled (undeclared) variables in on go, instead of
>>> just crashing each time one is encounterd.
>>
>> Wrong. It would catch at compile-time those misspellings which do not 
>> happen to coincide with another declared variable.
> 
> Fine, it is still better than python which will crash each time
> one of these is encountered.

Python doesn't crash when it meets an undeclared variable. It raises an
exception.

This lets you do things like:

try:
    False
except NameError:
    print "bools are not defined, making fake bools..."

    False = 0
    True = not False

    def bool(obj):
        if obj: return True
        else: return False

    # not identical to real bools, but close enough to fake it (usually)


>> Moreover, it adds a burden on the programmer who has to write all those 
>> declarations,
> 
> So? He has to write all those lines of code too.
> 
> People often promote unittesting here. Writing all those unittest is
> an added burden too. But people think this burden is worth it.

Yes, but there is no evidence that pre-declaration of variables is a
burden worth carrying. It doesn't catch any errors that your testing
wouldn't catch anyway.


> I think writing declaration is also worth it. The gain is not as
> much as with unittesting but neither is the burden, so that
> balances out IMO

Speaking as somebody who spent a long time programming in Pascal, I got
heartedly sick and tired of having to jump backwards and forwards from
where I was coding to the start of the function to define variables.

It got to the stage that sometimes I'd pre-define variables I thought I
might need, intending to go back afterwards and delete the ones I didn't
need. When the programmer is having to to jump through hoops to satisfy
the compiler, there is something wrong.


>> and worse it adds a burden on everyone reading the code who 
>> has more lines to read before understanding the code.
> 
> Well maybe we should remove all those comments from code too,
> because all it does is add more lines for people to read.

Well-written comments should give the reader information which is not in
the code. If the comment gives you nothing that wasn't obvious from the
code, it is pointless and should be removed.

Variable declarations give the reader nothing that isn't in the code. If I
write x = 15, then both I and the compiler knows that there is a variable
called x. It is blindingly obvious. Why do I need to say "define x" first?

Pre-defining x protects me from one class of error, where I typed x
instead of (say) n. That's fine as far as it goes, but that's not
necessarily an _error_. If the typo causes an error, e.g.:

def spam(n):
    return "spam " * x  # oops, typo

then testing will catch it, and many other errors as well. Declaring the
variable doesn't get me anything I wouldn't already get.

But if it doesn't cause an error, e.g.:

def spam(n):
    if n:
        return "spam " * n
    else:
        x = 0  # oops, typo
        return "spam " * n
    
This may never cause a failure, since n is always an integer. Since my
other testing guarantees that n is always an integer, it doesn't matter
that I've created a variable x that doesn't get used. Yes, it would be
nice for the compiler to flag this, but if the cost of that niceness is to
have to define every single variable, I can live without it.


>> Also there is 
>> increased overhead when maintaining the code as all those declarations have 
>> to be kept in line as the code changes over time.
> 
> Which is good. Just as you have to keep the unittests in line as code
> changes over time.

That is not the same at all. Changing variable declarations needs to be
done every time you modify the internal implementation of a function.
Changing the unittests, or any other testing for that matter, only needs
to be done when you change the interface.

In principle, if you have an interface designed up front before you write
any code, you could write all your tests at the start of the project and
never change them again. You can't do that with variable declarations,
since every time you change the implementation you have to change the
declarations.


-- 
Steven.




More information about the Python-list mailing list