Home Original page

PATCH: Augmented assignment

Doug Stanfield DOUGS at oceanic.com
Fri Jun 9 16:11:25 EDT 2000 
[Thomas Wouters wrote:] 
> >As promised, here is my patch to add augmented assignment (+=, -= and
> >family) to Python. It's still Work In Progress, and probably 
> requires a
> >rewrite of some magnitude before Guido will accept it.
> 
> 
> Why would the Python community want this?  It obfuscates 
> code, in as much
> that newbies aren't likely to intuite what the symbols mean.

There are a lot of things that the newbie doesn't understand.  I still can't
get my brain around 're'.  That definately doesn't mean that it shouldn't be
available to those who can.

> We just had a thread suggesting that = and == are frequently 
> confused by
> newbies.   How much more confused would they be with a plethora of
> alternative symbols?

I disagree that confusion by newbies, in and of itself, is necessarily a bad
thing.  Programming has some inherent sticky problems.  The question should
always be whether a particular confusion is artificially introduced by the
language or inherent to what needs to be understood.  Having two symbols '='
and '==' and thus having to explicitly understand the difference is good
because that is a fundamental to programming.  Not having them introduces
confusion because of the implicit nature.  "Explicit is better then
implicit". - Tim Peters

> Python seems to stick to the "one right way" model of 
> programming: most
> people's code tends to look the same.  It increases 
> maintainability and
> readability.

If the clearest way is what is taught most of the code produced will end up
clear.  I am in the middle of producing an example proving the exception to
the rule of clarity of Python coding.  It definately doesn't look the same
as "most people's code". It is much clearer than what I might produce if I
was trying to do it in, say, QBASIC.  I promise to clean it up when I get
more time ;-)
  
> I think we'll end up with a confusion of styles if augmented 
> assignments
> are allowed.

As in the case with '=' and '==', if you know you need them you've had to
think about why and where they go.  Obfuscate the documentation enough and
no newbie will be tempted.  If a newbie is reading code the documentation
should be clear that these are for optimization.  Good way to introduce such
concepts.

> And it's not like it adds new functionality nor improves code 
> readibility.
> It just saves the lazy programmer a whopping one or two keystrokes.

I don't see it this way.  I think mostly it won't be used if like you say it
reduces readability.  Those who need it will really appreciate it being
there.  I'm too lazy to look up the reference, but its been stated that
there can be a performance improvement given certain problem spaces.  It
would be great if that optimization (whatever it is) could be done under the
covers but that won't happen (probably) in the Python 1.x lineage.  Maybe
these extra symbols can be optimized out in Py3K.

-Doug-
More information about the Python-list mailing list