variable declaration

  • Thread starter Alexander Zatvornitskiy
  • Start date
R

Roy Smith

(e-mail address removed)3.n5025.z2.fidonet.org (Alexander
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.
 
A

Alexander Zatvornitskiy

Hi, Alex!

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.
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.
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).
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. 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, (e-mail address removed)
---url: alex-zatv.narod.ru
 
P

Peter Otten

Alexander said:
Привет 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:epselon 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.epsilon+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
 
A

Alex Martelli

Alexander Zatvornitskiy
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'.

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.

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
 
N

Nick Coghlan

Alexander said:
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.

This is a problem better solved through a decent editor with code completion
than through redundant variable declarations, which waste *far* more programmer
time than typos do.

The *only* time the typo is a potential problem is if a variable name gets
rebound to something different. This is because, in Python, the name binding
operation ('=') *is* the declaration of the variable.

Rebinding a name often begs the question, "why are you using the same name for
two different things in the one function?" It's not like using a different name
for the second thing will cost much in terms of program size (unless you have
some freakishly long functions) and it surely does little for readability.
(Granted, iteration can be an exception, but even then the name generally only
gets bound twice at most - once before the loop, and once in the loop body)

Consider all of the following cases which are detected while still preserving
the convenience of 'name binding is declaration':
Py> def f():
.... x = y
....
Py> f()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in f
NameError: global name 'y' is not defined
Py> def f():
.... x += 1
....
Py> f()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment
Py> def f():
.... oops = 1
.... print ooops
....
Py> f()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 3, in f
NameError: global name 'ooops' is not defined
Py> def f():
.... class C: pass
.... c = C()
.... print c.x
....
Py> f()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 4, in f
AttributeError: C instance has no attribute 'x'

Now, if someone were to suggest a *rebinding* operator, that worked just like
regular name binding, but expected the name to be already bound, that would be
an entirely different kettle of fish - you keep all the benefits of the current
system, but gain the typo-checking that the rest of the augmented assignment
operators benefit from.

Hell, '@' just acquired rebinding semantics through its use in function
decorator syntax, so how does it look?:

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

Meh. At symbols are still ugly. A full stop might work better, since the
semantics aren't very different from a reader's point of view:

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

Anyway, the exact syntax isn't as important as the concept :)

Cheers,
Nick.
 
N

Nick Coghlan

Alex said:
'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'.

Fortunately, it's reasonably easy to avoid the ugliness, by avoiding
rebinding (within functions) global variables, which tend to be easy.

Hear, hear! And if I could write "gbls = namespace(globals())" in order to deal
with those rare cases where I *do* need to rebind globals, all uses of the
keyword could be handled nicely, while entirely eliminating the need for the
keyword itself.
*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)...

Would you be as violently opposed to a 'rebinding' augmented assignment operator?

Since bare assignment statements essentially serve the purpose of variable
declarations, I sometimes *would* like a way to say 'bind this existing name to
something different'. A rebinding operation would provide a way to make that
intention explicit, without cluttering the language with useless declarations.

In addition to detecting typos in local variable names, it would *also* address
the problem of detecting typos in the right-most name in a compound name (e.g.
making a habit of always using the rebinding operator when modifying member
variables outside of __init__ would make it easier to avoid inadvertently
creating a new instance variable instead of modifying an existing one)

With a rebinding operator available, the only typos left to slip through the net
are those which match an existing visible name and those where the programmer
has explicitly requested an unconditional name binding by using '=' and then
made a typo on the left hand side.

Cheers,
Nick.
Did I mention the possible incidental benefit of reducing the whinging about the
lack of variable declarations?
 
N

Nick Coghlan

Alexander said:
var epsilon=0
var S
S=0
while epsilon<10:
S=S+epsilon
epselon=epsilon+1#interpreter should show error here,if it's in "strict mode"
print S

It is easy, and clean-looking.

Alexander, (e-mail address removed)

An alternate proposal, where the decision to request rebinding semantics is made
at the point of assignment:

epsilon = 0
S = 0
while epsilon < 10:
S .= S + epsilon
epselon .= epsilon + 1 #interpreter should show error here
print S

Of course, this is a bad example, since '+= ' can be used already:

