new | ask | show | jobs
mjr00 2 days ago  [ - ]

> This is a strange and aggressive bit of pedantry.

There's nothing pedantic about it. That's how Python works, and getting into the nuts and bolts of how Python works is precisely why the linked article makes type hinting appear so difficult.

> The entire point is that we have an intuition about what can be "added", but can't express it in the type system in any meaningful way.

As the post explores, your intuition is also incorrect. For example, as the author discovers in the process, addition via __add__/__radd__ is not addition in the algebraic field sense. There is no guarantee that adding types T + T will yield a T. Or that both operands are of the same type at all, as would be the case with "adding" a string and int. Or that A + B == B + A. We can't rely on intuition for type systems.

zahlman a day ago  [ - ]

> your intuition is also incorrect.

No, it definitionally isn't. The entire point is that `+` is being used to represent operations where `+` makes intuitive sense. When language designers are revisiting the decision to use the `+` symbol to represent string concatenation, how many of them are thinking about algebraic fields, seriously?

And all of this is exactly why you can't just say that it's universally bad API design to "accept all types". Because the alternative may entail rejecting types for no good reason. Again, dynamically typed languages exist for a reason and have persisted for a reason (and Python in particular has claimed the market share it has for a reason) and are not just some strictly inferior thing.

pdonis a day ago  [ - ]

> you can't just say that it's universally bad API design to "accept all types"

Note, though, that that's not really the API design choice that's at stake here. Python will still throw an exception at runtime if you use the + operator between objects that don't support being added together. So the API design choice is between that error showing up as a runtime exception, vs. showing up as flagged by the type checker prior to runtime.

Or, to put it another way, the API design choice is whether or not to insist that your language provide explicit type definitions (or at least a way to express them) for every single interface it supports, even implicit ones like the + operator, and even given that user code can redefine such interfaces using magic methods. Python's API design choice is to not care, even with its type hinting system--i.e., to accept that there will be interface definitions that simply can't be captured using the type hinting system. I personally am fine with that choice, but it is a design choice that language users should be aware of.

mjr00 19 hours ago  [ - ]

> No, it definitionally isn't. The entire point is that `+` is being used to represent operations where `+` makes intuitive sense.

Huh? There's no restriction in Python's type system that says `+` has to "make sense".

  import requests

  class Smoothie:
      def __init__(self, fruits):
          self.fruits = fruits

      def __repr__(self):
          return " and ".join(self.fruits) + " smoothie"

  class Fruit:
      def __init__(self, name):
          self._name = name

      def __add__(self, other):
          if isinstance(other, Fruit):
              return Smoothie([self._name, other._name])
          return requests.get("https://google.com")

  if __name__ == "__main__":
      print(Fruit("banana") + Fruit("mango"))
      print(Fruit("banana") + 123)
> banana and mango smoothie

> <Response [200]>

So we have Fruit + Fruit = Smoothie. Overly cute, but sensible from a CS101 OOP definition and potentially code someone might encounter in the real world, and demonstrates how not all T + T -> T. And we have Fruit + number = requests.Response. Complete nonsense, but totally valid in Python. If you're writing a generic method `slow_add` that needs to support `a + b` for any two types -- yes, you have to support this nonsense.