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