[Python-ideas] add fluent operator to everything

[Christopher Barker]

TL;DR:

When talking about all this, there are two distictions that should be
considered:

mutating operations vs copying operations

functions vs methods.

This has a lot of impact on the design, and it's very important that any
final syntax makes these distinctions clear.

On Wed, Feb 20, 2019 at 8:33 AM Dan Sommers <
2QdxY4RzWzUUiLuE at potatochowder.com> wrote:

> Python lists and dicts are classic objects.  I don't interact with the
> underlying data,

<snip>


> Python strings, however, don't work that way.  If I create one at the
> top of my application, I can pass it around, but my original remains as
> is.
>

It's a different way of doing things.  Please don't conflate them.
>

however, that's kind of what this thread is all about :-)

Python has two "kinds" of objects -- mutable and immutable.

Immutable objects necessarily return new objects when you call methods on
them (or do something else entirely)

This also makes them naturally easy to chain operations, as per the string
processing example(s).

However, mutating operations are not so easy to chain -- you can't write:

a_list.append(item).sort()[:10]

To, say, add a value to a list and get th first ten items in sorted order

I think the solution to THAT is to do as someone suggested, and to identify
the missing non-mutating operations. after all, we can, with lists, do:

sorted(a_list + [item])[:10]

but there are multiple issues with that:
1) a mixture of function calling and operators
2) that fact that "append an item and make a new list" isn't supported by
either a method or an operator, so we have to do a kludge to use +.

And I think a big one that inspires these ideas:

3) When nesting function calling, you write (and read) the code in the
reverse order that the operations take place:
    First you add the item to the list, then you sort it, then you slice it.
4) the "functional" form -- e.g. sorted() doesn't preserve type -- whether
you sort a list or a tuple, you get a list back.

So is the goal here to get  "fluent" syntax for stringing mutating
operations together that mutate the object?

If so, then that should be clearly different than string together
immutables. That is if I see:

that = this.a_method().another_method()

It should be really obvious whether or not "this" has been altered!
Right now, if the object in question follows python conventions, then it
has not been altered.

Personally, I think Python has enough ways to apply an operation, but maybe
in the spirit of functional programming's
idea that we shouldn't be mutating collections at all, we should extend the
mutable sequence ABC with methods that
return new objects:

list.sorted()
list.appended()
list.extended()
...

(slicing already copies). Then you could work with mutable and immutable
sequences similarly to how we do with strings:

first_ten = a_list.appended(item).sorted()[:10]

-CHB


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190220/f79ff30f/attachment-0001.html>