variable declaration

[Arthur]

On Sat, 5 Feb 2005 17:00:15 +0100, aleaxit at yahoo.com (Alex Martelli)
wrote:

>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'.

Venturing in - again - over my head. Brave or stupid.  

But the fact that I cannot dissect Python byte code, doesn't mean I
can't follow the logic or illogic of an argument. Or hear, or
interpret reasonably well what I hear.

I will accept that global is a horribly wart for reasons that I don't
understand.  (worse than print>> for more reasons I don't understand
as well ?)

But making the argument that it is a wart *because* it is declarative,
and therefore a violation  of Python's purity is hard for me. 

"""
The fact that in Python there are ONLY statements, NO declarations, is
a completely different LEVEL of issue -- a totally deliberate design
choice taken in full awareness of all of its implications.  
"""

Global is there. It was put there by someone who presumably knows his
declaratives. So simply as a matter of logic, your assertion doesn't
hold up.

And as we learn, what is true of Python today is not necessarily what
is true of Python tomorrow.  And my understanding of the arguments
surrounding the decorator debate suggested to me that there is
decently strong sentiment among a segment of the folks who represent
"the community" much better than do I, that if there indeed has been
any purist stricture about the use of declaratives in the kanguage, it
may be wise to loosen it.

Why is it logical to believe that a language that is purely anything
will best do.  Python prides itself on being multi-paradigm, thought
I. Except Ales says no declarations allowed, with great authority. 

Do they belong in any language? Solve problems in any language?

If so, why is that Python is denied them?

Ultimately I don't think Guido chooses to be restricted by these kinds
of notions of purity.  And suspect that if and when declarations best
solve real problems, they will brought to bare - without regard to
such notions.

I am sure you could if you wanted provide a highly competent - OK
brilliant - answer to why given this and that aspect of Python it
can't and won't and shouldn't be.. 

But you are a polemicist at heart, it seems to me - on observation
from non-techncial discussion.

So all my technical limitations aside, I still don't think I could
decipher where polemics ends, and analysis begins.

Squash me like a bug, it you like. But I am not - just so you know -
meaning to be even unfriendly, much less hostile.


Art


>
>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