This allows me to write Python in a design-by-contract style with full, rich runtime type checks. My bug count has gone down dramatically, and when I do find a bug it's virtually always via a typecheck exception.
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 mostly like Python for its clean syntax but the examples contained in this PEP turn unreadable really fast. I don't look forward to this and I don't really see the point of it. I can see how it can be useful in theory but, in practice, I just see a symptom of language bloat.
The way I see it, if you find yourself in the situation where explicit type checking is important, there's probably something wrong with your process or team. Either your are not testing properly, or your team's mindset is more adjusted to another language.
The danger I see with this becoming widespread is Python becoming somewhat like C++ where it's very easy to come across code one can't easily read because it uses a different subset of features than you're used to. This sort of "language accents" so common in human languages is something that should be avoided in computer languages, IMHO.
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?
Nice. It really seems like static typing and functional programming are winning [1]. For the most part, I think that's very a good thing, and may help move the software industry forward.
> 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.
Interesting to me that they write "Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention."
Having no experience with using gradual typing, I wonder if there's any stable equilibrium here between "thoroughly dynamic" and "type declarations everywhere".
In any case, as someone who started with Python and started preferring static types later on, I really hope this gets used.
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.)
I like it, let the developer choose where typing is most appropriate. Also runtime type assertions really help with identifying bugs, especially NoneType issues.
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.
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.
[+] [-] bkeroack|10 years ago|reply
This allows me to write Python in a design-by-contract style with full, rich runtime type checks. My bug count has gone down dramatically, and when I do find a bug it's virtually always via a typecheck exception.
[+] [-] ak217|10 years ago|reply
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.
[+] [-] reeboo|10 years ago|reply
[+] [-] true_religion|10 years ago|reply
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.
[+] [-] drincruz|10 years ago|reply
[+] [-] CrLf|10 years ago|reply
The way I see it, if you find yourself in the situation where explicit type checking is important, there's probably something wrong with your process or team. Either your are not testing properly, or your team's mindset is more adjusted to another language.
The danger I see with this becoming widespread is Python becoming somewhat like C++ where it's very easy to come across code one can't easily read because it uses a different subset of features than you're used to. This sort of "language accents" so common in human languages is something that should be avoided in computer languages, IMHO.
[+] [-] jghn|10 years ago|reply
[+] [-] ilevkivskyi|10 years ago|reply
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" :-)
[+] [-] coldnebo|10 years ago|reply
[+] [-] ilevkivskyi|10 years ago|reply
[+] [-] brikis98|10 years ago|reply
[1] http://www.ybrikman.com/writing/2015/02/06/are-static-typing...
[+] [-] TazeTSchnitzel|10 years ago|reply
[+] [-] chimeracoder|10 years ago|reply
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.
[+] [-] gaius|10 years ago|reply
[+] [-] hyperpape|10 years ago|reply
Having no experience with using gradual typing, I wonder if there's any stable equilibrium here between "thoroughly dynamic" and "type declarations everywhere".
In any case, as someone who started with Python and started preferring static types later on, I really hope this gets used.
[+] [-] wcdolphin|10 years ago|reply
[+] [-] tveita|10 years ago|reply
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
[+] [-] pas|10 years ago|reply
[+] [-] Nemcue|10 years ago|reply
And if you don't want to create your own you could use https://pypi.python.org/pypi/obiwan
[+] [-] IshKebab|10 years ago|reply
[+] [-] rectangletangle|10 years ago|reply
[+] [-] dimino|10 years ago|reply
[+] [-] deckiedan|10 years ago|reply
Already, anyone seriously using pylint or other "normal" python linting tools uses comments like that to give extra hints to the linter:
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.[+] [-] ta0967|10 years ago|reply
[+] [-] Eleutheria|10 years ago|reply
I wish they kept separate ways. Python for simple and powerful hobbyist programs and nim for the enterprise.
If we have two languages doing the same thing, we will abandon one group of enthusiasts. Then another language will come to fill the gap.
[+] [-] monkmartinez|10 years ago|reply
[1] - https://www.paypal-engineering.com/2014/12/10/10-myths-of-en...
[+] [-] pekk|10 years ago|reply
[+] [-] Shizka|10 years ago|reply
As I mentioned it is already used in several big corporations. From your point of view - is it a problem right now?
[+] [-] Dewie3|10 years ago|reply
[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.
[+] [-] commentard|10 years ago|reply
[deleted]