variable declaration

[Alexander Zatvornitskiy]

Hello All!

I'am novice in python, and I find one very bad thing (from my point of view) in
language. There is no keyword or syntax to declare variable, like 'var' in
Pascal, or special syntax in C. It can cause very ugly errors,like this:

epsilon=0
S=0
while epsilon<10:
S=S+epsilon
epselon=epsilon+1
print S

It will print zero, and it is not easy to find such a bug!

Even Visual Basic have 'Option Explicit' keyword! May be, python also have such
a feature, I just don't know about it?

Alexander, za**@bk.ru

[Alex Martelli]

Arthur <aj******@optonline.com> wrote:

Do the STUPID firms use Python as well.
Yes, they're definitely starting to do so.

Why?

The single most frequent reason is that some techie sneaked it in, for
example "just for testing" or "to do a prototype" or even without any
actual permission. Firms hardly ever follow the "build one to throw
away" dictum (and some argue that the dictum is wrong and the firms are
right), so, once it's in, it's in.

There are other reasons, such as "it's intolerable that we're using half
a dozen different languages, we need to unify all our software and
rewrite it into just one language" -- a rather silly reason, and this
plan (to rewrite perfectly good working software just for the purpose of
having it all in one language) generally doesn't come to fruition, but
meanwhile there are very few candidate languages that _could_ fill all
the different niches *and* not bust the PHB's softare-purchase business.

Even the various "success stories" we've collected (both on websites,
and, more impressive to PHBs, into paper booklets O'Reilly has printed)
play a role. ``NASA uses it for space missions, so of course we must
use it to control our hot dog franchises'' -- we DID say we're talking
about stupid firms, right?

This is a good development, overall. Against stupidity, the gods
themselves contend in vain; Python's entrance into stupid firms broadens
its potential appeal from less than 10% to around 100% of the market,
which is good news for sellers of books, tools, training, consultancy
services, and for Python programmers everywhere -- more demand always
helps. *BUT* the price is eternal vigilance...
Alex

[Arthur]

On Sun, 6 Feb 2005 08:47:31 +0100, al*****@yahoo.com (Alex Martelli)
wrote:

Even the various "success stories" we've collected (both on websites,
and, more impressive to PHBs, into paper booklets O'Reilly has printed)
play a role. ``NASA uses it for space missions, so of course we must
use it to control our hot dog franchises'' -- we DID say we're talking
about stupid firms, right? This is a good development, overall. Against stupidity, the gods
themselves contend in vain; Python's entrance into stupid firms broadens
its potential appeal from less than 10% to around 100% of the market,
which is good news for sellers of books, tools, training, consultancy
services, and for Python programmers everywhere -- more demand always
helps. *BUT* the price is eternal vigilance...

What if:

There was a well conducted market survey conclusive to the effect that
adding optional strict variable declaration would, in the longer run,
increase Python's market share dramatically.

It just would.

More books. more jobs, etc.

Why would it?

My sense of how the real world works is that there is going to be one
anti-Python advocate lying in wait for the first bug he can find that
he can say would have been caught if Python had strict variable
declaration, as he always knew it should.

He wants to be the PHB someday. The current PHB knows that, and since
being sensitive to these kinds of realities is how he got to be the
PHB, he is too smart to open himself up to this kind of risk.

The PHB can pretty safely make the use of the option optional. As
long as he is a position to jump down the throat of the programmer who
created the bug.

"The option is there, why the hell didn't you use it".

What is the correct language design decision in light of these
realities?

My answer is, I think, the same as your answer. In fact, its simpler
for me - I don't write Python books.

But isn't this kind of where Python is at the moment?

Art

[Roy Smith]

In article <1g*****************************@yahoo.com>,
al*****@yahoo.com (Alex Martelli) wrote:

This is a good development, overall. Against stupidity, the gods
themselves contend in vain; Python's entrance into stupid firms broadens
its potential appeal from less than 10% to around 100% of the market,
which is good news for sellers of books, tools, training, consultancy
services, and for Python programmers everywhere -- more demand always
helps. *BUT* the price is eternal vigilance...

I'm not sure what that last sentence is supposed to mean, but I have
visions (nightmares?) of someday having ANSI, ISO, IEEE, or some other such
organization notice that something useful exists which they haven't yet
standardized/broken and decide to form a committee to do it.

[Alex Martelli]

Roy Smith <ro*@panix.com> wrote:

which is good news for sellers of books, tools, training, consultancy
services, and for Python programmers everywhere -- more demand always
helps. *BUT* the price is eternal vigilance...
I'm not sure what that last sentence is supposed to mean, but I have

You seem to...:
visions (nightmares?) of someday having ANSI, ISO, IEEE, or some other such
organization notice that something useful exists which they haven't yet
standardized/broken and decide to form a committee to do it.

....so we'd better be careful (==eternal vigilance)...
Alex

[Jeremy Bowers]

On Sun, 06 Feb 2005 07:30:33 -0500, Arthur wrote:

What if:

There was a well conducted market survey conclusive to the effect that
adding optional strict variable declaration would, in the longer run,
increase Python's market share dramatically.

It just would.

Why would it?
What if, by eating a special mixture of cheddar and marshmallows, you
could suddenly fly?

It just would.

Why would it?

(The point, since I don't trust you to get it: The "absurd question" is
neither a valid argument technique, nor is it even good rhetoric. You
might as well go straight to "What if I'm right and you're wrong? What
then, huh?")
My sense of how the real world works is that there is going to be one
anti-Python advocate lying in wait for the first bug he can find that he
can say would have been caught if Python had strict variable declaration,
as he always knew it should.

He wants to be the PHB someday. The current PHB knows that, and since
being sensitive to these kinds of realities is how he got to be the PHB,
he is too smart to open himself up to this kind of risk.

The PHB can pretty safely make the use of the option optional. As long as
he is a position to jump down the throat of the programmer who created the
bug.
You really aren't very good at this "debate" thing.

"Look, I can construct a certain scenario whereby the dangers you propose
don't occur (assuming that I'm even right about my scenario in the first
place which is highly questionable). How do you respond to *that*? Huh?
Huh? Huh? Where's your precious 'overwhelming pattern' now?"

