News for hackers. Stuff that matters.
Re:Rails is not written in Ruby by matheusmoreira on Friday February 04, 2022 @05:32PM (#30214318)
In Ruby, anything that can be sorted will respond to sort. So thing.sort will also sort anything that can be sorted.

Python does the exact same thing, it just hides it from you using ugly __methods__ that the language itself will call by convention. What determines sortability? "Anything that can be sorted" just means anything that implements the __lt__ method. In Ruby, this method is called <=> and the Comparable module builds upon it.

Re:Rails is not written in Ruby by remram on Friday February 04, 2022 @05:51PM (#30214564)
Nothing like sort is hidden in class methods in Python.
Re:Rails is not written in Ruby by johnmaguire on Friday February 04, 2022 @05:55PM (#30214620)
That's not true - Python implements sorted by calling `__lt__` on the object: https://docs.python.org/3/library/functions.html#sorted
Re:Rails is not written in Ruby by int_19h on Friday February 04, 2022 @06:37PM (#30215097)
__lt__ is just the way to overload the comparison operator, which of course is going to be called by the sort. What OP is saying is that there's no __sort__ or anything like that.
Re:Rails is not written in Ruby by johnmaguire on Friday February 04, 2022 @07:43PM (#30215738)
But that's not really true either - there's __len__ which len() calls: https://docs.python.org/3/reference/datamodel.html#object.__...

You can add iterators with __iter__, reversed() calls __reversed__, etc.

Re:Rails is not written in Ruby by dwaite on Friday February 04, 2022 @08:09PM (#30215940)
Sorted mandates the type you give it implements __iter__, aka that it is iterable. Ruby defines sort as a method on Enumerable.

The difference is that most likely that CPython and CRuby started with different capabilities to map native implementations into the language.

The biggest difference between the two is python adds more functions into the global namespace, while Ruby pushes pretty hard to encapsulate logic within types.

Re:Rails is not written in Ruby by remram on Saturday February 05, 2022 @02:41PM (#30225028)
The discussion is about how to provide additional functionality.

To be sortable, you collection has to be a collection, and it has to have comparable elements. That has to be provided by the type itself.

The difference between Python and Ruby is how to add more functions. If you make a library to sort collections (or format phone numbers), the Ruby way is to monkey-patch collections (or numbers). Whereas the Python way is to offer a free function that takes an iterable (or number). This is what we are discussing.

Of course Python classes have methods.

Re:Rails is not written in Ruby by matheusmoreira on Friday February 04, 2022 @06:02PM (#30214712)
No, pretty much everything in the language is hidden from you behind methods. This hidden magic is in many cases literally baked into the language's syntax.

Iterables use functions like __len__ and __next__. The with keyword is just a thing that implicitly calls __enter__ and __exit__ on a context management object.

Re:Rails is not written in Ruby by remram on Saturday February 05, 2022 @02:16PM (#30224735)
Yes, sorted() will use methods like __iter__ and __lt__ provided by the object. But sorting is not provided by the object and is therefore not (quoting GP) "the exact same thing, just hidden from you in an ugly __method__".
Re:Rails is not written in Ruby by dragonwriter on Friday February 04, 2022 @06:48PM (#30215195)
> Nothing like sort is hidden in class methods in Python.

The discussion has mostly been about instance methods defined in classes, and how do you define “like sort” in this claim?

list.sort() is a method in Python; it's the equivalent of Array#sort! in Ruby.

Re:Rails is not written in Ruby by remram on Saturday February 05, 2022 @02:30PM (#30224894)
There is nothing that sorts hidden in dunder methods on objects, even if they can be sorted. `sorted()` will use intrinsic methods like `__iter__` and `__lt__` to sort a collection, but the op is claiming that even though the syntax is different (`sorted(obj)` rather than `obj.sort!`), it's "the exact same thing, it just hides it from you using ugly __methods__".

To that I reply that no, there is no method to sort hidden in __methods__. This is not how functionality is added to classes in Python. If you want to add something that works on all iterables, you don't insert new methods in iterable classes, like you do in Ruby. That free-standing sorted() function really is a free-standing function, it is not actually a method "hidden in ugly __methods__".

Re:Rails is not written in Ruby by dragonwriter on Saturday February 05, 2022 @08:54PM (#30228483)
> If you want to add something that works on all iterables, you don't insert new methods in iterable classes, like you do in Ruby.

You don't in Ruby, either.

If you want something that works on all Enumerables, you normally write an (instance or class/module) method on some other class or module that takes an argument that supports the methods provided by the Enumerable API.

(In Python, you might do this or write a bare function, but Ruby doesn't have bare functions; it's possible to make proc objects in a library which is the nearest equivalent, but you’d almost never do that, because module methods are much more convenient.)

In either Python or Ruby you might also monkey-patch existing classes to add functionality to the., and this is slightly more common in Ruby than Python, but because Python iterable, unlike Ruby Enumerables, don't have a common superclass that isn't shared with non-iterables, you couldn't easily do a “for all iterables” thing in Python [0] by monkey-patching because you don't have a good target to monkey-patch, whereas in Ruby you might do something for (nearly, because duck typing is a thing and it's possible someone could build an enumerable by implementing the whole API without mixing in the module) all enumerables, not by adding methods directly to individual enumerable classes, but by monkey-patching the Enumerable module itself.

The main difference here is that Python (despite having support for mixins because it uses multiple inheritance) tends in it's core to use a mix of OO public APIs and procedural public APIs built on top of OO protocols using (often dunder) methods, rather than either consistently-OO or consistently procedural APIs, whereas Ruby is consistently OO and uses mixins to provide shared functionality building on a narrower protocol where Python would use a suite of functions. (Python tends to be more OO in its stdlib and third party libs than in its core, except specifically when supporting protocols defined in the core and consumed through built-in functions.)

[0] except by monkey-patching object with code that tries to use the dunder methods that underlie the iteration protocol and fails if they don't exist, but while theoretically possible I don't think anyone would do that.

Re:Rails is not written in Ruby by remram on Sunday February 06, 2022 @04:14PM (#30237065)
The Python ecosystem does not monkey-patch, and in fact a lot of built-in classes do not support it.

Your point about Ruby syntax not really being meant for free functions is well-taken though.