On Thu, Oct 01, 2020 at 04:02:20AM +1000, Steven D'Aprano wrote:

Hi Konatan, welcome! Comments below.

Oh I'm very sorry, that was a typo, I meant Jonatan. -- Steve

-1 for various reasons expressed by several authors. But I'm not sure I agree with this: Steven D'Aprano writes:

I think this might make good sense for string methods:

mystring = mystring.upper() mystring .= upper()

but less so for arbitrary objects with methods returning arbitrary values, or methods that operate in place.

...

...

l = [0] l *= 5 l [0, 0, 0, 0, 0]

Operators are just functions. In most cases, we try to define them as algebraic operations, but occasionally there's reason to do otherwise. When we do, often the augmented assignment operators do sane things, too. I don't see why that wouldn't be true for '.', although I don't think that's a slam dunk either, '.' is different from most operators.

Steven D'Aprano writes:

I'm not sure that I understand your example here. Or rather, I understand your example, I don't understand why you think it disputes my comment above. Your example uses the list repetition operator, which returns a list; it is neither something that returns an arbitrary value, nor a method that operates in place.

My point is that given that the operation involves a non-list and the operation is in fact defined to be commutative, it *is* something that returns an arbitrary value -- if your frame of reference is a binary operation on a set, which involves two operands and a result, all members of the same set.

Here are two hypothetical examples:

[...]

It's not clear to me that either of these would make good examples of augmented assignment:

Sure, but that's not the way this works, picking out obviously bad examples. You need to do some work to make the plausible. In the case of the list index, renaming the assignment target: ndx = [10, 20, 30, 40, 50] ndx .= index(40) To me that looks like a statement-oriented version of the fluent style. For the "returning None" example, using .= with a method that is *defined* to return None is pretty silly. But consider a binary tree where the attributes Node.left and Node.right are None if no subtree is attached: # 1776, not Hamilton def cool_cool_conservative_men(federalist_heap): judge = federalist_heap while judge: appoint_justice(judge) judge .= right Note that this example could be modified to use a null Node (ie, bool(null_node) == False) instead of None, in which case it could be in-place. Are those styles Pythonic? Probably not. Are they even practically useful? I'm not sure. But they're much more the kind of example we need to look at to understand this proposal.

On Wed, Sep 30, 2020 at 4:24 PM Ben Rudiak-Gould wrote:

On Wed, Sep 30, 2020 at 1:43 PM David Mertz wrote:

...

Fluent programming is uncommon in Python, and hence few methods return a call of the same or similar type.

I think that if you include built-in operators as (shorthand for) method calls, and you count the number of occurrences in typical Python programs rather than the number of distinct species, it's common.

I think this misses the point. Yes, the methods that implement operators are ALL "fluent" for Python numeric types. I can write: a + b * c / d % e ** f - g Subject to operator precedence, every one of those "method calls" represented by the symbols produces a new value of the same or similar type (sometimes we coerce up the numeric hierarchy). Of course if you were to write that out using a bunch of dunder methods, you'd get a "fluent programming" style. The dunders are very self-consciously different from "regular" methods. One of the biggest and clearest differences is that most/many dunders are specifically designed for fluent programming... but they are designed that way because the methods themselves are rarely used directly, but rather the mathematical symbols are instead.

The fact that methods are inconsistent about mutating in place versus returning a new object, and it's sometimes hard to guess from the name which will happen, is unfortunate but I don't think this proposal makes the problem any worse.

They are inconsistent, but not THAT inconsistent. Mutation of mutable collections almost always returns None. Almost everything that doesn't return None on a mutable object returns an aggregation or reduction of the collection, not a transformation. Yes, I can find exceptions, and so can you. But as a mental model, that comes pretty close. That is to say, in PYTHON. Yes, Pandas and some other libraries encourage a fluent style. But very little within Python itself does (except strings). Here are a few cases where the syntax would be useful for values other than

strings: named_tuple .= _replace(...)

In all the years I've used and taught namedtuples, I think I've never used the ._replace() method. The leading underscore is a hint that the method is "private" (that said, I've used the "private" ._asdict() fairly often).

pil_image .= crop(...)

Not Python, but an external library. Pillow doesn't really encourage a fluent style either, but most methods do return some sort of image, admittedly.

numpy_array .= transpose()

More often than not in NumPy (again, not Python itself), you will be led astray trying to do stuff like this. Yes, .transpose() works. On the other hand, why on earth would you ever not just spell that `numpy_array.T` which is so much easier?!

node .= get_{parent,left_child,right_child}()

I'm not sure if this is meant to refer to some particular library or a hypothetical. Yes, I can imagine this working with a recursive descent into a binary tree. But it's no big win. I'd be less likely to want to rebind the descent to the same name, but maybe.

mutable_thing_from_caller .= copy()

This will DEFINITELY fail code review. Why on earth would you replace a name with a copy of its initial object like that?! I'm sure there is SOME scenario where that would be desirable, but it's got to be unusual (and more likely a bug than an intent). If this feature were somehow to get into the language, yes I can imagine a few places where it would be usable. But I can imagine vastly more cases where it would be an attractive nuisance. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On Wed, Sep 30, 2020 at 7:30 PM Greg Ewing wrote:

On 1/10/20 4:25 pm, David Mertz wrote:

...

In all the years I've used and taught namedtuples, I think I've never used the ._replace() method. The leading underscore is a hint that the method is "private"

Usually that would be true, but namedtuple is a special case. The docs make it clear that the underscore is there to prevent it from clashing with a potential field name, not to suggest privateness.

OK, that's a good point. I kinda hadn't thought about that fact. But nonetheless, I haven't been shy to use ._asdict(), so I wasn't avoiding ._replace() out of concerns for a "private" declaration. It's just not a thing I've needed. Which makes me feel like having a way to spell it that is a few characters shorter is not an important life concern for me. :-) -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.