Mailing List Archive

In article <37B47506.14EBD269@msfc.nasa.gov>
drew.mcdowell@msfc.nasa.gov "Drew McDowell" writes:
> I looked in the FAQ and couldn't find anything on the Compound
> Assignment Operators.
> (+=, *=, -=, etc..)
> Why dosen't Python support them?

Cos Guido doesn't like them, I imagine.

> Is there a easy way to add them?

Well, you have the source...

--
Phil Hunt....philh@vision25.demon.co.uk

On 13 Aug 1999 19:41:18 GMT, Drew McDowell <drew.mcdowell@msfc.nasa.gov> wrote:
>I looked in the FAQ and couldn't find anything on the Compound
>Assignment Operators.
>(+=, *=, -=, etc..)
Yeah, maybe it should be a FAQ.
>Why dosen't Python support them?
Don't really know, I guess the authors consider them unnecessary
syntactic sugar.
>Is there a easy way to add them?
Make you editor replace += with the proper thing.
Browse newgroup archive (dejanews) to find some example for vim...
Bernhard


--
Research Assistant, Geog Dept UM-Milwaukee, USA. (www.uwm.edu/~bernhard)
Association for a Free Informational Infrastructure (ffii.org)

Phil Hunt <philh@vision25.demon.co.uk> wrote:
> Cos Guido doesn't like them, I imagine.

seen on the python list, back in november 1991:

someone wrote:
> How about providing assignment operators?

guido:
> Agreed. Now that the parser can actually recognize
> two-character operators, adding these wouldn't be so
> hard (except that the grammar tables will grow again :-( ).

since this hasn't made it into the language yet, I suppose
keeping the grammar tables small is quite important ;-)

</F>

[courtesy cc of this posting mailed to cited author]

In comp.lang.python, Drew McDowell <drew.mcdowell@msfc.nasa.gov> writes:
:I looked in the FAQ and couldn't find anything on the Compound Assignment
:Operators. (+=, *=, -=, etc..) Why dosen't Python support them?
:Is there a easy way to add them?

Well, to start with, Python does not even *have* an assignment operator.
Nope, not one. Assignment is a statement, not an operator. That's while
you can't write:

while line = file.readline():
print line

for example.

Mostly it's the old "burnt child fears fire" syndrome. Or, if you would,
"fool me once, shame on you; fool me twice, shame on me". By outlawing
it, you can't get burned/fooled by it. Too many horrendous C programming
errors happen from confusing:

while (var = function()) { }

with

while (var == function()) { }

Think of the classic loop:

while ((ch = getchar()) != EOF) { }

You end up having to use parentheses in do group the assignment,
and then test its result.

As for why you can't write the statement (note: not the expression)

x["every"]["good"]["boy"]["does"]["fine"] = (
x["every"]["good"]["boy"]["does"]["fine"] + 1 )

as

x["every"]["good"]["boy"]["does"]["fine"] += 1

The basic reason seems to be that there are some people who believe that
this kind of thing is cruel and unusual punishment levied upon the poor
Pascal(ish) programmers purely for sake of brevity.

Common arguments in support of such ops include:

1) This requires care to avoid mis-duplication:
x["every"]["good"]["boy"]["does"]["fine"] = (
x["every"]["good"]["boy"]["deos"]["fine"] + 1 )
2) Side effects must be duplicated:
x[every()][good()][boy()][does()][fine()] = (
x[every()][good()][boy()][does()][fine()] + 1 )
3) It's too long to type.
4) Needless redundancy obscures the real meaning.

Whereas common rebuttals include:

1) Toss /bin/ed and get yourself a real editor.
2) Don't use side-effects, you wicked creature, you!
3) It's more efficient to keep a tmpobj anyway.
4) Redundancy can clarify through redundancy.

As to why there's no x++ there, consider how often people from a
Pascal(ish) background are confused between x+1 and x++ and ++x, and
you'll begin to see what kind of problems caused it to be vetoed.