It hasn't gone anywhere.
What is the correct language design decision in light of these realities?
In light of the above, I question your use of the plural.
But isn't this kind of where Python is at the moment?

Only for you.

Despite the tone of the rest of this message, I mean that. It's obviously
a huge stumbling block for you. It isn't for the rest of us, and once
again, I assure you, it's going to take more than spinning implausible
isolated entirely theoretical examples to convince us otherwise.

Not only do you argue solely from anecdote, even the aforementioned
"implausible isolated entirely theoretical" anecdote, it appears to be all
you understand. You're going to have to do better than that. Producing a
*real* study that shows declaration would be a good thing, instead of an
implausible entirely theoretical one, would be a good start.

[Arthur]

On Sun, 06 Feb 2005 08:20:29 -0500, Jeremy Bowers <je**@jerf.org>
wrote:

On Sun, 06 Feb 2005 07:30:33 -0500, Arthur wrote:

What if:

There was a well conducted market survey conclusive to the effect that
adding optional strict variable declaration would, in the longer run,
increase Python's market share dramatically.

It just would.

Why would it?
What if, by eating a special mixture of cheddar and marshmallows, you
could suddenly fly?

It just would.

Why would it?

(The point, since I don't trust you to get it: The "absurd question" is
neither a valid argument technique, nor is it even good rhetoric. You
might as well go straight to "What if I'm right and you're wrong? What
then, huh?")

You miss my point in so many ways, its not worth enumerating. Most
essentially is the fact that I am making no effort to be right about
anything, and don't care to be right about anything, and know better
than to hope to be right about anything here.

My sense of how the real world works is that there is going to be one
anti-Python advocate lying in wait for the first bug he can find that he
can say would have been caught if Python had strict variable declaration,
as he always knew it should.

He wants to be the PHB someday. The current PHB knows that, and since
being sensitive to these kinds of realities is how he got to be the PHB,
he is too smart to open himself up to this kind of risk.

The PHB can pretty safely make the use of the option optional. As long as
he is a position to jump down the throat of the programmer who created the
bug.
You really aren't very good at this "debate" thing.

I'm a lot bettter at it, I think, when I am trying to debate.

*You* don't get it. I'm not.

"Look, I can construct a certain scenario whereby the dangers you propose
don't occur (assuming that I'm even right about my scenario in the first
place which is highly questionable). How do you respond to *that*? Huh?
Huh? Huh? Where's your precious 'overwhelming pattern' now?"

It hasn't gone anywhere.

What is the correct language design decision in light of these realities?
In light of the above, I question your use of the plural.

And you would question the use of the singular, as well, if I catch
your dirft.

But isn't this kind of where Python is at the moment?
Only for you.

Despite the tone of the rest of this message, I mean that. It's obviously
a huge stumbling block for you. It isn't for the rest of us, and once
again, I assure you, it's going to take more than spinning implausible
isolated entirely theoretical examples to convince us otherwise.

I don't know who the rest of you are. Whoever the rest of you are,
I'm OK with not being one of you. Really I am.
Not only do you argue solely from anecdote, even the aforementioned
"implausible isolated entirely theoretical" anecdote, it appears to be all
you understand. You're going to have to do better than that. Producing a
*real* study that shows declaration would be a good thing, instead of an
implausible entirely theoretical one, would be a good start.

I am arguing, to the extent that I am arguing, from the hypothetical.
You can counter by saying that my hypothical premise is not even a
possiblity.

Among what you don't understand. I think, is that I would be wishing
that you were right. But of course you wouldn't be.

Art

[Nick Coghlan]

Roy Smith wrote:

I'm not sure what that last sentence is supposed to mean, but I have
visions (nightmares?) of someday having ANSI, ISO, IEEE, or some other such
organization notice that something useful exists which they haven't yet
standardized/broken and decide to form a committee to do it.

So long as the committee consists of one member who has the initials GvR and is
known as the Python BDFL, we should be OK ;)

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Antoon Pardon]

Op 2005-02-05, Roy Smith schreef <ro*@panix.com>:

In article <MS*****************************@fidonet.org>,
Al*********************@p131.f3.n5025.z2.fidonet.o rg (Alexander
Zatvornitskiy) wrote:

And, one more question: do you think code like this:

var S=0
var eps

for eps in xrange(10):
S=S+ups

is very bad? Please explain your answer:)

Let me answer that by way of counter-example.

Yesterday I was writing a little perl script. I always use "use strict" in
perl, which forces me to declare my variables. Unfortunately, my code was
giving me the wrong answer, even though the interpreter wasn't giving me
any error messages.

After a while of head-scratching, it turned out that I had written "$sum{x}
+= $y" instead of "$sum{$x} += $y". The need to declare variables didn't
find the problem. I *still* needed to test my work. Given that I needed
to write tests anyway, the crutch of having to declare my variables really
didn't do me any good.

I you come to the conclusion that it doesn't do you any good, why did
you use it? I find it odd that someone who prefers to use it in a
language where it is optional is argues that it shouldn't be included
as an option is an other language. I would think that if he thinks
it so bad he wouldn't use it in that other language in the first place.

--
Antoon Pardon

[Alexander Zatvornitskiy]

ðÒÉ×ÅÔ Alex!

05 ÆÅ×ÒÁÌÑ 2005 × 17:00, Alex Martelli × Ó×ÏÅÍ ÐÉÓØÍÅ Ë All ÐÉÓÁÌ:

AM> The fact that in Python there are ONLY statements, NO
AM> declarations,
What is "global"? Statement? Ok, I fill lack of "var" statement:) AM> 'global' is an ugly wart,

