relative speed of incremention syntaxes (or "i=i+1" VS "i+=1")

[Stephen Hansen]

On 8/21/11 9:14 PM, Steven D'Aprano wrote:
>> That said: my advice is always to avoid += like a plague. It is magic
>> and impossible to predict without intimate knowledge of exactly what's
>> on the left-side.
>>
>>    i += 1
>>    n += x
>>
>> Those two things look very similar, but they may do -completely-
>> different things depending on just what "n" is.
> 
> Technically, the *exact same criticism* can be applied to:
> 
> n = n + x
> 
> since either n or x could override __add__ or __radd__ and do anything it
> bloody well likes. Including in-place modification of *either* argument
> (where possible).

I know: I addressed that. :P See, you know I addressed that, because:

> [...]
>> With "i = i + 1", I know that generally speaking, my "i" is being
>> assigned a new object and that's that, no matter what type "i" is.
>> (Okay: I do know that you could modify __add__ to do something
>> underhanded here, tweaking internal state and then returning self.
> 
> What makes you think that's underhanded?

You quoted me addressing that very fact, and responded! :)

Its underhanded outside of narrow, well-defined situations such as ORM's
and the like where they're doing interesting and novel things with the
object model.

Underhanded doesn't mean there's no reason one should ever do it, but
its very much an unusual thing and objects that do things like that
should NOT freely interact with general Python objects: very surprising
behavior will result.

> To my mind, __add__ modifying self as a side-effect is unusual, but apart
> from breaking the general rule of thumb to avoid side-effects, not
> particularly evil. (But I would accept this is a code smell.)

I didn't really say its evil, just that its underhanded: that's like,
sketchy, not evil. :)

There's good reasons to do it on occasion, but if an object does
something like that then that is a very special kind of object and when
using it, you need to be very aware of its unusual semantics.

Having objects like that is fine.

However, for the /language/ to have unusual (and unpredictable, from
something of a distance at least) semantics, rubs me very much the wrong
way.

>> People going out of their way to behave unpredictably is not my
>> objection: supposedly easy and straight-forward normal Python-fu being
>> inherently unpredictable is).
>>
>> For example: I just /know/ that it doesn't matter who or what may have
>> their own binding to that object before I go and increment it, they
>> won't be affected and everything just will work fine. 
> 
> But you can't /know/ that at all, unless you know that the object
> isn't "underhanded" (however you define that!). And given some arbitrary
> object, how can you know that?

I CAN know it with sufficient certainty that I can rely on it, and if I
get messed up on it-- its never happened yet-- then I can fire someone
or get a new library, after staring at an odd traceback and scratching
my head for a minute.

Python has very soft rules, I know that. Objects /can/ do all kinds of
crazy things. I'm okay with that.

But I can rely on certain behaviors being consistent: the basic behavior
of the language is very straight-forward. It has hooks where you can do
lots of Special stuff, and if objects are Special, they're described as
Special.

ORM's have a lot of Special objects, for example. That's fine: when
messing with ORM objects, I know I have to take care with the operators
I use against them, because I know I'm not using a /usual/ Python
object. SQLAlchemy for example. This is not a criticism of SQLAlchemy:
having magic objects lets it construct SQL in ways that are vastly
easier then if they stuck to more regularly behaving objects.

But, += is Python itself adding an unpredictable behavior into the core
language, with its own base types behaving

The *exact same criticism* can NOT be applied to

    n = n + x

Because my criticism isn't about one choosing to do crazy stuff with the
object model. I've never advocated Python be strict about rules.

But for Python, all by itself, with nothing but built-in and basic
types, to have a situation where:

    a = a + b
    a += b

... does two very distinctly different actions, even if in many or
even most circumstances the end-result is probably the same and probably
fine, is my criticism.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20110821/5f212ce3/attachment-0001.sig>