variable declaration

[Alexander]

Hi, Alex!

05 feb 2005 at 12:52, Alex Martelli wrote:
 >> 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> You're conflating a fundamental, crucial language design choice, with
 AM> a rather accidental detail
It's not my problem:) I just wrote about two things that I don't like.
 AM> Run Python with -Qnew to get the division behavior you probably want,
 AM> or -Qwarn to just get a warning for each use of integer division so
 AM> those hard to find bugs become trivially easy to find.
Thank you. It will help me.

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

 AM> is a completely different LEVEL of issue -- a totally deliberate
 AM> design choice taken in full awareness of all of its implications.  I
 AM> do not see how you could be happy using Python if you think it went
 AM> wrong in such absolutely crucial design choices.

Ok, I understand your position.

 >>  >> 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
 >>  AM> anything,
 >> Oh, I don't find it:)
 AM> Hit control-C (or control-Break or whatever other key combination
 AM> interrupts a program on your machine) when the program is just
 AM> hanging there forever doing nothing, and Python will offer a
 AM> traceback showing exactly where the program was stuck.
 AM> In any case, you assertion that "it will print zero" is false.  You
 AM> either made it without any checking, or chose to deliberately lie (in
 AM> a rather stupid way, because it's such an easy lie to recognize as
 AM> such).
Sorry, while saying "I don't find it" I mean "I don't take it into account at
time I wrote original message. Now I find it, and it make me smile.". As you
understand, I'am not very good in English.

 >> 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
 AM> environmental issue, notoriously hard to verify precisely with unit
 AM> tests.  Therefore, asserting that "every, even simple, test will find"
 AM> bugs connected with program behavior when a file is missing shows
 AM> either that you're totally ignorant about unit tests (and yet so
 AM> arrogant to not let your ignorance stop you from making false
 AM> unqualified assertions), or shamelessly lying.

Here, you take one detail and bravely fight with it. Just try to understand
meaning of my sentence, in all. It will help:)

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

Again, skip small details and take a look on the problem "in general". Here is,
again, the main idea:
========
Or, maybe, we will ask interpreter to find and prevent as many errors as he
can?
========

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.

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

 >> 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> Yes, the many wasted pixels in those idiotic 'var ' prefixes are a
 AM> total and utter waste of programmer time.

Hmmm, that code is not so pretty. Lets change it a little bit:

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

I think it is look well.

 AM> 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! :)
 AM> Wrong again.  I've made a good living for years as a C++ guru, I
 AM> still cover the role of C++ MVP for the Brainbench company, I'm
 AM> (obviously) totally fluent in C (otherwise I could hardly contribute
 AM> to the development of Python's C-coded infrastructure, now could I?),
 AM> and as it happens I have a decent command (a bit rusty for lack of
 AM> recent use) of dozens of other languages, including several Basic
 AM> dialects and Visual Basic in particular.
 AM> It should take you about 20 seconds with Google to find this out
 AM> about me, you know?  OK, 30 seconds if you're on a slow dialup modem
 AM> line.
Ok, your are really cool guy. Also, I appreciate your contribution to Python's
C infrastructure. I'am not as cool as you, but Python is not my first language
too:)

Alexander, zatv at bk.ru
---url: alex-zatv.narod.ru