But the best reason is probably the one another poster already supplied:
because Guido didn't like them. An interesting study would be to check
the extent to which he also forbids such constructs in his own C code. :-)

--tom
--
Besides, REAL computers have a rename() system call. :-)
--Larry Wall in <7937@jpl-devvax.JPL.NASA.GOV>

[posted & mailed]

[Tom Christiansen]
> Mostly it's the old "burnt child fears fire" syndrome. Or, if you
> would, "fool me once, shame on you; fool me twice, shame on me". By
> outlawing it, you can't get burned/fooled by it.

Right. It is part of Python's stated goals to be "safe as milk" under
normal usage. (Obviously, all bets are off as soon as you override
__setattr__, or play with metaclasses).

> As to why there's no x++ there, consider how often people from a
> Pascal(ish) background are confused between x+1 and x++ and ++x, and
> you'll begin to see what kind of problems caused it to be vetoed.

Additional point: If x++ were taken as syntactic sugar, it would have
the odd affect of modifying a name binding in place.

If more than syntactic sugar, it would do different things depending
on whether x was mutable or immutable.

No telling whether either of those would become major conceptual
stumbling blocks without experimentation. While I like both those
shortcuts, there are certainly more interesting things to experiment
with.

> But the best reason is probably the one another poster already
> supplied: because Guido didn't like them. An interesting study
> would be to check the extent to which he also forbids such
> constructs in his own C code. :-)

As you probably expected, when Guido writes C, he writes C.

- Gordon

Tom Christiansen <tchrist@mox.perl.com> writes:

>
> As to why there's no x++ there, consider how often people from a
> Pascal(ish) background are confused between x+1 and x++ and ++x, and
> you'll begin to see what kind of problems caused it to be vetoed.
>

Hm. I would have thought that the reason for this is more that x++ is,
in fact, an expression, an allowing this would amount to allowing a
special case of assignment expressions... Or?

--

Magnus Making no sound / Yet smouldering with passion
Lie The firefly is still sadder / Than the moaning insect
Hetland : Minamoto Shigeyuki

Tom Christiansen <tchrist@mox.perl.com> wrote:
> [courtesy cc of this posting mailed to cited author]

> In comp.lang.python, Drew McDowell <drew.mcdowell@msfc.nasa.gov> writes:
> :I looked in the FAQ and couldn't find anything on the Compound Assignment
> :Operators. (+=, *=, -=, etc..) Why dosen't Python support them?
> :Is there a easy way to add them?

[motivations against assignment in expressions snipped]

There's an interesting analogy here with the inability to leave off the
{ and } in Perl in a single lined block, like you can in C. The motivation
is that people shoot themselves in the foot with it too often, I recall.

Note that the usual way to do such a readline loop in Python goes like
this:

while 1:
line = f.readline()
if not line:
break
... stuff with line here ..

Not too difficult and easy enough to recognize, though it does take some
getting used to.

There were a couple of big threads about assignment in expressions
a while back. In one of those discussions people came up with
interesting ways to do these things without the infinite loop. Often
these center on iterator approaches. It's possible the vaporware Python 2
will extend on that idea.

> As for why you can't write the statement (note: not the expression)

> x["every"]["good"]["boy"]["does"]["fine"] = (
> x["every"]["good"]["boy"]["does"]["fine"] + 1 )

> as

> x["every"]["good"]["boy"]["does"]["fine"] += 1

> The basic reason seems to be that there are some people who believe that
> this kind of thing is cruel and unusual punishment levied upon the poor
> Pascal(ish) programmers purely for sake of brevity.

You can do:

a = x["every"]["good"]["boy"]["does"]
a["fine"] = a["fine"] + 1

Not perfect, perhaps, but a lot easier. It's interesting, but I actually
don't recall running into this problem a lot with Python at all.

> Common arguments in support of such ops include:

> 1) This requires care to avoid mis-duplication:
> x["every"]["good"]["boy"]["does"]["fine"] = (
> x["every"]["good"]["boy"]["deos"]["fine"] + 1 )

You avoid misduplication with the above solution.

> 2) Side effects must be duplicated:
> x[every()][good()][boy()][does()][fine()] = (
> x[every()][good()][boy()][does()][fine()] + 1 )

Partially solved by the above solution.

> 3) It's too long to type.

I'd say solved by the above solution.

> 4) Needless redundancy obscures the real meaning.

I seem to be neutral on this. :)

> Whereas common rebuttals include:

> 1) Toss /bin/ed and get yourself a real editor.

Indeed helpful.

> 2) Don't use side-effects, you wicked creature, you!

When you use side-effects, be careful. :)

> 3) It's more efficient to keep a tmpobj anyway.

I don't get this one. By 'tmpobj', do you mean my solution? Indeed,
it'd be more efficient as you'd avoid (costly) Python name lookups.

> 4) Redundancy can clarify through redundancy.

I plead neutrality once again.

> As to why there's no x++ there, consider how often people from a
> Pascal(ish) background are confused between x+1 and x++ and ++x, and
> you'll begin to see what kind of problems caused it to be vetoed.

I don't think Python was designed for people with a Pascallish background
at all, by the way.

> But the best reason is probably the one another poster already supplied:
> because Guido didn't like them. An interesting study would be to check
> the extent to which he also forbids such constructs in his own C code. :-)

When coding in C, code in C; when coding in Python, code in Python. From
what I've heard the Python C sourcecode is well designed; I'm also sure the
constructs are used in many places.

But again, this problem is something that in practice just does not seem
to happen to me when I program in Python.

Regards,

Martijn

[courtesy cc of this posting mailed to cited author]

[Drew McDowell]
> I looked in the FAQ and couldn't find anything on the Compound
> Assignment Operators. (+=, *=, -=, etc..) Why doesn't Python
> support them?

Look in the ToDo list, or search DejaNews very hard <wink>.

> Is there a easy way to add them?

Nope.

[switching to Tom Christiansen]
> Well, to start with, Python does not even *have* an assignment
> operator. Nope, not one. Assignment is a statement, not an
> operator.
> [.followed by the familiar confusions owing to assignment operators
> in C]

That's indeed why Python doesn't have assignment operators. Drew was really
asking why Python doesn't have Compound Assignment Statements (he'll get
back to why it doesn't have assignment operators ...), so:

> ...
> As for why you can't write the statement (note: not the expression)
>
> x["every"]["good"]["boy"]["does"]["fine"] = (
> x["every"]["good"]["boy"]["does"]["fine"] + 1 )
>
> as
>
> x["every"]["good"]["boy"]["does"]["fine"] += 1
>
> The basic reason seems to be that there are some people who believe
> that this kind of thing is cruel and unusual punishment levied upon
> the poor Pascal(ish) programmers purely for sake of brevity.

THere are, but Guido isn't one of them. He's on record as liking augmented
assignments well enough that he'd put them in someday if more than 6 people
cared <wink>. Seriously, the problem at the start was simply one of
non-obviousness. For example, if x and y are lists, does

z = x
x += y
print z

mean

x = x + y # x is now bound to an entirely different object
# and the old x is printed

or

x.extend(y) # x is still the same object, but mutated
# and the new x is printed

? The resulting *values* compare equal either way, but there are
differences in efficiency and effects on object identity.

There were more important questions to resolve first, and the lack of
augmented assignments hasn't caused enough people enough pain to force a
resolution of these questions. Nevertheless, in good Pythonic fashion,
Guido's favored resolution is to say it's up to the object: whatever type x
may happen to have, it's up to x.__addeq__(y) to decide what "+=" (& so on)
means.

> Common arguments in support of such ops include:
>
> 1) This requires care to avoid mis-duplication:
> ...
> 2) Side effects must be duplicated:
> ...
> 3) It's too long to type.
> 4) Needless redundancy obscures the real meaning.

5) Efficiency.

> Whereas common rebuttals include:
>
> 1) Toss /bin/ed and get yourself a real editor.
> 2) Don't use side-effects, you wicked creature, you!
> 3) It's more efficient to keep a tmpobj anyway.
> 4) Redundancy can clarify through redundancy.

5) Not having it was good enough for my grandfather, and what makes you
think you're better than him <wink>?

> ...
> But the best reason is probably the one another poster already
> supplied: because Guido didn't like them.

Not so in this case (++x and x++ are a different matter). Supply & demand,
and need vs desire, get closer.

> An interesting study would be to check the extent to which he
> also forbids such constructs in his own C code. :-)

Python's implementation begins with:

#define colon {
#define dedent }
#define spaces(E) (E)
#define rspace )
#define newline ;

if spaces(sVersion == 0) colon
printf("internal error") newline
exit(1) newline
dedent

if-perl-really-believed-in-freedom-it-would-have-a-
character-level-preprocessor<wink>-ly y'rs - tim

First off, I'd like to apologize for the Compound Assignment Operator vs.
Compound Assignment Statement confusion...
I'll get the hang of this some day <grin>


Tim Peters wrote:

> Seriously, the problem at the start was simply one of
> non-obviousness. For example, if x and y are lists, does
>
> z = x
> x += y
> print z
>
> mean
>
> x = x + y # x is now bound to an entirely different object
> # and the old x is printed
>
> or
>
> x.extend(y) # x is still the same object, but mutated
> # and the new x is printed
>
> ? The resulting *values* compare equal either way, but there are
> differences in efficiency and effects on object identity.
>

I don't see where the "non-obviousness" comes into play...
(maybe that's why it's not obvious <wink>)

Why would you confuse x += y (which would seem to imply the former) to mean
x.extend(y) ? It _is_ and assignment statement after all..


>
> There were more important questions to resolve first, and the lack of
> augmented assignments hasn't caused enough people enough pain to force a
> resolution of these questions.

Not to touch on a sore topic, but hop over to comp.lang.perl and check out the
(rather long and heated) comparison of perl and python.
The lack of these statements is causing quite a bit of a stir.


> Nevertheless, in good Pythonic fashion,
> Guido's favored resolution is to say it's up to the object: whatever type x
> may happen to have, it's up to x.__addeq__(y) to decide what "+=" (& so on)
> means.
>

Why addeq?? Why not just add?

>
> 5) Not having it was good enough for my grandfather, and what makes you
> think you're better than him <wink>?
>

Because Python wasn't around then! <wink>

On Sun, 15 Aug 1999 03:09:14 -0500, Andrew McDowell <drew@getaway.net> wrote:
>Why would you confuse x += y (which would seem to imply the former) to mean
>x.extend(y) ? It _is_ an assignment statement after all..

If you have:
aList = []
bList = aList
aList += [1,2,3]

Do aList and bList still point to the same list? I think people could
argue for either interpretation as being the most intuitive.

Another thing: if the meaning is taken as "x = x + y", this means that
x+=y is really quite inefficient, which will be confusing to people
who've been indoctrinated to believe that '++' lets the compiler
produce better code. That may be true for C, but if you coded "for i
in biglist: resultlist += thingy", you'd do a lot of unnecessary list
copying.

--
A.M. Kuchling http://starship.python.net/crew/amk/
We are Brigand Philosophers / Our hearts are high and cheery, / For we know
our robbery rests upon / A sound economic theory!
-- _The Golden Ass_, music Randolph Peters, libretto Robertson Davies

Tom Christiansen (tchrist@mox.perl.com) wrote:

> Common rebuttals [to += and co.] include:

> 3) It's more efficient to keep a tmpobj anyway.

Bah. Temporary variables are evil!

> 4) Redundancy can clarify through redundancy.

Wossat? Sounds like rot to me. :-)

> As to why there's no x++ there, consider how often people from a
> Pascal(ish) background are confused between x+1 and x++ and ++x, and
> you'll begin to see what kind of problems caused it to be vetoed.

