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

[Michael Tobis]

> All in all, I fail to see what gains would be expected by making
Python

into a single-assignment or single-binding language, even on a module by module basis, to repay this kind of awkwardness.

Just to be clear, if anyone was suggesting that, it wasn't me.

It would be helpful on occasion in a numarray development context to
have *specific* refererences be bound only once, and I wouldn't be
surprised if the compiler couldn't use that information to good
advantage too.

However, this subthread is about whether rebinding is completely
avoidable. Others including you have come up with better reasons than I
did that it's not.

If rebinding is normal, I think the 'epselon' bug can't be dismissed as
completely avoidable. This is something that I gather you disagree with
on the presumption that everyone who writes Python is sufficently
talented that they can use their skills to avoid getting too far into
this trap.

Since I'm very much a believer in Python as a beginner's language, that
doesn't satisfy me. "Declaratio ns are impractical" would satisfy me,
but so far I'm not completely convinced of that.

mt

[Thomas Bartkus]

"Michael Tobis" <[e-mail] > wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .
<snip>

Since I'm very much a believer in Python as a beginner's language, that
doesn't satisfy me. "Declaratio ns are impractical" would satisfy me,
but so far I'm not completely convinced of that.

As has been pointed out, it's not a big deal for a programmer who's been
there, done that. But the original posters example is a beginners trap for
certain.

*If* Python were a "beginners language", then it would be missing one of
it's training wheels.
Thomas Bartkus

[Steve Holden]

Thomas Bartkus wrote:

"Steve Holden" <st***@holdenwe b.com> wrote in message
news:41******** ******@holdenwe b.com...

Thomas Bartkus wrote:

"Carl Banks" <in**********@a erojockey.com> wrote in message
news:11***** *************** *@f14g2000cwb.g ooglegroups.com ...
<snip>

How common is it for a local variable to be bound in
more than one place within a function?
How common? It shouldn't happen at all and that was the point.
This seems a little excessive to me. Sample use case:

for something in lst:
if type(something) != type(()):
something = tuple(something )

Hhhmmh!
I presume you are going through the list and want to gaurantee that every
item you encounter is a tuple! So if it ain't - you just re-declare
"something" to be a tuple. What was formerly a single string, integer,
whathaveyou is now a tuple *containing* a single string, integer,
whathaveyou.

Do you do it that way because you can? Or because you must?
And
If the former - is it a good idea?
OR did I just miss your codes intent completely?

I suspect you missed the intent completely.
My first inclination would be to create a new variable (type = tuple) and
accept (or typecast) each "something" into it as required. The notion that
OK, but if you do that then surely the loop looks like

for something in lst:
somethingElse = something
if type(somethingE lse) != type(()):
somethingElse = ...
you just morph "something" still seems rather abhorrent. It hadn't occurred
to me that iterating through a list like that means the iterater "something"
might need to constantly morph into a different type according to a lists
possibly eclectic contents.
Now I suspect I'm missing *your* point.
It might explain why the interpreter is incapable of enforcing a type. It
would forbid iterating through lists containing a mix of different types.
EXCEPT- I must note, that other languages manage to pull off exactly such a
trick with a variant type. When you need to pull off a feat such as this,
you declare a variant type where the rules are relaxed *for that situation
only* and there is no need to toss the baby out with the bathwater.

Well I have to say that the longer I program (and I've been at it nearly
forty years now) the more I am convinced that type declarations don't
actually help. I can see their value in terms of code optimization, but
there is no way that I see them as an error-detection mechanism. "You
have tried to assign a string to an integer variable" just isn't a
mistake I make a lot.

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

[Eric Pederson]

"Thomas Bartkus" wrote

As has been pointed out, it's not a big deal for a programmer who's
been
there, done that. But the original posters example is a beginners trap
for
certain.

*If* Python were a "beginners language", then it would be missing one
of
it's training wheels.

If you put training wheels on your bicycle, it's not going to be any good for moderately serious cycling. The OP was clearly not new to programming, and it was a hypothetical problem.

We're all adults here (even my 12 year old!) - and we have only beginners in my house. This purported wart has never bothered me -- Python is so friendly to develop in. If this sort of code error bites my 12 year old, I'm sure he will be able to find it and feel good about fixing it. It's not the kind of code error that has you shutting down your computer at 4AM, perplexed and frustrated - those feelings are usually attributable to subtle, complex, dastardly language features (unexpected behavoirs). Just my opinion, of course.

