On Sun, Nov 28, 2021 at 3:06 AM Stephen J. Turnbull < stephenjturnbull@gmail.com> wrote:
Chris Angelico writes:
The policy of not returning self is, from my understanding, to clarify which methods return a new thing and which mutate the existing one
yup.
Which is what I would expect for a *sort* *method*. But I guess others might not think about it and be unpleasantly surprised.
Lists could have both a sort() (sort in place) and sorted() (return a new list) method -i fact, I have done exactly that in some of my code (well, not sort, but the same idea, one method to mutate, one to return a new copy) I would like that, and it would be great to support a fluent interface in that way. WHo among us has not chained string methods together? a_str.strip().upper(). ... However, we are kind of stuck because we have a current interface to both the built ins and the ABCs that we don't want to break. And it's been Python's philosophy from the beginning to get generalized behavior from functions, not methods (e.g. len() ) -- so we have a sorted() function, but not a sorted() method on the Sequence protocol. Hmm -- I jsut had a whacky idea: As pointed out, adding a bunch of chaining methods to the Iterator ABC isn't really helpful, as it would A) potentially break / override existing classes that happen to use teh same names, and B) not provide anything for Iterators that don't subclass from the ABC. But we *could* define a new ChainedIterator ABC. Anyone could then subclass from it to get the chaining behavior, and we could (potentially) use it for many of the iterators in the stdlib. I'm not sure I'd even support this, but it's an idea. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython