3

I've recently used typescript, and I think the ability to mention or not types is great. It greatly reduces the debugging time while also giving you the advantages of an untyped language. I could imagine a python language superset with the same functionalities, I'm sure the type specifications could be used to greatly speed up the runtime while reducing the debugging hustle. What do you think?

4

I don't know whether TypeScript enforces type constraints at compile or run time. But Python does support type hints.

Python 3.0 introduced function annotations as defined in PEP 3107. They work like this:

def log_in(login: 'Login', password: 'Password') -> 'Return value':
    # ...

log_in.func_annotation['login'] # => 'Login'
log_in.func_annotation['password'] # => 'Password'
log_in.func_annotation['return'] # => 'Return value'

You can annotate the parameters and the return value with any object.

This can be used to implement type hints. Python 3.5 introduces the typing module. You can implement a decorator that'd perform run-time type checking.

0

I'm sure the type specifications could be used to greatly speed up the runtime […]

No, they can't. The definition of an optional type system is that it does not impact the runtime behavior in any way. That's what makes it "optional" in the first place. If adding or removing types made the program change its behavior, the types wouldn't be optional.

Note also that you don't need to change Python in any way to typecheck it. You could just write your type annotations in comments, after all. What you do need is of course a type system with typing rules. Then, you need to prove this type system correct and sound (if you are interested in soundness, which, let's face it, you are, otherwise you wouldn't be interested in a type system to begin with). Then you need to write a typechecker for this typesystem. And once you have done that, and proven its worth, then you can talk about adding your type system to the language itself, and also adding type annotation syntax.

[Note that, at least for function parameters and return values, there already does exist support for type annotation syntax.]

This is already very hard. But it's not even the interesting part: you have now created a new, statically-typed language. But, you cannot expect everyone to statically type their Python code all at once. (Remember how long the transition to Python3 took … ehm … is still taking?) What you really want is a way to gradually migrate to static typing, or have parts of your code statically typed and parts dynamically.

One way to solve this problem, would be to find a type inference scheme which can automatically infer the correct static types from the program, so that you don't have to rely on legacy Python code to be annotated. Now, typechecking Python without violating its idioms is already going to be hard enough with the help of static type annotations, just imagine how hard it is going to be without!

So, the other way is what is called "gradual typing", a way to mix statically type-safe and dynamically typed code in such a way that

  • they can interoperate seamlessly,
  • the dynamically typed code cannot violate the type-safety of the statically type-safe code, and
  • dynamically typed code can be gradually migrated to statically type-safe code through gradually adding annotations.

There is a lot of research into gradual typing, and in fact, a lot of the original research has been (and is being done) in and on Python, and a research implementation of gradual typing for typing in Jython has existed for quite a while.

You should give it some time. There is still debate over whether gradual typing or optional typing (or the route the Racket community took with their alternative take on gradual typing called soft typing), a combination of the two (and there are again different ideas on what such a combination would look like), or something entirely different is the way to go. Gradual typing is still an actively evolving research subject.

Besides Jeremy Siek's gradual typing in Jython there was also a research project for a statically typed and type-inferred Ruby (Diamondback Ruby), and there was ECMAScript4. There is Typed Racket (and clojure.typed, wich is based on the former). We had the optional Strongtalk typesystem for Smalltalk. But we still haven't figured it all out.

tl;dr:

Why python doesn't provide optional types?

Because nobody has done the work yet.

  • 1
    Python 3.5 has the typing module which adds support for type variables, generics, and a suggested way to use the function annotations. Mypy-lang is an existing type checker that uses these annotations. I've used it a bit and while it's not as good as a built-in type system (it doesn't guarantee type safety), I've come to rely on it as a kind of linter. – amon Jun 24 '16 at 18:59
  • Nitpick: python supports arbitrary annotations on functions as long as it's a single object, not just type annotations. This is a sticking point because limiting annotations to only this one use would break backwards compatibility. See the PEP – Joel Harmon Jun 25 '16 at 1:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.