Among the great and enlightening posts in this thread, I liked this:

QOTW?
"""We should concentrate on *real* problems, ones that exist in real code, not ones that mostly
exist in wild-eyed prose that consists of predictions of pain and death
that conspicuously fail to occur, no matter how many times they are
repeated or we are exhorted to heed them or face our doom. """

http://groups-beta.google.com/group/...8fef06830cc779
[Go PyPy!]

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

::::::::::::::: ::::::::::::::: :::::
domainNot="@som ething.com"
domainIs=domain Not.replace("s" ,"z")
ePrefix="".join ([chr(ord(x)+1) for x in "do"])
mailMeAt=ePrefi x+domainIs
::::::::::::::: ::::::::::::::: :::::

[Jorgen Grahn]

On Mon, 31 Jan 2005 18:49:15 +0100, Alex Martelli <al*****@yahoo. com> wrote:

Michael Tobis <[e-mail] > wrote:

With all due respect, I think "so go away if you don't like it" is
excessive, and "so go away if you don't like it and you obviously don't
like it so definitely go away" is more so. The writer is obviously

I disagree: I believe that, if the poster really meant what he wrote, he
may well be happier using other languages and all the declarations he
cherishes, so recommending that course of action to him is quite proper
on my part.

You are wrong, for once.

That poster could have been me a few years back, when I was younger, more
stupid, more arrogant and less experienced. He'll get over it.

Also, what he described /is/ a problem. I still get bitten by it now and
then. It's just that it has even larger /benefits/ which aren't obvious at
first.

In BASIC, /bin/sh and perl without 'use strict', the lack of declarations is
only a negative thing without benefits. If you know those languages, it's
easy to jump to the conclusion that this applies to Python, too.

/Jorgen

--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!

[Alexander Zatvornitskiy]

ðÒÉ×ÅÔ Peter!

31 ÑÎ×ÁÒÑ 2005 × 09:09, Peter Otten × Ó×ÏÅÍ ÐÉÓØÍÅ Ë All ÐÉÓÁÌ:
PO> pychecker may help you find misspelled variable names. You have to
PO> move the code into a function, though:

PO> $ cat epsilon.py
....skipped...
PO> $ pychecker epsilon.py
PO> epsilon.py:6: Local variable (epselon) not used

Well, I can change it a little to pass this check. Just add "print epselon"
line.

I think if as soon as I will make such error, I will write special checker. It
will take code like this:

def loop():
#var S,epsilon
epsilon=0
S=0
while epsilon<10:
S=S+epsilon
epselon=epsilon +1
print S

Such checker will say "error:epse lon is not declared!" if I will use something
not declared. If everything is ok, it will call pychecker. Simple and tasty,
isn't it?
Of cource, it may be difficult to handle fields of classes:
MyClass.epsElon =MyClass.epsilo n+1
but it is solvable, I think. What do you think, is it a good idea?
Alexander, za**@bk.ru

[Alexander Zatvornitskiy]

Hi, Alex!

31 jan 2005 at 13:46, Alex Martelli wrote:

(sorry for the delay,my mail client don't highlight me your answer)

AM> Since the lack of declarations is such a crucial design choice for
AM> Python, then, given that you're convinced it's a very bad thing, I
AM> suggest you give up Python in favor of other languages that give you
AM> what you crave.
Well, I like Python. But, as every language I know, it have some bad sides
which I don't like. One of them in Python is lack of variable declarations,
another (this problem is common with C/C++) is:
===

print 1/2

0
===
(I understand why it is so, but I don't like it anyway. Such behaviour also can
cause some hard-to-find-bugs)

AM> issue for you. Therefore, using Python, for you, would mean you'd be
AM> fighting the language and detesting its most fundamental design
AM> choice: and why should you do that? There are zillions of languages
AM> -- use another one.
Thank you for advice:) 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!

AM> Actually, this while loop never terminates and never prints anything,
Oh, I don't find it:)
AM> so that's gonna be pretty hard to ignore;-).
AM> But, assume the code is
AM> slightly changed so that the loop does terminate. In that case...:

AM> It's absolutely trivial to find this bug, if you write even the
AM> tiniest and most trivial kinds of unit tests. If you don't even have
AM> enough unit tests to make it trivial to find this bug, I shudder to
AM> think at the quality of the programs you code.