Ok,
===
def hi():
print "hello!"
===
What is it? Statement or declaration? After interpreter see this lines, it add
information about function "hi" and it's body to his memory. Look at this:
var S
Interpreter see this line and add information about variable S to the memory. I
don't find big difference.
By the way keyword "def" is as bad as "var", from your point of view? :)

AM> to all intents and purposes working "as if"
AM> it was a declaration. If I had to vote about the one worst formal
AM> defect of Python, it would surely be 'global'.
Second worsest - 'def'? :)

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

:) "Star Wars IX" :)
If your boss is rather smart, you can explain your position. Even if he is not
agree, he will give you freedom.
If your boss is stupid, find another one:)
Of course, if you will explain him in such a way "hey, boss, you will never
understand this language, go back to your playground", you have no chance:)

AM> There IS no meaning to your (several) sentences above-quoted, that it
AM> can help anybody to "try to undestand": it's simply an insanely bad
AM> attempt at totally invalid parallels.
I understand your opinion. From my point of view, you don't even try to
understand.
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: AM> Do yourself a favor: don't even _try_ to be funny in a language you
AM> have so much trouble with. Your communication in English is badly
AM> enough impaired even without such lame attempts at humor: don't made
AM> bad things even worse -- the result is NOT funny, anyway, just totally
AM> garbled.

But, I am friendly, even with my opponents. I think it is my good trait.

AM> There IS no ``problem "in general"'': Python does a pretty good job
AM> of
AM> diagnosing as many errors as can be diagnosed ***without demanding
AM> 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?
AM> To show how absurd that would be: why not force every line of the
AM> program to be written twice, then -- this would help diagnose typos,
AM> because the interpreter could immediately mark as errors any case in
AM> which the two copies aren't equal. Heck, why stop at TWICE -- even
AM> MORE errors will be caught if every line has to be written TEN times.
AM> Or a million. Why not? *AS MANY ERRORS AS [it] CAN* is an
AM> *ABSURD* objective, if you don't qualify it with *WHILE AVOIDING ANY
AM> ENFORCED REDUNDANCY* introduced solely for that purpose.

Hmm. It's clever move. I can't resist here.
Well, I agree that keyword "var" is to long. Programs are not look pretty with
it, especialy in situations like this:
for var x in xrange(10):...
But I still think declaration of variables is good idea. But with shorter
syntax. May be, smth like this: ~S, or `S or .S, or S`, S~ , S. , and so on. Of
course it must be optional feauture: use it if you want or don't use if you
don't want.

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

AM> Your, what, TENS?, of man-hours spent programming in Python tell you
AM> otherwise.

Do you ever wrote programs for engineering calculations? Dozens of variables
with names like lambda_1, phi_k, epsilon, d2f_dx2, grad_z and so on. You wrote
it, start it and see that it work wrong. You start debugging. Look at every
line, and attentively compare written in the screen and in the paper: is it
correct? My experience say that often errors caused by typos in names of vars
(more precisely, writing one name instead of another).
You may say: give better names for your variables! Ha, I'am often don't
understand that they mean! They are written for me by an engineer! He is
thinking in that terms, they is natural for him. He and his collegues want to
see error messages as "lambda_1 must be between 2 and 75".
So I'am sure: any checking will help. If I'am sure that interpreter can't
create "epsElon" I will not check the left side of "=" operator. If I can't be
sure in it, I will check it. It will take time. That's all.
Recent years I'am not often work with engineering calculations, but I want to
use Python for them also - if they will be.

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

Bad boss will find a way to make your life worse:) With, or without,
availibility of variable declarations.
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).

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

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

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

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

Don't be so ... I don't find the equivalent english word. Smth like: Take it
more easy.
Alexander, za**@bk.ru

[Alex Martelli]

Alexander Zatvornitskiy
<Al*********************@p131.f3.n5025.z2.fidonet. org> wrote:

?????? Alex!

05 ??????? 2005 ? 17:00, Alex Martelli ? ????? ?????? ? All ?????:

>> AM> The fact that in Python there are ONLY statements, NO
>> AM> declarations,
>> What is "global"? Statement? Ok, I fill lack of "var" statement:)

AM> 'global' is an ugly wart,

Ok,
===
def hi():
print "hello!"
===
What is it? Statement or declaration?

Statement, obviously.
After interpreter see this lines, it add
information about function "hi" and it's body to his memory. Look at this:
Utterly false, like most of the unqualified, arrogant assertions you
keep making.

If and when the interpreter *EXECUTES* this *STATEMENT*, it binds or
rebinds name 'hi' in the current scope to a new function object -- just
like it would if the statement was, say, an assignment such as:

hi = new.function( ... )

