[Python-ideas] add fluent operator to everything

[Jimmy Girardet]

Hi,

thank for the replies.

I searched on python-idea as Chris proposed me with "chain" and I've
found 2 relevant discussions :

* A  proposal from Cris Angelico ;-)
https://mail.python.org/pipermail/python-ideas/2014-February/026079.html

"""Right. That's the main point behind this: it gives the *caller* the
choice of whether to chain or not. That's really the whole benefit,
right there.""" ChrisA


the killer  answer of Nick Coghlan
https://mail.python.org/pipermail/python-ideas/2014-February/026158.html
explaining that the main point is about mutating and transforming : this
is a part of Nick's answer :

> start piece of answer Compare:

    seq = get_data()
    seq.sort()

    seq = sorted(get_data())

Now, compare that with the proposed syntax as applied to the first
operation:

    seq = []->extend(get_data())->sort()

That *looks* like it should be a data transformation pipeline, but
it's not - each step in the chain is mutating the original object,
rather than creating a new one. That's a critical *problem* with the
idea, not a desirable feature.
> end of answer

It seems that in 2014 Guido was against chaining method.


* Then in 2017 :
https://mail.python.org/pipermail/python-ideas/2017-August/046770.html

quite the same thing with a "rcompose" idea.


So i understand that in this and previous discussions,  the main
argument against it  was that mutation should looks like mutation  and
not transformation (which returns value).

This seems like a strong thing in core-dev mind since it's about design
of the language.

I totally agree with this idea of "mutating does not "return  value" but
as a "user" of the language I easily can deal with the 2 ideas of
"mutating does not return value" and "lets chain those things". I think
you can do the last without breaking the first.


"Although practicality beats purity"

a : object::mutable1()::mutable2()::mutable3()::mutable4()

b : multligne sequence

mutable1(object)

mutable2(object)

mutable3(object)

mutable4(object)




Pros for a:

    - stands in one line without loosing clarity.

    - user are now used to play with "fluent" syntax in many libs or
languages.

Cons for a:

    - b was here before :-) and fits the idioms of the language.

    - a may look like you're using some `return Value` on mutating
operation. I read somewhere that we are adult enough to be careful of
what we are doing so, this cons is not obvious to me.

At the very beginning of my thoughts I (maybe naively) thought that "a"
could easily be converted to "b" at compile time but I'm not aware of
those internal things.
 

Le 20/02/2019 à 04:10, Stephen J. Turnbull a écrit :
> In most cases, where one doesn't care about performance, one can rewrite
> as
>
>     max(a := sorted([1, 2, 3] + [4])) + 1
Indeed, but at first glance, it's not obvious where  it starts and where
it stops.

[1,2,3].append(4)::List.sort()::max() +1  

gives you a sequential way of reading things like you talk or speak in
every day life.

> I think given the current design with its long history, it would be
> more useful to identify pain points where functions like sorted()
> don't exist.
You're right on it. The str class is a  straightforward swiss army knife
with methods you can chain. list or dict do not fit this idea.

Jimmy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190220/205e22aa/attachment.html>