4 ms·

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 ne

• dfinninger 5y ago
  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.__len__ https://docs.python.org/3/reference/datamodel.html#object.__...
  • int_19h 5y ago
    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__.
    • dragonwriter 5y ago
      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.)
      • progval 5y ago
        > 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#collections-abstract-base-classes https://docs.python.org/3/library/collections.abc.html#colle...
• RangerScience 5y ago
  +1 on the unpredictability being an issue. "Only one right way to do", yeah... gimme that least surprise :)
• tyingq 5y ago
  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)
  • dragonwriter 5y ago
    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.
    • renox 5y ago
      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.
    • renewiltord 5y ago
      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.
    • mcphage 5y ago
      Why? somearray is the important piece, the string is just a bit of spacing. Put the important thing first, don’t bury the lede.
  • tedunangst 5y ago
    print('Hello '.join('world!'))
  • pmontra 5y ago
    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.