This is a good point, but stems from C's tendency to return values all
the time from things I think it shouldn't. :-)

I'd like a syntax like:

x.+(1)

With the idea that x is an object (of type int) with a '+' method that
adds stuff to it. It'd be nicer without the brackets though.

:opens the language can of worms again

--
This posting was brought to you by And Clover.
(Sorry.)

http://radio.warwick.ac.uk/shows/losertown/

Drew McDowell <drew.mcdowell@msfc.nasa.gov> writes:

> I looked in the FAQ and couldn't find anything on the Compound
> Assignment Operators.
> (+=, *=, -=, etc..)
> Why dosen't Python support them? Is there a easy way to add them?
>
> -Drew McDowell

One reason that these constructs could cause problems is due to
namespaces. Assuming that x += y is expanded to x = x + y, consider
the following code while remembering how python treats namespaces and
global variables.

>>> def foo():
... x += 2
... return x
>>> x = 42
>>> foo()
44
>>> x
42

I don't think this is what you want to happen, but it is what python
would do. Inside foo(), the global variable x is read, then a local
variable x is created (there is no `global x' in the function). So in
this case x += 2 does not add 2 to x, it creates a new local variable
that is 2 greater than the global variable of the same name.

Confused yet, well here's a second reason.

>>> x = [1,2,3,4]
>>> y = x
>>> x += [5,6]
>>> x
[1,2,3,4,5,6]
>>> y
what should this be?

you would expect x += y on lists to actually extend the list, or do
you want it to be x = x + y, which could be really slow on big lists,
while hiding the fact that it is copying the list.

--
Tim Evans

>> ... does
>>
>> z = x
>> x += y
>> print z
>>
>> mean
>>
>> x = x + y # x is now bound to an entirely different object
>> # and the old x is printed
>>
>> or
>>
>> x.extend(y) # x is still the same object, but mutated
>> # and the new x is printed
>>
>> ? The resulting *values* compare equal either way, but there are
>> differences in efficiency and effects on object identity.

[Andrew McDowell]
> I don't see where the "non-obviousness" comes into play...
> (maybe that's why it's not obvious <wink>)

In that reasonable people can (& do) expect either behavior.

> Why would you confuse x += y (which would seem to imply the
> former) to mean x.extend(y) ?

Efficiency; and, to half the reasonable people in the world, obviousness
<wink>.

> It _is_ and assignment statement after all..

That's my mild preference, and it's easier to implement that way; but some
reasonable people want it the other way. Consider the NumPy extension,
where "x" can denote a matrix with millions of elements and consuming many
Mb of storage. There you may desperately not want e.g.

x += 1

to create an entirely new similar-sized matrix, yet still want the economy
of expression. Guido's preferred scheme caters to either behavior.

> Not to touch on a sore topic, but hop over to comp.lang.perl and
> check out the (rather long and heated) comparison of perl and python.

So *that's* what it is -- I thought it was a flame war.

> The lack of these statements is causing quite a bit of a stir.

I expect you could post "have a nice day!" to that thread and also "cause"
quite a bit of a stir. Flame wars aren't "about" the topics being toasted,
y'know <0.1 wink>.

>> ... it's up to x.__addeq__(y) to decide what "+=" (& so on) means.

> Why addeq?? Why not just add?

So that it's *possible* for the implementation of x's type to arrange for

y = x + 1

to create a new object but for

x += 1

not to. If you don't want to allow for mutation, __addeq__ isn't needed
(and you can find an implementation sketch in DejaNews for this case -- it's
easy to implement in Python's front end).

lettuce-should-never-be-chewed-twice-ly y'rs - tim

Andrew Clover <esuzm@primrose.csv.warwick.ac.uk> wrote:
> I'd like a syntax like:
>
> x.+(1)
>
> With the idea that x is an object (of type int) with a '+' method that
> adds stuff to it. It'd be nicer without the brackets though.

mutable integers? now that's a really cool feature! (known
from Fortran and Tcl, among others. I'm pretty sure Perl
has them too ;-).

</F>

Fredrik Lundh wrote:
>
> Andrew Clover <esuzm@primrose.csv.warwick.ac.uk> wrote:
> > I'd like a syntax like:
> >
> > x.+(1)
> >
> > With the idea that x is an object (of type int) with a '+' method that
> > adds stuff to it. It'd be nicer without the brackets though.
>
> mutable integers? now that's a really cool feature! (known
> from Fortran and Tcl, among others. I'm pretty sure Perl
> has them too ;-).

Here's a mutable integer implementation: it's a counter
type with which you can do cute things like:

>>> c = Counter(0)
>>> ++c
1
>>> ++c
2

You can even split the increment into two operations (well, that's
due to the hack used to implement this):

>>> +c
2
>>> +c
3

Here's some more magic:

>>> +-c
3
>>> -+c
4
>>> -+c
4
>>> -+c
4
>>> +-c
3
>>> +-c
3

To find out how this works, see:

http://starship.skyport.net/~lemburg/mxCounter-0.1.zip

--
Marc-Andre Lemburg
______________________________________________________________________
Y2000: 138 days left
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/

[courtesy cc of this posting mailed to cited author]

In comp.lang.python,
Timothy R Evans <tre17@pc142.cosc.canterbury.ac.nz> writes:
:One reason that these constructs could cause problems is due to
:namespaces. Assuming that x += y is expanded to x = x + y, consider
:the following code while remembering how python treats namespaces and
:global variables.
:
:>>> def foo():
:... x += 2
:... return x
:>>> x = 42
:>>> foo()
:44
:>>> x
:42
:
:I don't think this is what you want to happen, but it is what python
:would do. Inside foo(), the global variable x is read, then a local
:variable x is created (there is no `global x' in the function). So in
:this case x += 2 does not add 2 to x, it creates a new local variable
:that is 2 greater than the global variable of the same name.

That's not the way I dimly understand it. You can't from a local
scope even try to do a

x = x + 2

on a global, unless you declare x to be global. Anything else is illegal,
because you'd end up talking about a global and a local at the same
time. Consider if your function were written:

def foo():
x = x + 2
return x

That's not legal even now. You need the global.

:Confused yet, well here's a second reason.
:
:>>> x = [1,2,3,4]
:>>> y = x
:>>> x += [5,6]
:>>> x
:[1,2,3,4,5,6]
:>>> y
:what should this be?
:
:you would expect x += y on lists to actually extend the list, or do
:you want it to be x = x + y, which could be really slow on big lists,
:while hiding the fact that it is copying the list.

I think you've pointed out a real issue here, but it's not the "big lists
are slow one". That's just something the compiler should just optimize.

The real issue is the aliasing issue. If you write:

x = [1,2,3,4]
y = x

Then you are expecting x and y to refer to the same object. If you use

x = x + [5,6]

then you've orphaned y, which remains as it was due to the
semantics of "+" providing a new result list.

Is this bad? I don't know for sure. Sometimes it seems to make sense.
Certainly if you write

x = 4
y = x
x = x + 2

you don't expect y to track the changes to x and also be 6.

I don't really see any reason for

var += expr

to be defined in any terms other than

var = var + expr

However, I do see ample opportunity for optimization, some of which
might be easier given += then it would be if written out long hand.

--tom
--
"The purpose of most computer languages is to lengthen your resume by
a word and a comma." --Larry Wall

[courtesy cc of this posting mailed to cited author]

In comp.lang.python,
gmcm@hypernet.com writes:
:[posted & mailed]
:Additional point: If x++ were taken as syntactic sugar, it would have
:the odd affect of modifying a name binding in place.
:
:If more than syntactic sugar, it would do different things depending
:on whether x was mutable or immutable.

People are probably only thinking of ++ for numbers, and I don't see that
"in place changes" matter there. There's no reason that it should make
sense on, say lists. It's a lot easier to survive without ++ than it
is without +=, however. :-)

