Hacker News Reader

Comment by TomVDB | Hacker News Reader

I’m switching back from Ruby to Python out of necessity, and I loath things like len(my_list) vs my_list.len().

I just don’t understand why Python thinks it necessary to define global functions for something that naturally should exist as a method.

And, of course, there’s no way to know up front when to use a global function vs when to use a method.

View on HN

    len(my_list)

is just sugar for

    my_list.__len__()

if you feel strongly about the convention: https://docs.python.org/3/reference/datamodel.html#object.__...

It's not just sugar; it also does things like ensuring that the value is actually a nonnegative integer.

And for other unary "magic methods", the disconnect can be even bigger. E.g. iter(x) is not just a synonym for x.__iter__() - it can also produce an iterator for something that only provides __len__ and __getitem__.

This is, I think, largely a result of Python not idiomatically using mixins as much as Ruby (since it has multiple inheritance, it supports them, and they are sometimes used, but Ruby leans into them hard in the core.)

In the Ruby way, with otherwise similar setup, you would have a mixin that provided __iter__() given __len__() and __getitem__(), and classes that had the last two but wanted the behavior of the first would just include that mixin class as a parent, rather than having a separate branch in iter() to handle the different cases. (Ironically, its one way that Ruby is less TMTOWTDI than Python is.)

> In the Ruby way, with otherwise similar setup, you would have a mixin that provided __iter__() given __len__() and __getitem__(),

Python does have such a mixing, it's collections.abc.Sequence https://docs.python.org/3/library/collections.abc.html#colle...

+1 on the unpredictability being an issue. "Only one right way to do", yeah... gimme that least surprise :)

I understand why Python does it this way, but this is usually where someone points out Ruby doing:

  somestring=somearray.join(' ')

Versus Python's:

  somestring=' '.join(somearray)

I generally like Ruby better than Python, but Python's choice on _join_ being a string method on the thing stuck between elements rather than an collection method on the things whose elements are getting something stuck between is better.

Why do you think it's better?

I don't use either Ruby or Python but I think that the first way is more natural.

Interesting. I model `array.join(',')` or the equivalent Py `','.join(l)` in my head as ultimately (pseudo-code):

    foldLeft(tail(array), str(head(elem)), (acc: String, elem: T) -> acc + ',' + str(elem))

Which makes the array method easier to understand than the string method. Funny how I thought it was _obvious_, but you find the opposite obvious.

Why? somearray is the important piece, the string is just a bit of spacing. Put the important thing first, don’t bury the lede.

    print('Hello '.join('world!'))

After years of Python I can't remember which one of these are correct

  1 ",".join(["a", "b"])
  2 ["a", "b"].join(",")
  3 ",".split("a,b")
  4 "a,b".split(",")

These method names feel like active form so 1 and 3 should be correct but it's 1 and 4 despite "a,b" obviously is not splitting "," but it's splitted by it

In Ruby it's 2 and 4.

I'm out of luck twice but at least Ruby has a and b always to the left and the comma always to the right so I always remember it.

Reply on news.ycombinator.com