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
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
