declaration of variables?

[Alex Martelli]

André Jonsson wrote:

> Alex Martelli wrote:
>>>:-)  I mostly meant that Python seems more "aware" than most other
>>>:languages of
>>>usability and readability. Do those not count?
>> 
>> Of course; they're the main reasons Python avoids declarations.
> 
> Dare I quote the Python Zen? "Explicit is better than implicit". I
> concurr, declaring a variable explicitly is better than just implicitly
> using, seemingly arbitrary, ones.

You're assuming there is an "implicit declaration" when I
explicitly create a variable by binding it:

    x = 23

i.e. you're assuming this explicit creation implies an implicit
declaration "I'm using x as a variable name".  But it doesn't,
any more than it implies an implicit declaration "I'm using the
literal integer 23".

Why do you think the variable name "x" HAS to be "declared",
either implicitly or implicitly, while the integer literal "23"
suffers from no such constraint?

If it were about typos, as you claim, then why do you think a
variable name is any more typo-prone than an integer literal?

Couldn't I MEAN 32 and have written 23 by mistake, just as
easily as I could MEAN "z" and have written "x" by mistake, as
it's right next to it on the keyboard and looks a bit similar?

There is no way to make

    x = 23

any "more explicit" than it already is: bind the value 23 to
the name x.  That IS what it explicitly SAYS.  There are a
zillion ways to make it more verbose and redundant, many of
which might make it possible for a compiler to catch some
typos a tad earlier.  You seem to _assume_ (again...) that
out of all those zillion ways, the ones that just redundantly
state "I'm about to bind name 'x'!" have any more value than
those that redundantly state "I'm about to use integer 23!".

Why?

The only answer that readily comes to mind is, habit.  You may
be USED to languages that force you to state what names you
are going to use, before letting you use them, but not to
languages that force you to state what integer literals you
are going to use, before letting you use them.  But can you
find any arguments, APART from what habits are ingrained in
you, about why one should be any better than the other?


> Please note that by "declaring" I don't mean like in C/C++ and others
> where you associate an object type with a variable name. Why would I do
> that, that's not very pythonic, is it? I'm only after the declaring of the
> variable _name_ before it is used (e.g. a keyword "var" or something).
> 
> (perhaps I was a bit unclear about this, for me it was implicit (uhm))

That is not the problem -- you didn't mention _types_, just _typoes_,
so I didn't _assume_ you meant what you didn't say (I'm weird that way:
I love taking people at their word).


>> Do you really fail to see how not having to declare variables enhances
>> flexibility?  Has your brain been washed SO thoroughly that you can't
>> see it any longer, or are you just applying less than ALL of your brain
>> to the issue?  Take it as a stimulus to personal growth -- use advanced
>> google groups search to find the hundreds of times this has been already
>> discussed in this group over the years, for example, making it a research
>> project rather than asking for the info to be spoon-fed to you (for the
>> N-plus-1'th time in this group's history).
> 
> See my comment above. As you suggested (ordered?), I did a little googling
> and I must say I couldn't find any good arguments for allowing implicit
> creation of variable names.

I suggested, of course (how could I "order"?!), but since there is no
"implicit creation of variable names" involved at all, then it's hardly
surprising you didn't find anything germane.  In:

    x = 23

the variable name, x, is just as explicit as the integer literal, 23.
There's NOTHING implicit going on here: it's all on the up and up.

The only "implicit binding" (not creation) that comes to mind is that
performed in interactive interpreter sessions when you type an expression
at the prompt -- besides being displayed, the expression's result, if
not None, is implicitly bound to a variable named "_" (one underline).
This is just a minor convenience for those times where you're using
Python as a calculator, and indeed ONLY applies to interactive sessions;
I would never defend similar behavior in *program development* usage!

So why don't you go back to Google and search some more, forgetting that
erroneous fixation on "implicit"?  No arguments are being brought forth
on this thread that weren't brought forth a zillion times before, of
course -- so, given that further on in the thread you claim to be
"getting it" even those no explicit (...) answers had yet been given
to all of these claims and questions of yours, maybe you HAVE been doing
some more googling and not mentioned it...?



> If you by flexibility mean it could be used for creating variable names in
> run-time for things that are not known at the time of writing, sure, but
> in that case a dictionary is of course a better choice.

I fully agree on this, and shudder at the idea of creating _variable_
names (as opposed to attributes and other dictionary entries) that are
not known at coding time.  But that is pretty obviously NOT what I mean.

Rather, consider a hypothetical language where I have to declare ALL
variables AND constants I'll be using later on:

    variables x, y, z, y
    constants 23, 34, 45, 56
       ...
    x = 23

I claim this language is OBVIOUSLY less flexible than Python, i.e., it
is more rigid and brittle -- and I further claim that this is absolutely
obvious.  If I decide the variable name x is silly and should rather
be 'plaka', I now have one more silly redundant spot to find and
change -- just as, if I decide the value 23 is wrong and should rather
be 67, I have ANOTHER silly redundant spot to find and change.

Now _isn't_ this obvious?  Not because of "implicitness" -- the 23
AND the x are quite obviously explicit WITHOUT the begraddled, and
FORTUNATELY hypothetical, 'variables' and 'constants' statements.  But
rather because of the DEFINITION of "flexible" (" 3. Capable or being
adapted or molded; plastic,; as, a flexible language.", as one
online Webster puts it).


> I refrain from making any comments to rant about unit-tests, because I
> feel it
> [cw]ould get long-winded, and is kind of beside the point I'm trying to
> [make.

I think you still hadn't _gotten_ the point of unit tests at all, at
the time you wrote this, if you truly felt they were besides the
point.  Have you, now?  Do you still feel that way...?


Alex