with the appropriate arguments. So, wondering if `def' "is a
declaration" is just about as stupid as wondering if an assignment
statement "is a declaration".

If the statement is not EXECUTED -- it does not suffice for it to be
merely *SEEN*, and your assertion about this is pure and unadulterated
POPPYCOCK, just like everything else you've been posting -- then no new
function object is made, and nothing is bound or re-bound to name 'hi'
in the current scope -- for 'def' just as for assignment, same thing.

If either statement is executed repeatedly, it builds a new function
object each time. Not particularly meaningful when the function object
is trivial in this way, but if it was at all significant that would be
easy to verify -- just give the function some meaningfully mutable
values, such as argument defaults, and you can mutate each independent
function object separately at will.

'global', of course, is, alas, totally different -- which makes it a
wart.

var S
Interpreter see this line and add information about variable S to the
memory. I don't find big difference.
That's because you criticize what you completely fail to understand, and
your arrogance is such that you appear to not feel any need to perform a
modicum of research to avoid showing everybody your total ignorance
coupled with perfect willingness to spout about subjects you don't
grasp.
By the way keyword "def" is as bad as "var", from your point of view? :)
Obviously not: 'def' is an excellent executable statement, just like
'class' or assignment. 'var' is (or rather, thank Guido, WOULD BE, if
Python developers were as incompetent and incapable as you) reason
enough to throw the language in the closest dustbin.
Do you ever wrote programs for engineering calculations? Dozens of variables

I was a senior developer for a major CAD SW house for 12 years, rising
to the rank of "senior software consultant". Engineering enough for
you?
with names like lambda_1, phi_k, epsilon, d2f_dx2, grad_z and so on. You wrote

Not when _I_ wrote the code. Clarity of naming is always important,
whether the computations are "engineering", "accounting", or whatever.
You may say: give better names for your variables! Ha, I'am often don't
understand that they mean! They are written for me by an engineer! He is
A good programmer understand what he or she IS programming. I am not
surprised that you're used to coding without a glimmer of comprehension:
your readiness to publically post unfounded criticisms of a language
about which you're most obviously totally clueless clearly show that
doing without comprehending is something you're quite used to.
AM> wrong (just incredible, eh?!); others have gone away to find their
AM> bliss in Perl, PHP, or whatever -- good riddance, and don't let the
AM> door slam behind you as you go, please.

Don't be so ... I don't find the equivalent english word. Smth like: Take it
more easy.

Don't have much experience with Southern Europeans of hot Latin blood,
hm? We're ALWAYS intense about our feelings. Of course, afterwards we
go bask in our delightful weather sipping our delightful cheap wines, so
there's no risk of our lives being stressful -- it must be very
different in the frozen North.
Alex

[Steve Holden]

Alexander Zatvornitskiy wrote:

ðÒÉ×ÅÔ Alex!

05 ÆÅ×ÒÁÌÑ 2005 × 17:00, Alex Martelli × Ó×ÏÅÍ ÐÉÓØÍÅ Ë All ÐÉÓÁÌ:

>> AM> The fact that in Python there are ONLY statements, NO
>> AM> declarations,
>> What is "global"? Statement? Ok, I fill lack of "var" statement:) AM> 'global' is an ugly wart,

Ok,
===
def hi():
print "hello!"
===
What is it? Statement or declaration? After interpreter see this lines, it add
information about function "hi" and it's body to his memory. Look at this:
var S
Interpreter see this line and add information about variable S to the memory. I
don't find big difference.
By the way keyword "def" is as bad as "var", from your point of view? :)
If your colloquial English is good enough to understand the word
"bollocks" then you might begin to realize how irritating your arguments
are becoming.

If, as you suggest, def were a declaration, then it should either not be
possible to write

if __debug__:
def func(x):
print x, "is bollocks"

or, if it were possible, then func would have a code object bound to it
whether or not __debug__ were true.

In point of fact this is perfectly legal Python, which results in no
binding to the name func when __debug__ is false, precisely *because the
def statement is executable* - and it is so by design.
AM> to all intents and purposes working "as if"
AM> it was a declaration. If I had to vote about the one worst formal
AM> defect of Python, it would surely be 'global'.
Second worsest - 'def'? :)
The reason global is a wart can clearly be seen in the following example:

x = 3
def f(tf, v): ... if tf:
... global x
... x = v
... f(0, 5)
x 5

This makes it apparent that the global statement is *not* executable,
the only one in the language that is not.

[...]
But, I am friendly, even with my opponents. I think it is my good trait.
You are, of course, entitled to your opinion, self-serving though it may
be. A friendly idiot is still an idiot.

[...]
But I still think declaration of variables is good idea. But with shorter
syntax. May be, smth like this: ~S, or `S or .S, or S`, S~ , S. , and so on. Of
course it must be optional feauture: use it if you want or don't use if you
don't want.
Why not make it even shorter by omitting it altogether. Oh, sorry, it
can be as short as you want as long as it isn't actually zero length?
This is insanity ... [...]
Don't be so ... I don't find the equivalent english word. Smth like: Take it
more easy.

Please don't insult the martellibot. He did, after all, write "Python in
a Nutshell" and co-edited the "Python Cookbook", and he has established
a reputation with his consistent long-term contribution to Python and
this newsgroup. Instead, ask yourself why your remarks engender such a
response from a pillar of the Python community. What are your credentials?

regards
Steve
--
Meet the Python developers and your c.l.py favorites March 23-25
Come to PyCon DC 2005 http://www.pycon.org/
Steve Holden http://www.holdenweb.com/

[Brian van den Broek]

Steve Holden said unto the world upon 2005-02-07 17:51:

Alexander Zatvornitskiy wrote:

ðÒÉ×ÅÔ Alex!

05 ÆÅ×ÒÁÌÑ 2005 × 17:00, Alex Martelli × Ó×ÏÅÍ ÐÉÓØÍÅ Ë All ÐÉÓÁÌ:
<SNIP>

AM> to all intents and purposes working "as if"
AM> it was a declaration. If I had to vote about the one worst formal
AM> defect of Python, it would surely be 'global'.
Second worsest - 'def'? :)
The reason global is a wart can clearly be seen in the following example:
>>> x = 3
>>> def f(tf, v): ... if tf:
... global x
... x = v
... >>> f(0, 5)
>>> x 5 >>>

This makes it apparent that the global statement is *not* executable,
the only one in the language that is not.

<SNIP>
regards
Steve

Hi,

Steve's example makes my brain hurt. :-)

I'd appreciate it if someone could tell me if I am understanding the
example correctly. (My grasp of the terminology and issues at play is
a bit shaky.)

Let me simplify Steve's example to:

..def hurts_my_brain(v):
.. if False: # unlike Steve's eg, ensuring that the
.. global x # nested block is never hit at runtime
.. x = v

(I checked, and it works the same as the original eg, modulo change of
function name.)

Is the right way to understand it in this vicinity:

At compile time (by which I mean when the Python bytecode is built)
the global statement is hit and has the effect of `bumping up' the
function local name `x' to the module namespace, making the function
local name `x' synonymous with the module global name `x'. At runtime,
the `global x' is never reached, but it has already, at compile time,
had its effect on the nature of the function object hurts_my_brain.
Further, if the function had instead said 'if True:' the global
statement would have been reached at runtime, but would have been
without effect due to this, having already been `used up' in the
creation of the bytecode.
Can it then be further (truly :-) ) said that