S = 0
epsilon = 0
while epsilon<10:
S += epsilon
epselon += 1 #interpreter DOES show error here
print S

However, here's an example where there is currently no way to make the rebinding
intent explicit:

def collapse(iterable):
it = iter(iterable)
lastitem = it.next()
yield lastitem
for item in it:
if item != lastitem:
yield item
lastitem = item

With a rebinding operator, the intent of the last line can be made explicit:

def collapse(iterable):
it = iter(iterable)
lastitem = it.next()
yield lastitem
for item in it:
if item != lastitem:
yield item
lastitem .= item

(Note that doing this *will* slow the code down, though, since it has to check
for the existence of the name before rebinding it)

Cheers,
Nick.
 
A

Arthur

I consider this one of the worst ideas to have been proposed on this
newsgroup over the years, which _IS_ saying something. \

I would disagree, but only to the extent that nothing that is only a
request for an option toggle should qualify for this award. For
anyone not interested in it's effects, it's business as usual.

They can even reward themselves with the knowledge that among the time
and typing they did not waste was in asking for the toggle to be on.

It is also true that mplementation might be a diversion of efforts
from the implementation of features solving more generally recognized
problems. There *are* a lot of bad things to say about the idea.

But I think it worth mentioning that the OP is requesting only a
toggle.

Why is it worth mentioning?

Because maybe one needs to save the heaviest rhetoric for when this is
not the case.

There was a simple answer to those who hate decorators - don't use
them. I won't.

And the most controversial suggestions about optional static typing
all perserve their sanity by remaining suggestions about something
defined as optional.

Generally speaking, it might then be said to be good community poilcy
to hold one's fire at least a bit if a feature request, or accepted
PEP, will not impact one's own code writing beyond the extent one
might choose it to.

Though I do think there *should* be a worst feature request contest
at PyCon,

What is with this white space business, anyway?

;)

Art
 
A

Alex Martelli

Nick Coghlan said:
Hear, hear! And if I could write "gbls = namespace(globals())" in order to
deal with those rare cases where I *do* need to rebind globals, all uses
of the keyword could be handled nicely, while entirely eliminating the
need for the keyword itself.

I entirely agree with you on this.

Would you be as violently opposed to a 'rebinding' augmented assignment
operator?

Not at all. The only downside I can see, and it seems a minor one to
me, is having two "obvious ways" to re-bind a name, since '=' would keep
working for the purpose. But making it explicit that one IS rebinding a
name rather than binding it anew could sometimes make certain code more
readable, I think; quite apart from possible advantages in catching
typos (which may be OK, but appear minor to me), the pure gain in
reaability might make it worth it. Call my stance a +0.
the problem of detecting typos in the right-most name in a compound name
(e.g.

It's not clear to me what semantics, exactly, x.y := z would be defined
to have (assuming := is the syntax sugar for ``rebinding''). Perhaps,
by analogy with every other augmented operator, it should be equivalent
to:

_temp = x.y
x.y = type(temp).__irebind__(temp, z)

This makes it crystal-clear what happens when type(x).y is a descriptor
with/without __set__ and __get__, when type(x) defines __getattribute__
or __setattr__, etc, etc. Giving type object an __irebind__ which just
returns the second operand would complete the semantics. Of course,
doing it this way would open the issue of types overriding __irebind__,
and it's not clear to me that this is intended, or desirable. So, maybe
some other semantics should be the definition. But since "rebinding" is
not a primitive, the semantics do need to be somehow defined in terms of
elementary operations of getting and setting (of attributes, items, &c).
Did I mention the possible incidental benefit of reducing the whinging
about the lack of variable declarations?

It might, with some luck;-). Probably worth a PEP, although I suspect
it will not be considered before 3.0.


Alex
 
A

Alex Martelli

Arthur said:
I would disagree, but only to the extent that nothing that is only a
request for an option toggle should qualify for this award. For
anyone not interested in it's effects, it's business as usual.

You must have lead a charmed life, I think, unusually and blissfully
free from pointy-haired bosses (PHBs). In the sublunar world that most
of us inhabit, ``optional'' idiocies of this kind soon become absolutely
mandatory -- thanks to micromanagement by PHBs.

