Brython - Python in the browser

[Chris Angelico]

On Fri, Dec 21, 2012 at 1:05 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 20 Dec 2012 18:59:39 -0500, Terry Reedy wrote:
>> What Python does have is 11 versions of the augmented assignment
>> statement: +=, -=, *=, /=, //=, %=, **=, >>=, <<=, &=, ^=, |=. Moreover,
>> these are *intended* to be implemented in place, by mutation, for
>> mutable objects, with possibly class-specific meanings.
>
> I don't believe that is the case. The problem is that augmented
> assignment that mutates can be rather surprising to anyone who expects
> "a += b" to be a short cut for "a = a + b".

This is confusing only because it violates the principle that exists
with methods, that it _either_ mutates _or_ returns. The augmented
assignment operators must return, and in some cases also mutate, hence
confusion.

> One might even have a class where (say) __iadd__ is defined but __add__
> is not.

That would be plausible, if it had an easy way to clone an object.
This would in fact be my preferred way to do things if the clone
operation is expensive - such as in this case. Adding two DOM trees
could be prohibitively expensive (if the tree is deep), but parenting
a tree to another is cheap.

>> <= is a comparison expression operator, which is completely different.
>
> <= is a comparison operator for ints, floats, strings, lists, ... but not
> necessarily for *everything*. That's the beauty and horror of operator
> overloading. Any operator can mean anything.
>
> If it were intended to only return a flag, then 1) Python would enforce
> that rule, and 2) the numpy people would be most upset.

There's a difference between returning a different data type that
makes good sense (compare two arrays and get an array of booleans) and
abusing an operator for its visual characteristics. The former is a
good reason to have the language grant freedom; the latter is proof
that freedom can be used in many ways. I'm not saying it's always
wrong, but it certainly isn't right as often as the other is.

> I have no opinion on the usefulness or sensibility of using <= as an in-
> place mutator method in this context, but I will say that if I were
> designing my own mini-DSL, I would not hesitate to give "comparison
> operators" some other meaning. Syntax should be judged in the context of
> the language you are using, not some other language. If you are using a
> DSL, then normal Python rules don't necessarily apply. <= in particular
> looks just like a left-pointing arrow and is an obvious candidate for
> overloading.

<tongue location="cheek">But there's no corresponding => arrow! How
can you make your DSL look like PHP arrays without that vital array
creation operator?</tongue>

ChrisA