if False:
# thousands of lines of code here

would effect the structure of the function object's bytecode, but not
its behaviour when run? Or, at most, would cause a performance effect
due to the bytecode being bloated by thousands of line's worth of code
that would never get executed?

Thanks for any confirmation of my understanding / rectification of
same. Best,

Brian vdB

[Terry Reedy]

"Brian van den Broek" <bv****@po-box.mcgill.ca> wrote in message
news:42************@po-box.mcgill.ca...

Is the right way to understand it in this vicinity:
In the vicinity, but not quite exact
At compile time (by which I mean when the Python bytecode is built)
Compile time is when the def statement is executed
the global statement is hit and has the effect of `bumping up' the
function local name `x' to the module namespace, making the function local
name `x' synonymous with the module global name `x'.
Global make 'x' global. Period. There is no local 'x'.
At runtime, the `global x' is never reached,
In CPython, at least, it is not even there to be reached (see below).
It is strictly a compile time declaration. At runtime, it is equivalent to
'pass'.
but it has already, at compile time, had its effect on the nature of the
function object

Right. With 2.2:

def f():
if False: global x
x = 1

import dis
dis.dis(f)
0 SET_LINENO 1

3 SET_LINENO 2
6 LOAD_GLOBAL 0 (False)
9 JUMP_IF_FALSE 7 (to 19)
12 POP_TOP

13 SET_LINENO 2
16 JUMP_FORWARD 1 (to 20)

19 POP_TOP 20 SET_LINENO 3

23 LOAD_CONST 1 (1)
26 STORE_GLOBAL 1 (x)
29 LOAD_CONST 0 (None)
32 RETURN_VALUE

Two points: there is no byte code for the global declaration; x is directly
stored as global.

Terry J. Reedy

[Alex Martelli]

Terry Reedy <tj*****@udel.edu> wrote:

"Brian van den Broek" <bv****@po-box.mcgill.ca> wrote in message
news:42************@po-box.mcgill.ca...

Is the right way to understand it in this vicinity:

In the vicinity, but not quite exact

At compile time (by which I mean when the Python bytecode is built)

Compile time is when the def statement is executed

I disagree: compile time is when the compiler is running (for example,
the compiler is the component which diagnoses syntax errors, while other
errors are diagnosed ``at runtime'').

Bytecode is built before def executes -- indeed it's built whether def
executes or not. Cfr:

def f(wo): .... if wo:
.... def g(): pass
.... f.func_code.co_consts (None, <code object g at 0x382a60, file "<stdin>", line 3>)

the 'def g' hasn't executed (yet?), but the bytecode is built (and
stored as the first constantvalue in f, save the ubiquitous None).

If the ``if wo: def ...'' construct was in a module being imported, the
mechanics would be similar -- although in this case I think you could
tell only if a syntax error was present in the def statement (I may be
wrong, but offhand I don't think the codeobject is saved in this case).

Or, try this one:
c = compile('def x(): pass', '<string>', 'exec')
c <code object ? at 0x389420, file "<string>", line 1> c.co_consts (<code object x at 0x3893e0, file "<string>", line 1>, None)

``compile time'' here is when the 'compile' built-in runs; and we can
see the code object ``x'' is already built even though the def has not
been executed yet.
Alex

[Fredrik Lundh]

Terry Reedy wrote:

At compile time (by which I mean when the Python bytecode is built)

Compile time is when the def statement is executed

no, that's run time. "def" is an executable statement, just like "print", "for",
assignments, "import", etc.

the entire module is compiled (to bytecode) before any part of it is executed.
the compiler handles "global" and "from __future__", everything else is done
at runtime.

</F>

[Peter Otten]

Fredrik Lundh wrote:

executed. the compiler handles "global" and "from __future__", everything
else is done at runtime.

and __debug__, too, it seems:

__debug__ False def f(): .... if __debug__:
.... global x
.... x = 42
.... f()
x

Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'x' is not defined

Peter

[Duncan Booth]

Brian van den Broek wrote:

Can it then be further (truly :-) ) said that

if False:
# thousands of lines of code here

would effect the structure of the function object's bytecode, but not
its behaviour when run? Or, at most, would cause a performance effect
due to the bytecode being bloated by thousands of line's worth of code
that would never get executed?

Yes, but that purely an implementation detail.

if 0:
# thousands of lines of code here

has no effect at all on the bytecode, it it optimised out entirely. 'if
False:' is not optimised out in Python 2.4 or earlier, but might be in
later versions.

Now, to really get your brain hurting, see what this one does:

def hurts_my_brain(v):
if 0: # unlike Steve's eg, ensuring that the
global x # nested block is never hit at runtime
x = v

I'll give you a clue, it's not the same as your:

def hurts_my_brain(v):
if False: # unlike Steve's eg, ensuring that the
global x # nested block is never hit at runtime
x = v

So the global statement is a wart which isn't executed at runtime, but
behaves differently when the bytecode it doesn't generate is optimised out.

[Fredrik Lundh]

Peter Otten wrote:

executed. the compiler handles "global" and "from __future__", everything
else is done at runtime.

and __debug__, too, it seems:

you left out the "python -O" line.

__debug__ False def f(): ... if __debug__:
... global x
... x = 42
... f()
x

Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'x' is not defined

yup, but unlike the two others, that's a CPython -O implementation issue.
(I'd say bug, in this case).

neither standard CPython (without -O) nor Jython behave this way.

</F>

[Alexander Zatvornitskiy]

Hi, Peter!

05 feb 2005 at 15:28, Peter Otten wrote:

variable names. You have to move the code into a function, though: $
cat epsilon.py ...skipped... $ pychecker epsilon.py epsilon.py:6:
Local variable (epselon) not used Well, I can change it a little to
pass this check. Just add "print epselon" line.

PO> You are now on a slippery slope. I'd rather think of ways to write my
PO> code in a way for it to succeed or at least fail in an obvious way.
Ok, fixed.
PO> I don't consider a scenario likely where you both misspell a name
PO> nearly as often as you write it correctly, and do that in a situation
PO> where the program enters an infinite loop instead of just complaining
PO> with an exception, which is by far the most likely reaction to a
PO> misspelt name.
Let say, you have variable or class field 'PowerOfGenerator', or 'lambda_k'.
You decide to rename it to 'ReactivePowerOfGenerator' or 'lambda_kx'. But, for
some reasons, you forget to do it everywhere, for example in function with
first lines like this:

PowerOfGenerator=TakeFromSensor()
if PowerOfGenerator>xxx:
....
RecalcPower(PowerOfGenerator)
PutToTheDatabase(PowerOfGenerator)
....
Here, python will not help you. The worst thing is that in such calculations
you often receive plausible results.

Another example. Let say you have variable PowerOfGenerator in your program.
But, it is only active power, so you have to (1)rename PowerOfGenerator to
ActivePowerOfGenerator, (2)calculate ReactivePowerOfGenerator, and (3)calculate
new PowerOfGenerator by formula
PowerOfGenerator=sqrt(ReactivePowerOfGenerator**2+ ActivePowerOfGenerator**2)
With var declarations, on step (1) you just rename PowerOfGenerator to
ActivePowerOfGenerator in the place of its declaration, and compile your
program. Compiler will show you all places where you have to rename variables.
After it, on step (3) you can safely and peacefully add new PowerOfGenerator
variable.

Of course, I am trying to use more short variable names, but its just an
example.

PO> Code not written is always errorfree, and in that spirit I'd rather
PO> strive to write the function more concisely as

PO> def loop2():
PO> s = 0
PO> for delta in range(10):
PO> s += delta
PO> print s

PO> This illustrates another problem with your approach: would you have
PO> to declare globals/builtins like range(), too?
if I understand you right, it can be done this way (with '~' instead of 'var'):
~s=0
for ~delta in range(10)
s+=delta

[skip]

PO> I suggested pychecker more as a psychological bridge while you gain
PO> trust in the Python way of ensuring reliable programs, i. e. writing
PO> small and readable functions/classes that do one thing well and can
PO> easily be tested. Administrative overhead -- as well as excessive
PO> comments -- only serve to bury what is actually going on.

Your explanation is most "non-religious" in comparison with all others I see in
this newsgroup. Thank you, now I see that lack of var declarations is not
stupid oversight, but it may have reasons.
From the other side, I still think that optional var declaration is good idea,
for example in functions which are big and operate with tens of variables,
non-decomposable by their nature. Such functions occurs in some domains. And,
in situations like above.

PO> I guess that means no, not a good idea.

PO> On the other hand, taking all names used in a function and looking
PO> for similar ones, e. g. by calculating the Levenshtein distance,
PO> might be worthwhile...

Hmm, what is the Levenshtein distance between 'x1' and 'x2'? Or between kappa_i
and kappa_j? :)

Alexander, za**@bk.ru

[Brian van den Broek]

Brian van den Broek said unto the world upon 2005-02-07 20:36:

Steve Holden said unto the world upon 2005-02-07 17:51:
<SNIP>

The reason global is a wart can clearly be seen in the following example:

>>> x = 3
>>> def f(tf, v):

... if tf:
... global x
... x = v
...

>>> f(0, 5)
>>> x

5

>>>
<SNIP>
Hi,

Steve's example makes my brain hurt. :-)

I'd appreciate it if someone could tell me if I am understanding the
example correctly. (My grasp of the terminology and issues at play is a
bit shaky.)
<SNIP>
Thanks for any confirmation of my understanding / rectification of same.
Best,

Brian vdB

Thanks to everyone whose contributed to this sub-thread! I've learned
a lot. :-)

And, for posterity, some one wrote me off-list to correct my claim
that in

if False:
# thousands of lines of code here

the thousands of lines "would never get executed". Simplifying their
example, they pointed out:
False = 'evil trickery'
if False: .... print 'Surprise!'
....
Surprise!

Which leads me naturally to the differences between 'if False:' and
'if ):' that Duncan Booth pointed to. (Where'd I put the Tylenol.)

Thanks again to all,

Brian vdB

[top]

Alex Martelli wrote:
[snip]

I disagree: compile time is when the compiler is running (for example, the compiler is the component which diagnoses syntax errors, while other errors are diagnosed ``at runtime'').

[snip]

That thing about syntax errors is news to me. I thought they were
caught at runtime, since you can catch them as exceptions, as in:

try: prijnt projnt
except SyntaxError: print "See, it gets caught"

If this happens at compile-time, I'd like to know how.
Thanks,
--
- Alexandre

[Fredrik Lundh]

"top" <al**********@gmail.com> wrote:

That thing about syntax errors is news to me. I thought they were
caught at runtime, since you can catch them as exceptions, as in:

try: prijnt projnt
except SyntaxError: print "See, it gets caught"

If this happens at compile-time, I'd like to know how.

$ python sample.py
File "sample.py", line 1
try: prijnt projnt
^
SyntaxError: invalid syntax

</F>

[Alex Martelli]

top <al**********@gmail.com> wrote:

Alex Martelli wrote:
[snip]

I disagree: compile time is when the compiler is running (for example,

the compiler is the component which diagnoses syntax errors, while

other

errors are diagnosed ``at runtime'').

[snip]

That thing about syntax errors is news to me. I thought they were
caught at runtime, since you can catch them as exceptions, as in:

try: prijnt projnt
except SyntaxError: print "See, it gets caught"

Nope:

kallisti:~/cb alex$ cat a.py
try: prijnt projnt
except SyntaxError: print "See, it gets caught"

kallisti:~/cb alex$ python a.py
File "a.py", line 1
try: prijnt projnt
^
SyntaxError: invalid syntax
kallisti:~/cb alex$
If this happens at compile-time, I'd like to know how.

You can catch SyntaxError when it happens (e.g) on an explicit call to
the built-in function ``compile'', or, say:

try: import a

.... except SyntaxError: print "caught!"
....
caught!

Here, the compilation of a.py (which has the error, see the cat above)
happens AFTER the try/except itself has been compiled, and while the try
clause is executing (compiling happens as part of import of a .py unless
the .pyc file is already there & updated); so the exception handler can
of course catch the exception.
Alex

[Thomas Bartkus]

"Alexander Zatvornitskiy"
<Al*********************@p131.f3.n5025.z2.fidonet. org> wrote in message
news:MS*****************************@fidonet.org.. .
<snip>

The worst thing is that in such calculations you often receive plausible

results.
<snip>

Exactly so!

An ordinary spelling error gets promoted to a logic error that is damn
difficult to detect, let alone trace! Before one even tries, it behooves
one to spell check his variables. An additional step that counters Python's
procedural simplicity.

"i" comes before "e" except after "c" OR whenever I make a typo!
Thomas Bartkus

[Jeff Shannon]

Alexander Zatvornitskiy wrote:

Another example. Let say you have variable PowerOfGenerator in your program.
But, it is only active power, so you have to (1)rename PowerOfGenerator to
ActivePowerOfGenerator, (2)calculate ReactivePowerOfGenerator, and (3)calculate
new PowerOfGenerator by formula
PowerOfGenerator=sqrt(ReactivePowerOfGenerator**2+ ActivePowerOfGenerator**2)
With var declarations, on step (1) you just rename PowerOfGenerator to
ActivePowerOfGenerator in the place of its declaration, and compile your
program. Compiler will show you all places where you have to rename variables.
After it, on step (3) you can safely and peacefully add new PowerOfGenerator
variable.

You can also get all places where said variable exists by using grep,
or your editor's search feature. I don't see how a var declaration
gains you anything over 'grep PowerOfGenerator *.py' ...

Jeff Shannon
Technician/Programmer
Credit International

[Caleb Hattingh]

Alexander

PowerOfGenerator=TakeFromSensor()
if PowerOfGenerator>xxx:
....
RecalcPower(PowerOfGenerator)
PutToTheDatabase(PowerOfGenerator)
....
Here, python will not help you. The worst thing is that in such
calculations
you often receive plausible results.

(I think PyChecker has come up before, but...) If you like, you could make
a text-file index of all the variable names allowed in your program, and
parse all the python code to ensure that only those variable names are
used. I believe this would
a) solve your problem
b) require less than a morning's work
c) not force everyone else to have to deal with variable declarations that
will be only an annoyance 95% percent of the time.

Is there a specific reason you want this added to the *language* itself?

Thanks
Caleb

[Caleb Hattingh]

Jeff

I fully agree. As I stated in a message to alexander, it is quick and
easy even to write a simple project-specific tool for checking that only
allowed variable names exist in all the project files.

Compared to having to work with tons of effectively useless variable
declarations forever (perhaps even only in other peoples code who decided
to use the "option"), it is not much to ask (I work in pascal a lot - I
know all about tons and tons of declarations).

thx
Caleb

You can also get all places where said variable exists by using grep, or
your editor's search feature. I don't see how a var declaration gains
you anything over 'grep PowerOfGenerator *.py' ...

Jeff Shannon
Technician/Programmer
Credit International

[Arthur]

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

Alexander Zatvornitskiy
<Al*********************@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

[Elspeth Thorne]

Alexander Zatvornitskiy wrote:

You may say: give better names for your variables! Ha, I'am often don't
understand that they mean! They are written for me by an engineer!

Hang on, though - if you don't understand what you are programming, then
how can you check if it's correct? Regardless of variable names,
declarations, or anything else. And besides which - is/was there
anything preventing you from using different variable names within the
code (which are understandable to you), then displaying different names
to the user (eg an engineer) when an error occurs?

You'd hit the same issues (precisely the same issues) with any language,
if you flat-out do not know what you are doing - or trying to do.
Admittedly, I have somewhat limited experience, so my word is not
gospel, or even necessarily well-informed.

But it seems to me that declaring your variables would not fix the
underlying problem here - the programmer's lack of understanding of the
task.
Elspeth.

[Eric Pederson]

Arthur artfully argued:

What if:

There was a well conducted market survey conclusive to the effect that
adding optional strict variable declaration would, in the longer run,
increase Python's market share dramatically.

It's always good to examine one's objectives and motives. I am an enthusiast for marketing Python, but why? Would I get something out of Python being the language du jour? If everyone starts using Python when I am an old hand with the language, will it elevate me? Is a world where people use a programming language called "Python" necessarily a better world?

For me the answer to those questions is no.

So what would I like?

Just the option to use Python when and where it suits me and my tasks - and the continued excellent quality development and maintenance of Python andPython libraries.

It just would.

Right!

All the cool kids (and if you want to be popular you need to):

smoke/smoke dope/get tatoo'd/fight/climb the water tower/get pierced/get drunk/call their girlsfriends a b!#ch/shop lift/ditch school/put their fingers into an electrical outlet
Declare variables?

Hey, what's one more compromise to get popular?!
(I shudder thinking where that slippery slope leads)


[Nothing above is meant to imply I haven't done stupid things; rather perhaps that I've already done more than enough to know better; and, by the way,I'm still not "popular". I'd hope GvR and the crew "keep Python Python"]


Eric Pederson
http://www.songzilla.blogspot.com

[Alexander Zatvornitskiy]

Hi, Elspeth!

09 feb 2005 at 14:44, Elspeth Thorne wrote:

You may say: give better names for your variables! Ha, I'am often
don't understand that they mean! They are written for me by an
engineer!

ET> Hang on, though - if you don't understand what you are programming,
ET> then how can you check if it's correct?
....skipped...
ET> You'd hit the same issues (precisely the same issues) with any
ET> language, if you flat-out do not know what you are doing - or trying
ET> to do.

ET> Admittedly, I have somewhat limited experience, so my word is not
ET> gospel, or even necessarily well-informed.

I will inform you:) Let say you are working with the team of engineers. They
develop a project of new building, and they need some calculations of solidness
of metall constructions, specific for such kind of building. Such calculations
are rather complex, so they can't wrote program (or smth else) themselves. But
they can wrote and explain algorithm with calculations.
If you want understand their formulas, you must learn theoretical mechanicks,
resistance of materials, builder's standarts and rules (I'm not sure I
translate titles of the disciplines correctly). It will take a year, minimum.
But you have no such time - deadline is much closer:)

As for me, I _HATE_ such kind of job:) But sometimes it happens. And, after
some years, when you see the final result of such job, you fill some special
feelings. It differ from result of purely programmer's work. The result is big,
real, it may work for people during tens (or may be hundred) years.

Main problem in programming - programmer "look to the wrong place" or "overlook
coefficient", ... . Main weapon to fight with them - tests. We do it this way.
After engineer wrote an "algorithm", he take a calculator and began to work
according to it (it also help him to find "bugs"). Final result, and all
intermediate results are written. Every separate part of calculations (separate
function in program) tested separately and in whole.

But tests are not a silver bullet. static checking is also very usefull. What's
why I feel variable declaration (or explicit variable definition) may help.

Alexander, za**@bk.ru

[Alexander Zatvornitskiy]

Hi, Steve!

07 feb 2005 at 17:51, Steve Holden wrote:

information about variable S to the memory. I don't find big
difference. By the way keyword "def" is as bad as "var", from your
point of view? :) SH> If your colloquial English is good enough to understand the word
SH> "bollocks" then you might begin to realize how irritating your
SH> arguments are becoming.
Well, I have a dictionary. Let's look. "Man with grey bollocks - wise,
experienced man".Hm, I'am realy have some experience in some areas:)

SH> If, as you suggest, def were a declaration, then it should either not
SH> be possible to write
SH> if __debug__:
SH> def func(x):
SH> print x, "is bollocks"

if __debug__:
~S=0

S=5 #error in non-debug mode.
print S

That's not the same I suppose from the beginning, but it also can be helpfull.
More exactly, it is not 'variable declaration' but 'variable definition'.
But, I am friendly, even with my opponents. I think it is my good
trait. SH> You are, of course, entitled to your opinion, self-serving though it
SH> may be. A friendly idiot is still an idiot.

No comments.
Don't be so ... I don't find the equivalent english word. Smth like:
Take it more easy.

SH> Please don't insult the martellibot.

It was not an insult. It is not in my rules, as I said before. It's just an
advice. "global" is in Python, but he is still alive - hence it's not as big
problem as he say.

SH> He did, after all, write "Python
SH> in a Nutshell" and co-edited the "Python Cookbook", and he has
SH> established a reputation with his consistent long-term contribution to
SH> Python and this newsgroup. Instead, ask yourself why your remarks
SH> engender such a response from a pillar of the Python community. What
SH> are your credentials?
Well, for python community - 0. Now, you can only read my messages and think
about them. After all, idiot who made contribution is still idiot, isn't it?
(it's not about A.M., of course)

Alexander, za**@bk.ru

[Antoon Pardon]

Op 2005-02-08, Fredrik Lundh schreef <fr*****@pythonware.com>:

Peter Otten wrote:

executed. the compiler handles "global" and "from __future__", everything
else is done at runtime.

and __debug__, too, it seems:

you left out the "python -O" line.

> __debug__

False

> def f():

... if __debug__:
... global x
... x = 42
...

> f()
> x

Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'x' is not defined

yup, but unlike the two others, that's a CPython -O implementation issue.
(I'd say bug, in this case).

neither standard CPython (without -O) nor Jython behave this way.

If people here are so against declarations, how do they feel about
statements that don't seem like declarations but have a declarative
effect anyway?

Because that is what assignment statements in python essentially are.
If assignments wouldn't have a declarative effect then code like
the following should work:

x = 42

def f():
if False:
x = 20
return x

f()
If the x = 20 would be a pure executing statement, then how come
its presence has an effect on the return statement even when it
isn't executed. And we can play the same trick here. calling python -O
and feeding it this program but with the False replaced by __debug__
will make this "work".

So having come to the conclusion that some statements have a declarative
effect, I would prefer to have the declaration and the assignment be
seperated in two different statements. That would make the declaration
explicit instead of being implicit now and explicit is better than
implicit.

Of course the other solution, simply removing the declarative effect from
assignments, could work too and might even be preferable but I fear
it would produce strange behaviour.

--
Antoon Pardon

[Serge Orlov]

Alexander Zatvornitskiy wrote:

Hello All!

I'am novice in python, and I find one very bad thing (from my point
of view) in language. There is no keyword or syntax to declare
variable, like 'var' in > Pascal, or special syntax in C. It can
cause very ugly errors,like this:

epsilon=0
S=0
while epsilon<10:
S=S+epsilon
epselon=epsilon+1
print S

It will print zero, and it is not easy to find such a bug!

I'm late to the party, but I found an interesting text by the Guinness
book
record-holder in typing. He claims that the python way of dealing with
typos is right. He doesn't write about python directly but the main
idea is to punish heavily for every typo. He also has "nice" words for
software industry and the backspace key. Read it here:
http://www.supremelearning.com/bookexcerpts.html

By the way if my reading of poor quality scan of his record certificate
http://www.supremelearning.com/image_certificate.html is correct, his
typing speed was 614 characters/minute. Impressive! There is also his
book in Russian language:
http://www.supremelearning.com/russianslbookpart1.html

As for me, typos have never been a big problem. They happen rarely.
As the Guinness book record-holder suggests: don't make typos!

Serge.