PEP 0484 – Type Hints is accepted (opens in new tab)

Thanks for the link. I developed the annotation+decorator-based type checker in https://github.com/kislyuk/ensure before I saw typecheck-decorator (which looks like it has some cool features). One thing I'm proud of with ensure's @ensure_annotations decorator is that we actually went through a few rounds of optimization and are fairly confident in the decorator's runtime performance.

Optional type checking as a first-class citizen is a great tool to have, and it's good to see the syntax standardized.

But as alluded to in the Reddit thread, there are serious issues with this PEP. The use of comments and the lack of runtime type checking from the start not only limits the potential of this particular PEP, but undermines future efforts to bring that functionality in.

IMO it would have been better to put in the work and properly integrate type checking decorations into the interpreter and the grammar. The tack-on comments at the end of the line are especially un-Pythonic and jarring.

Edit: Just saw the string literal based forward references. Ugh. Another problem in the making.

Yeah, isn't that amazing? I really think this "type" idea is a good one. I wonder if other languages have thought about following Python's lead and adding a type system.

This might sound odd, but lately I haven't noticed any bugs I've introduced to production that were type errors.

Inevitably my code will produce results of the right type, but have a logical error that makes either the answer flat out wrong or more or less inaccurate based on our cloud requirements.

I can see this being very useful. Runtime type checking, a contract for code to follow; all should help out with better code quality.

One could argue that you'd need many fewer lines of test code if your compiler can prove a lot of stuff is correct at compile time. It's a personal preference thing but I prefer this situation and don't view it as having poor testing

From the acceptance letter: """ if you are worried that this will make Python ugly and turn it into some sort of inferior Java, then I share you concerns, but I would like to remind you of another potential ugliness; operator overloading.

C++, Perl and Haskell have operator overloading and it gets abused something rotten to produce "concise" (a.k.a. line noise) code. Python also has operator overloading and it is used sensibly, as it should be. Why? It's a cultural issue; readability matters.

Python is your language, please use type-hints responsibly :) """ I would add metaclasses, generators, etc. all these are already enough to write horrible things. It is indeed all about "culture", readability is really the cornerstone of Python culture. Type hints when used responsibly are fantastic tool. You could be surprised but they really improve readability, it's like a succinct docstring. I discovered this while recently reading through one large codebase. Moreover, typechecker will tell you when your "docs" do not reflect actual semantics. Finally, I would like to point out that typing.py and Mypy are pure Python, no magic :-) At the same time "import typing" is very in the spirit of "import antigravity". I hope Python gradual typing could become alternative to Java/C++/etc. BDSM-style typing and one day we could say: "Come join us! Typing is fun again" :-)

It seems more like Scala syntax, which is much cleaner than C++ IMHO. But with Java becoming dynamic (and C++ techniques for same), is the future a smear of shared language features, like Bladerunner's cityspeak, or are these just intermediate forms as a new protolanguage capable of unifying these features comes into existence?

> So now two popular dynamic languages have type hinting of a kind: Python (unenforced annotations) and PHP (declarations). Great!

Don't forget Javascript, via Typescript (which predates both Python and PHP's typechecking): http://www.typescriptlang.org/

Typescript is a strict superset of Javascript that compiles very transparently to the equivalent Javascript, so I think it's close enough to what Python3 does to be included here.

The annotations are stripped out before runtime, but they are checked at compile-time for any errors that are possible to detect statically.

I encourage all use of the type system to ensure program correctness, but once you've had Hindley-Milner inference, it's hard to muddle along with something like this.

Pretty sure Python is very "enterprise"[1] worthy.

[1] - https://www.paypal-engineering.com/2014/12/10/10-myths-of-en...

Since when was Nim more for the enterprise than Python?

I see your point in hobbyist vs. enterprise, but Python is already used in multiple big corporations and I don't think I have seen any result of it being a problem. If anything, the language gets more and more attention due to its spreading popularity on all levels. Isn't that just for the good of the language?

As I mentioned it is already used in several big corporations. From your point of view - is it a problem right now?

Nim the language[1] will probably still win with regards to mechanical sympathy. And perhaps also metaprogramming?

[1] As opposed to implementations... because I don't know what kind of crazy compiler (JIT or AOT) they do nowadays to make "slow" languages fast. So for all I know Python can still be fast, given enough manpower.

Simple function annotations like

  def foo(x: int) -> str: ...

have been available since 3.0, and editors like PyCharm already use them for typechecking.

For new PEP 0484 features like generics, MyPy supports Python 3.2 and up, but PyCharm support seems to be work in progress: https://youtrack.jetbrains.com/issue/PY-15206

https://github.com/JukkaL/mypy is the/one implementation of a static checker that conforms to PEP 484. (Naturally, as far as I know, JukkaL with mypy almost singlehandedly inspired the PEP.)

You can use it today if you want to, there is already language support for adding your own type notation.

And if you don't want to create your own you could use https://pypi.python.org/pypi/obiwan

I guess this will be in Python 3, so probably never! :P

Not quite. The PEP is (to me) quite explicit that the typing is never mandatory. So a comment-hint will never change the way the code actually runs, nor will lack of a comment or an unintentional comment cause a program to act strangely.

Already, anyone seriously using pylint or other "normal" python linting tools uses comments like that to give extra hints to the linter:

    def blah(): # pylint: ignoresomething

type of thing. Yes, it's a bit weird, and yes, it does teeter right on the edge of the comments as syntactic value precipice, but I think lands just on the alright side.

the `type: x` comments substitute explicit syntax in places where i'd want type inference, so it's no big deal.