[Python-il] [pyweb-il:1072] Python coding question

Amit Aronovitch aronovitch at gmail.com
Fri Jul 9 03:43:26 IDT 2010


On Fri, Jul 9, 2010 at 2:49 AM, Shai Berger <shai at platonix.com> wrote:

> On Thursday 08 July 2010, you wrote:
> > > I wouldn't like the trade-off where you "win" a couple of
> > > questions on mailing-lists and pay for it with the DRY in
> > >
> > > complex_or_just_long_reference = complex_or_just_long_reference + 1
> >
> > But wouldn't you prefer something like
> >   complex_or_just_long_reference = same + 1
> > which turns out to be more powerful than the standard pack of syntactic
> > sugar constructs:
> >   complex_or_just_long_reference = max(same, new_thing)
> > or
> >   complex_or_just_long_reference = "(" + same + ")"
> > IMHO, this is more readable and saves most of the mess with long names.
> >
>
> This is an interesting idea -- I agree that it has merits, but I also see
> why
> it wouldn't be included in a language where 'self' is a convention and not
> a
> keyword.
>
> While it is definitely more general, I don't see it as more readable in the
> common cases. Between C and its descendents, += has become quite
> entrenched.
>
>
But that's exactly the problem! It looks like something they know, but does
not do what they expect it to do. Well, sometimes it does, depending on the
type of the object, but this only makes it even more confusing.

>>> a = 1; b=a
>>> a += 1
>>> b
1
>>> from numpy import array
>>> a = array(1); b=a
>>> a+=1
>>> b
array(2)

 This type-dependent semantics blurs the distinction between mangling the
namespace and modifying the objects, adds complexity and special-cases to
the mental model.
 Suppose you are documenting a function that gets a parameter x (which might
be an instance of user defined class), and does x/=2;x+=3 .
 What would you say? "The parameter x will be modified only if it has both
__iadd__ and __idiv__ defined?" and you'll have to keep track in case
 you later add a -= as well...

 Normally you will just not do that. Either completely avoid augmented
assignments, or use them explicitly:
    x.__idiv__(3)
 which will raise an exception if the object does not support the protocol.

This brings us to my own, much simpler, hypothetical alternative:
  x.* y (equivalent to x.__imul__(y) ), x.+ y, etc.

     AA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://hamakor.org.il/pipermail/python-il/attachments/20100709/de6ad322/attachment.htm 


More information about the Python-il mailing list