Thank you for advice again, I already use different tests in my work and I
found them usefull. But! I want to use Python for prototyping. I want to write
my algorithms on it, just to see they do almost they must to do. Next, I want
to play with them to understand their properties and limitations.
If sometimes such a program fall, or not very fast, or sometimes show wrong
results, it's not a big problem. So, I use Python like tool for prototyping.

After I debug the algorithm and understand it, I can rewrite it on C++ (if I
need), carefully, paying attention to speed, side effects, memory requirements,
and so on. With full testing, of course.

Hence, from "language for prototyping" I need next features:

1. I want to think about algorithm (!!!), and language must help me to do it.
It must take care on boring things like memory management, garbage collection,
strict type inference, my typos. It must provide easy-to-use packages for many
of my low-level needs. And so on.

2. goto 1:)

Python is realy very good for such demands. Except one: it force me to type
variable names carefully:) In other words, divert my attraction from algorithm,
to typing.

AM> Even just focusing on
AM> typos,
AM> think of how many other typos you could have, besides the misspelling
AM> of 'epsilon', that unit tests would catch trivially AND would be
AM> caught in no other way whatsoever -- there might be a <= where you
AM> meant a <, a 1.0 where you meant 10, a - where you meant a +, etc,
AM> etc.
AM> You can't live without unit tests. And once you have unit tests, the
AM> added value of declarations is tiny, and their cost remains.

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.

:)

Or, maybe, we will ask interpreter to find and prevent as many errors as he
can?

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:)
AM> Python has no declarations whatsoever. If you prefer Visual Basic, I
AM> strongly suggest you use Visual Basic, rather than pining for Visual
AM> Basic features in Python. If and when your programming practices ever
AM> grow to include extensive unit-testing and other aspects of agile
AM> programing, THEN you will be best advised to have a second look at
AM> Python, and in such a case you will probably find Python's strengths,
AM> including the lack of declarations, quite compelling.

Uh! And you! And you!... And you must never even come close to any languages
with variable declaration! Even to Visual Basic! :)

AM> brain". I find it's true: Python gets out of my way and let me solve
AM> problems much faster, because it fits my brain, rather than changing
AM> the way I think.

I'm agree with you.

AM> If Python doesn't fit YOUR brain, for example because your brain is
AM> ossified around a craving for the declaration of variables, then,
AM> unless you're specifically studying a new language just for personal
AM> growth purposes, I think you might well be better off with a language
AM> that DOES, at least until and unless your brain changes by other
AM> means.

Thank you for explanation of your opinion.

Alexander, za**@bk.ru

[Alex Martelli]

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

Hi, Alex!

31 jan 2005 at 13:46, Alex Martelli wrote:

(sorry for the delay,my mail client don't highlight me your answer)

AM> Since the lack of declarations is such a crucial design choice for
AM> Python, then, given that you're convinced it's a very bad thing, I
AM> suggest you give up Python in favor of other languages that give you
AM> what you crave.
Well, I like Python. But, as every language I know, it have some bad sides
which I don't like. One of them in Python is lack of variable declarations,
another (this problem is common with C/C++) is:
===

print 1/2 0
===
(I understand why it is so, but I don't like it anyway. Such behaviour
also can cause some hard-to-find-bugs)
You're conflating a fundamental, crucial language design choice, with a
rather accidental detail that's already acknowledged to be suboptimal
and is already being fixed (taking years to get fixed, of course,
because Python is always very careful to keep backwards compatibility).

Run Python with -Qnew to get the division behavior you probably want, or
-Qwarn to just get a warning for each use of integer division so those
hard to find bugs become trivially easy to find. Or import from the
future, etc, etc.

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. I do not see
how you could be happy using Python if you think it went wrong in such
absolutely crucial design choices.

AM> issue for you. Therefore, using Python, for you, would mean you'd be
AM> fighting the language and detesting its most fundamental design
AM> choice: and why should you do that? There are zillions of languages
AM> -- use another one.
Thank you for advice:)
You're welcome.

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

AM> Actually, this while loop never terminates and never prints anything,
Oh, I don't find it:)

Hit control-C (or control-Break or whatever other key combination
interrupts a program on your machine) when the program is just hanging
there forever doing nothing, and Python will offer a traceback showing
exactly where the program was stuck.

