4 ms·
the problem is not type hinting. the problem is people trying to use a single function for any type. as can be seen in the article, that is extremely difficult
by 2h 4y ago
the problem is not type hinting. the problem is people trying to use a single function for any type. as can be seen in the article, that is extremely difficult and error prone. so just dont do that:
def slow_add(a: int, b: int) -> int:
def slow_add_float(a: float, b: float) -> float:
OK its not as elegant or pretty, but its really clear what is going on. the problems described in the article crop up because people are trying to have the interpreter intuit what the programmer is wanting, when what the programmer is wanting might be ill defined or simply invalid.
- mjburgess 4y agoSo because the type system is far far far far less polymorphic than the underlying code, we're to monomorphize the code manually? Angry rant: maybe mypy (and its PEPs) can be designed well? Maybe tacking java on top of python was a terrible idea, and python is much better than this awful type system. cf. the syntactical catastrophe that is "protocols". Consider that to type `+` correctly, you're writing >dozen lines of python. This is mad, and the type system shouldnt have been designed by people this inexperienced with type systems.
- deleted 4y ago[deleted]
- zeckalpha 4y agoWait until you use math in OCaML.
- JonChesterfield 4y agoPython always had a type system. It's not checked ahead of time but it's there. You can do things like return different types based on values read from a text file at runtime, that is it's a dependent type system. Python is not a total language - no termination proof of given functions to be found. It's also not pure, the calculation that picked a type can pick a different one next time it runs on the same arguments. A dependent type system in a pure language with no user provided termination proof is in the ballpark of academia hasn't made it work yet. Python's dynamic type system _cannot_ be checked at compile time, however much care goes into the design. What can be done is cripple python to some subset that can be statically typed, combining the elegance of java with the performance of python, with some end goal that doesn't make any sense to me.
- zeckalpha 4y agoThis definition of dependent type system is a bit controversial. There was a conflict between Julia language maintainers and FP researchers a few years back.
- JonChesterfield 4y agoWell, sort of. There's the (dominant?) school of thought that believes that types encode a program that runs before your actual program runs (and may thus be deleted at some point). This is often characterized by writing the type in a more awkward language than the usual one, C++'s separate languages for example. Dependent Type Theory is quite strongly associated with the compiletime/runtime phase separation assumption, where the weirdness is that values from the runtime world leak into the compiletime one. This is magic in the static/AoT type world and trivial in the dynamic/JIT one. So, strictly you're right, python is not dependently typed, as that term is owned by a different branch. However if you were to put an ahead of time type system on arbitrary python, that would need to be dependently typed to be able to describe the programs people write in python today. It would also be prone to failing to terminate during type checking.
- mjburgess 4y agoJust make types functions which are executed at compile time: @type def Monoid(T: type): return {'+': type[T, T].to(T) } def add(left: Monoid(int), right: Monoid(int)): Monoid(int) return left + right ...if it takes too long to compile, terminate and report an error. As for this kind of dependence, that seems straightforward: @type def Dependent(): return {0: int, 1: str, "Hello": bool} def rtn_dependent(x: Dependent().keys): Dependent().values if x == 0: return x elif x == 1: return "message" else: return x == "Hello"
- JonChesterfield 4y agoNot actually sufficient though, you'll need: def slow_add_int_float(a: int, b: float) -> float: # etc where an argument could be made for encoding the return type in the name as well, at least for functions that don't do addition. What that has going for it is the warm familiarity of C99. People really like function (and sometimes operator, if they draw a distinction) overloading though, and can reasonably argue that writing template instantiations by hand is a poor use of their time.
- 2h 4y agoyou should never be adding an int to a float. You should be casting one first.
- Taurenking 4y ago[dead]