[Python-ideas] Method chaining notation

[spir]

On 02/21/2014 11:43 PM, Masklinn wrote:
> On 2014-02-21, at 23:00 , spir <denis.spir at gmail.com> wrote:
>> Also, I don't find the idea of having a builtin construct for such hacks a good idea. Libs for which this may be practicle can return self --end of the story.
>
> That has two issues though:
>
> 1. it makes chainability a decision of the library author, the library
>     user gets to have no preference. This means e.g. you can't create
>     a tree of elements in ElementTree in a single expression (AFAIK
>     Element does not take children parameters). With cascading, the
>     user can "chain" a library whose author did not choose to support
>     chaining (in fact with cascading no author would ever need to
>     support chaining again).

I agree with you, here...

> 2. where a return value can make sense (and be useful) the author
>     *must* make a choice. No way to chain `dict.pop()` since it
>     returns the popped value, even if `pop` was only used for its
>     removal-with-shut-up properties. With cascading the user can
>     have his cake and eat it: he gets the return value if he
>     wants it, and can keep "chaining" if he does not care.

... not there (if I understand you well; not quite 100% sure). In fact, I find 
this point rather a counter-argument, something to avoid (again, if I 
understand). What I mean is that executing given methods should have consistent 
effect; also, you should use the right method for the right task: if you don't 
want a stack's top item _and_ have it removed, then don't use 'pop', otherwise 
you are misleading readers (including yourself maybe, later) (note 'pop' is just 
a convenience utility for this very case; we could just read and remove in 2 steps).

d