In any case, you assertion that "it will print zero" is false. You
either made it without any checking, or chose to deliberately lie (in a
rather stupid way, because it's such an easy lie to recognize as such).

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.
Another false assertion, and a particularly ill-considered one in ALL
respects. Presence and absence of files, for example, is an
environmental issue, notoriously hard to verify precisely with unit
tests. Therefore, asserting that "every, even simple, test will find"
bugs connected with program behavior when a file is missing shows either
that you're totally ignorant about unit tests (and yet so arrogant to
not let your ignorance stop you from making false unqualified
assertions), or shamelessly lying.

Moreover, there IS no substantial cost connected with having the library
raise an exception as the way to point out that a file is missing, for
example. It's a vastly superior approach to the old idea of "returning
error codes" and forcing the programmer to check for those at every
step. If the alternative you propose is not to offer ANY indication of
whether a file is missing or present, then the cost of THAT alternative
would most obviously be grievous -- essentially making it impossible to
write correct programs, or forcing huge redundancy if the check for file
presence must always be performed before attempting I/O.

In brief: you're not just wrong, you're so totally, incredibly, utterly
and irredeemably wrong that it's not even funny.

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:)
Yes, the many wasted pixels in those idiotic 'var ' prefixes are a total
and utter waste of programmer time. Mandated redundancy, the very
opposite of the spirit of Python.
Uh! And you! And you!... And you must never even come close to any languages
with variable declaration! Even to Visual Basic! :)

Wrong again. I've made a good living for years as a C++ guru, I still
cover the role of C++ MVP for the Brainbench company, I'm (obviously)
totally fluent in C (otherwise I could hardly contribute to the
development of Python's C-coded infrastructure, now could I?), and as it
happens I have a decent command (a bit rusty for lack of recent use) of
dozens of other languages, including several Basic dialects and Visual
Basic in particular.

It should take you about 20 seconds with Google to find this out about
me, you know? OK, 30 seconds if you're on a slow dialup modem line.

So, I guess you just *LIKE* being utterly and monumentally wrong, since
it would be so easy to avoid at least some of the bloopers you instead
prefer to keep making.

I *CHOOSE* Python, exactly because I have vast programming experience in
such a huge variety of languages, across all kinds of application areas,
methodologies, and sizes and levels of programming teams. It's not
``perfect'', of course, being a human artifact, but it does implement
its main design ideas consistently and brilliantly, and gets the
inevitable compromises just about right.
Alex

[Roy Smith]

In article <MS************ *************** **@fidonet.org> ,
Al************* ********@p131.f 3.....fido net.org (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.

[Peter Otten]

Alexander Zatvornitskiy wrote:

Привет Peter!

31 �нвар� 2005 в 09:09, Peter Otten в �воем пи�ьме к All пи�ал:
PO> pychecker may help you find misspelled variable names. You have to
PO> move the code into a function, though:

PO> $ cat epsilon.py
...skipped...
PO> $ pychecker epsilon.py
PO> epsilon.py:6: Local variable (epselon) not used

Well, I can change it a little to pass this check. Just add "print
epselon" line.
You are now on a slippery slope. I'd rather think of ways to write my code
in a way for it to succeed or at least fail in an obvious way. I don't
consider a scenario likely where you both misspell a name nearly as often
as you write it correctly, and do that in a situation where the program
enters an infinite loop instead of just complaining with an exception,
which is by far the most likely reaction to a misspelt name.
I think if as soon as I will make such error, I will write special
checker. It will take code like this:

def loop():
#var S,epsilon
epsilon=0
S=0
while epsilon<10:
S=S+epsilon
epselon=epsilon +1
print S
Code not written is always errorfree, and in that spirit I'd rather strive
to write the function more concisely as

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

This illustrates another problem with your approach: would you have to
declare globals/builtins like range(), too?
Such checker will say "error:epse lon is not declared!" if I will use
something not declared. If everything is ok, it will call pychecker.
Simple and tasty, isn't it?
That your program compiles in a somewhat stricter environment doesn't mean
that it works correctly.
Of cource, it may be difficult to handle fields of classes:
MyClass.epsElon =MyClass.epsilo n+1
MyClass.epsilon += 1

reduces the risk of a spelling error by 50 percent. I doubt that variable
declarations reduce the likelihood of erroneous infinite loops by even 5
percent.
but it is solvable, I think. What do you think, is it a good idea?

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

I guess that means no, not a good idea.

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

Peter