Привет 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, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
