Hi Remy, On Mon, Nov 22, 2021 at 02:15:08PM -0000, Remy wrote:
Hi, I'd like to revive this thread after what seemed like a decade and see where this might take us 😃
Reviving old threads from a decade ago is fine, if something has changed. Otherwise we're likely to just going to repeat the same things that were said a decade ago. Has anything changed in that time? If not, then your only hope is that people's sense of what is Pythonic code has changed. Python is a purely object-oriented language that does not enforce, or even prefer, object-oriented syntax. We prefer procedural syntax (functions) in many cases, especially for protocols. What I mean by this is: - all values in Python are objects; there are no "unboxed" or machine values; - but we don't force everything to use "object.method" syntax when functions are better. We even have a FAQ for why Python is designed this way: https://docs.python.org/3/faq/design.html#why-does-python-use-methods-for-so... You might also get some insight from a classic critique of Java: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html Note that, *technically*, Python is a "kingdom of nouns" language too. Everything we have, including functions and methods and even classes, is an object. But you will rarely see a `ThingDoer.do` method when a `do` function is sufficient. You want to write: mylist.iter() But that's just a different spelling of: iter(mylist) Instead of: any_iterable.to_list() just write: list(any_iterable) `list` already knows how to iterate over any object which provides either of the two iterable protocols: - the iterator protocol; - or the sequence protocol; so your classes just need to implement one protocol or the other, and they will *automatically and for free* get the functional equivalent of all of your methods: - to_list, to_tuple, to_set, to_frozenset, iter, map, reduce, filter... without any extra work, or bloating your class' namespace and documentation with dozens or hundreds or thousands of methods that you don't use. And most importantly, since you cannot possibly anticipate every possible container class and functional process, you don't have to worry about all the methods you left out: - mapreduce, union, product, to_deque ... Since you cannot provide a dot-method for every possible function your consumers may want, you are never going to eliminate procedural syntax: # Why is there no to_rainbox_forest method??? obj = rainbox_forest(obj) so you might as well embrace it and stop fighting it. Protocol-based functions are better than methods. Any function that operates on an iterable object will automatically Just Work. -- Steve