--tom
--
Even if you do learn to speak correct English, whom are you going to
speak it to?
--Clarence Darrow

[courtesy cc of this posting mailed to cited author]

In comp.lang.python, akuchlin@mems-exchange.org writes:
:... but if you coded "for i
:in biglist: resultlist += thingy", you'd do a lot of unnecessary list
:copying.

Only if you implemented it that way, which wouldn't appear to be
particularly clever. :-)

--tom
--
"Just because you're screwed *up* doesn't mean you're screwed." --Larry Wall

Tom Christiansen <tchrist@mox.perl.com> writes:

> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.python,
> Timothy R Evans <tre17@pc142.cosc.canterbury.ac.nz> writes:
[snip]
> def foo():
> x = x + 2
> return x
>
> That's not legal even now. You need the global.
>
[snip]

Oops, you're right of course, you can access globals but you can't
override a global definition if you have already used the global
value. Quite strange behaviour really.

x = 5
def foo():
print x # works, prints 5
def bar():
x = 6 # works, but doesn't change the global
def wibble():
print x
x = 6 # this fails with NameError

Seems like a good behaviour as it stops you doing dumb things.

--
Tim Evans

[courtesy cc of this posting mailed to cited author]

In comp.lang.python,
Timothy R Evans <tre17@pc142.cosc.canterbury.ac.nz> writes:
:x = 5
:def foo():
: print x # works, prints 5
:def bar():
: x = 6 # works, but doesn't change the global
:def wibble():
: print x
: x = 6 # this fails with NameError
:
:Seems like a good behaviour as it stops you doing dumb things.

Perhaps it could give a better error message, pretty please? Sometimes
driving Python feels like driving Ken Thompson's car. It just keeps saying
"?" and you're expected to know what that means. :-(


--tom

PS: From an old joke about Ken's treatment of error messages in ed.
--
If I allowed "next $label" then I'd also have to allow "goto $label",
and I don't think you really want that... :-) [now works in perl5!]
--Larry Wall in <1991Mar11.230002.27271@jpl-devvax.jpl.nasa.gov>

[posted & mailed]

[Timothy R Evans]
> :x = 5
> :def foo():
> : print x # works, prints 5
> :def bar():
> : x = 6 # works, but doesn't change the global
> :def wibble():
> : print x
> : x = 6 # this fails with NameError
> :
> :Seems like a good behaviour as it stops you doing dumb things.

[Tom Christiansen]
> Perhaps it could give a better error message, pretty please?

I whined about this for years myself, and a month or two ago finally wrote a
patch to make it raise UnboundLocalError instead -- which is what you'll get
if you use the current CVS version of Python. It should be made clear that
Timothy's wibble example fails on the "print x" line, though, not the
assignment.

> Sometimes driving Python feels like driving Ken Thompson's car.
> It just keeps saying> "?" and you're expected to know what
> that means. :-(

But also like a sleek modern car with idiot lights, Python's syntax is so
simple you soon figure out that "?" means what it says <wink>.

change-the-oil-or-fix-the-syntax-ly y'rs - tim

In comp.lang.python,
Timothy R Evans <tre17@pc142.cosc.canterbury.ac.nz> writes:
>def wibble():
> print x
> x = 6 # this fails with NameError
>
>Seems like a good behaviour as it stops you doing dumb things.

Tom Christiansen writes:
> Perhaps it could give a better error message, pretty please? Sometimes
> driving Python feels like driving Ken Thompson's car. It just keeps saying
> "?" and you're expected to know what that means. :-(

Current behavior (1.5.2 as released) raises UnboundLocalError (a
subclass of NameError), which is much more informative and is usually
exactly what is needed to point out to the programmer where the coding
error is.


-Fred

--
Fred L. Drake, Jr. <fdrake@acm.org>
Corporation for National Research Initiatives