variable declaration

[Alex Martelli]

Alexander Zatvornitskiy
<Alexander_Zatvornitskiy at p131.f3.n5025.z2.fidonet.org> wrote:
   ...
>  AM> The fact that in Python there are ONLY statements, NO declarations,
> ===
> def qq():
>  global z
>  z=5
> ===
> What is "global"? Statement? Ok, I fill lack of "var" statement:)

'global' is an ugly wart, to all intents and purposes working "as if" it
was a declaration.  If I had to vote about the one worst formal defect
of Python, it would surely be 'global'.

Fortunately, it's reasonably easy to avoid the ugliness, by avoiding
rebinding (within functions) global variables, which tend to be easy. 

What you keep demanding is a way to inject far worse ugliness, and in a
context in which the typical behavior of pointy-haired bosses will be to
make it unavoidable for many of the people who work with Python.  I am
strongly convinced that, if you had your wish, the total amount of
happiness in the world would be quite substantially diminished, and I
will do anything I can to stop it from happening.


>  >> Fine! Let interpreter never show us errors like division by zero,
>  >> syntax errors, and so on. If file not found, library don't need to
>  >> say it. Just skip it!!! Because every, even simple, test will find
>  >> such bugs. Once you have unit tests, the added value of <anything>
>  >> is tiny, and their cost remains.
>  AM> Another false assertion, and a particularly ill-considered one in ALL
>  AM> respects. Presence and absence of files, for example, is an
   ...
> Here, you take one detail and bravely fight with it. Just try to understand
> meaning of my sentence, in all. It will help:)

I tear ONE of your examples to pieces in gory detail, because it's not
worth doing the same over and over again to every single piece of crap
you filled that sentence with -- very similar detailed arguments show
how utterly inane the whole assertion is.

There IS no meaning to your (several) sentences above-quoted, that it
can help anybody to "try to undestand": it's simply an insanely bad
attempt at totally invalid parallels.

>  AM> In brief: you're not just wrong, you're so totally, incredibly,
>  AM> utterly and irredeemably wrong that it's not even funny.
> Hey, take it easy! Relax, reread that piece of text. It was written with smile
> on my lips. Here it is for your convenience:

Do yourself a favor: don't even _try_ to be funny in a language you have
so much trouble with.  Your communication in English is badly enough
impaired even without such lame attempts at humor: don't made bad things
even worse -- the result is NOT funny, anyway, just totally garbled.

I'm not a native English speaker, either, so I keep a careful watch on
this sort of thing, even though my English would appear to be a bit
better than yours.


> Again, skip small details and take a look on the problem "in general".
Here is,

There IS no ``problem "in general"'': Python does a pretty good job of
diagnosing as many errors as can be diagnosed ***without demanding
absurdities such as redundancy on the programmer's part***.  Period.

> again, the main idea:
> ========
> Or, maybe, we will ask interpreter to find and prevent as many errors as he
> can?

To show how absurd that would be: why not force every line of the
program to be written twice, then -- this would help diagnose typos,
because the interpreter could immediately mark as errors any case in
which the two copies aren't equal.  Heck, why stop at TWICE -- even MORE
errors will be caught if every line has to be written TEN times.  Or a
million.  Why not?  *AS MANY ERRORS AS [it] CAN* is an *ABSURD*
objective, if you don't qualify it with *WHILE AVOIDING ANY ENFORCED
REDUNDANCY* introduced solely for that purpose.

As soon as you see that such redundancy is a horror to avoid, you will
see that Python's design is essentially correct as it is.


> You wrote about "substantial cost" of var declarations. Yes, you are
> write. But think about the cost of lack of var declarations. Compare time
> that programmer will waste on search for the reason of bug caused by such
> typo, plus time what programmer will waste while remembering exact
> variable name.

I've been programming essentially full-time in Python for about three
years, plus a few more years before then when I used Python as much as I
could, even though my salary was mostly earned with C++, Visual Basic,
Java, perl, and so on.  My REAL LIFE EXPERIENCE programming in Python
temms me that the time I've "wasted on search" etc due to the lack of
variable declaration is ***FUNDAMENTALLY NOTHING AT ALL***.  Other
hundreds of thousands of man-hours of similar Python programming
experience on the part of hundreds of other programmers essentially
confirm these findings.

Your, what, TENS?, of man-hours spent programming in Python tell you
otherwise.  Fine, then *USE ANOTHER LANGUAGE* and be happy, and let US
be just as happy by continuing to use Python -- almost all languages do
things the way you want, so ***leave alone*** the few happy oases such
as Python and Ruby where programmers can happily avoid the idiotic
redundancy of variable declarations, and not even PHBs can impose
otherwise.


> Compare it with time for looking on message:
> ===
> Traceback (most recent call last):
>   File "<pyshell#16>", line 5, in -toplevel-
>     epselon
> NameError: name 'epselon' is not defined, in strict mode
> ===
> and fixing it, plus time on typing three letters (or less).

Like experience shows in all cases of such idiotic redundancies, the
real waste of time comes in the BAZILLION cases where your program WOULD
be just fine -- except you missed one redundancy, so you have to go and
put it in to make the gods of redundancy happy again.  That happens with
VASTLY higher frequency than the cases where the enforced redundancy
saves you a comparable amount of time by catching some error earlier.

Plus, the FALSE confidence coming from redundancy works against you by
kidding you into believing that a BAZILLION other typos can't still be
lurking in your code, just because you've eliminated one TINY subset of
such typos (typos in names of variables that happen to leave the mangled
names syntactically valid BUT different from any other variable) -- and
*ONLY* that tiny subset of such typos which happened on the left of a
plain '=' (since all others, happening on the RIGHT of an '=' or on the
left of an _augmented_ '=', were already caught), and ONLY regarding
barenames (such typos on any but the rightmost component of compound
names were already caught intrinsically, and catching those on the
rightmost component is trivially easier than introducing a {YECCCCHH}
'vars' as you so stubbornly insist)...

Basically you're focusing on maybe ONE IN A MILLION of the errors you
could make and want to pervert the whole foundation of Python, and
seriously hamper the productivity of hundreds of thousands of Python
programmers in every normal case!, to save maybe two minutes in such a
one-in-a-million case.

I consider this one of the worst ideas to have been proposed on this
newsgroup over the years, which _IS_ saying something.  Oh, you're not
the only one, for sure -- there must have been a dozen before you, at
least.  Fortunately, even though almost each and every one of them has
wasted more of everybody's time with such ideas, than even their
scare-tactics claim of ``wastes of time'' due to lack of declarations
could account for, Python is still intact.  A few of the stubborn lovers
of declarations tried doing without, and, to their astonishment, found
out that everybody else, with years of Python experience, was right, and
they, without ANY such experience, were wrong (just incredible, eh?!);
others have gone away to find their bliss in Perl, PHP, or whatever --
good riddance, and don't let the door slam behind you as you go, please.


Alex