4 ms·

It is, but it has a lot harder time deciding what type of object I'm working with in a function vs. being able to specify the object's class in the function arg

It is, but it has a lot harder time deciding what type of object I'm working with in a function vs. being able to specify the object's class in the function arguments. You can get that with docstrings but it's not as straightforward as just saying "def frobozinator(FooBar thing):"

pekk 10y ago
Either it's your code, in which case why don't you know what type of object you are passing, or it's a documented part of a framework or something. With polymorphism and inheritance in the mainstream languages, the method signature still doesn't exactly tell you what you are going to get, so you have all of the pain of micromanaging type annotations and you still don't really get an invariant. Also, Python has function annotations if your purpose is to document the signature without using docstrings. I'm unsure why you don't mention these because they are exactly analogous to what you say is straightforward.
- Programmatic 10y ago
  Knowing in my head and having it tab out are two different things. Interfaces will without a doubt tell you what you can do with a given object. With polymorphism you most assuredly know what types the arguments are inside each signature you write. Function annotations look like shit[0] and are not guaranteed to mean the same thing across projects. Don't get me wrong, I love Python and its idioms and have been using it for a rather long time. It pays the bills and I am productive in it. I just think that I've outgrown its implicit typing when I step into an explicitly typed language using modern tools and enjoy myself. [0]: https://www.python.org/dev/peps/pep-3107/#syntax https://www.python.org/dev/peps/pep-3107/#syntax
- jdmichal 10y ago
  > With polymorphism and inheritance in the mainstream languages, the method signature still doesn't exactly tell you what you are going to get, so you have all of the pain of micromanaging type annotations and you still don't really get an invariant. This is exactly what is addressed by the Liskov substitution principle [0] -- the "L" in SOLID [1]. If your subtype does not have the same semantics as the type it extends, then it fails this criteria. It is violating the (implicit) contract of the type it is extending. [0] https://en.wikipedia.org/wiki/Liskov_substitution_principle https://en.wikipedia.org/wiki/Liskov_substitution_principle [1] https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 https://en.wikipedia.org/wiki/SOLID_%28object-oriented_desig...

pekk 10y ago

Either it's your code, in which case why don't you know what type of object you are passing, or it's a documented part of a framework or something. With polymorphism and inheritance in the mainstream languages, the method signature still doesn't exactly tell you what you are going to get, so you have all of the pain of micromanaging type annotations and you still don't really get an invariant. Also, Python has function annotations if your purpose is to document the signature without using docstrings. I'm unsure why you don't mention these because they are exactly analogous to what you say is straightforward.

Programmatic 10y ago
Knowing in my head and having it tab out are two different things. Interfaces will without a doubt tell you what you can do with a given object. With polymorphism you most assuredly know what types the arguments are inside each signature you write. Function annotations look like shit[0] and are not guaranteed to mean the same thing across projects. Don't get me wrong, I love Python and its idioms and have been using it for a rather long time. It pays the bills and I am productive in it. I just think that I've outgrown its implicit typing when I step into an explicitly typed language using modern tools and enjoy myself. [0]: https://www.python.org/dev/peps/pep-3107/#syntax https://www.python.org/dev/peps/pep-3107/#syntax
jdmichal 10y ago
> With polymorphism and inheritance in the mainstream languages, the method signature still doesn't exactly tell you what you are going to get, so you have all of the pain of micromanaging type annotations and you still don't really get an invariant. This is exactly what is addressed by the Liskov substitution principle [0] -- the "L" in SOLID [1]. If your subtype does not have the same semantics as the type it extends, then it fails this criteria. It is violating the (implicit) contract of the type it is extending. [0] https://en.wikipedia.org/wiki/Liskov_substitution_principle https://en.wikipedia.org/wiki/Liskov_substitution_principle [1] https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 https://en.wikipedia.org/wiki/SOLID_%28object-oriented_desig...