For the last few years I've been working as a consultant -- mostly
(thanks be!) for a wonderful Swedish customer whose managers are in fact
great techies, but otherwise for a fair sample of typical development
shops. Such "fair samples" have weaned me from my own mostly-charmed
blissful life, confirming that the amount of utter stupidity in this
world is REALLY high, and far too much is that is in management
positions.

Now, I've recently had a great offer to work, doing mostly Python, for
another incredibly great firm, and, visa issues permitting, I'll gladly
leave the life of consultants' joys and sorrows behind me again -- I've
spent most of my life working as a full-time employee for a few great
firms, and the last few years have confirmed to me that this fits my
character and personality far better than being a consultant does (just
like the years between my two marriages have confirmed to me that I'm
better suited to be a husband, rather than a roving single... I guess
there's a correlation there!-). So, I'm not speaking for selfish
reasons: at my soon-to-be employer, techies rule, and optional idiocies
won't matter much. I _am_ speaking on behalf of maybe half of the
million or so Python programmers in the world, who are NOT so lucky as
to be working in environments free from the blight of micromanagement.


Alex
 
A

Arthur

You must have lead a charmed life, I think, unusually and blissfully
free from pointy-haired bosses (PHBs). In the sublunar world that most
of us inhabit, ``optional'' idiocies of this kind soon become absolutely
mandatory -- thanks to micromanagement by PHBs.

It seems to me that you would be more accurate (and calmer) if you
generalized from your own experience, rather than in direct
contradiction to it.

That the firms that advocate the use of Python are the one's least
likely to be dominated by PHB's who DKTAFTE (who don't know their ass
from their elbows).

Unless I am misintepreting you.

Do the STUPID firms use Python as well.

Why?

Clearly there are stupider choices.

I prefer to use VB when doing certain kinds of stupid things. It's
the right tool in those cases.

Really.

Perhaps the answer here has more to do with backing off efforts to
make Python ubiquitous.

Why shouldn't the community stay a bit elitist?

Or else maybe that's where you started on this thread, in fact - and
in your own way.

If so, I agree - within reason.

One doesn't toggle between VB and Python, perhaps is the point. They
are of different species.

Art
 
N

Nick Coghlan

Alex said:
It's not clear to me what semantics, exactly, x.y := z would be defined
to have (assuming := is the syntax sugar for ``rebinding''). Perhaps,
by analogy with every other augmented operator, it should be equivalent
to:

_temp = x.y
x.y = type(temp).__irebind__(temp, z)

This makes it crystal-clear what happens when type(x).y is a descriptor
with/without __set__ and __get__, when type(x) defines __getattribute__
or __setattr__, etc, etc. Giving type object an __irebind__ which just
returns the second operand would complete the semantics. Of course,
doing it this way would open the issue of types overriding __irebind__,
and it's not clear to me that this is intended, or desirable. So, maybe
some other semantics should be the definition. But since "rebinding" is
not a primitive, the semantics do need to be somehow defined in terms of
elementary operations of getting and setting (of attributes, items, &c).

I was thinking of something simpler:

x.y
x.y = z

That is, before the assignment attempt, x.y has to resolve to *something*, but
the interpreter isn't particularly fussy about what that something is.

Cheers,
Nick.
 
A

Alex Martelli

Nick Coghlan said:
...
I was thinking of something simpler:

x.y
x.y = z

That is, before the assignment attempt, x.y has to resolve to *something*, but
the interpreter isn't particularly fussy about what that something is.

OK, I guess this makes sense. I just feel a tad apprehensive at
thinking that the semantics differ so drastically from that of every
other augmented assignment, I guess. But probably it's preferable to
NOT let a type override what this one augmented assignment means; that
looks like an "attractive nuisance" tempting people to be too clever.

Still, if you write a PEP, I would mention the possible alternative and
why it's being rejected in favor of this simpler one.


Alex
 
A

Alex Martelli

Arthur said:
Do the STUPID firms use Python as well.

Yes, they're definitely starting to do so.


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
 
A

Arthur

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
 
J

Jeremy Bowers

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

Roy Smith

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

Alex Martelli

Roy Smith said:
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
 
A

Arthur

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


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

Nick Coghlan

Roy said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,764
Messages
2,569,567
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top