
PEP 0484 – Type Hints is accepted - ilevkivskyi
https://www.python.org/dev/peps/pep-0484/
======
bkeroack
One of the reasons why I use Python 3.x exclusively is for the new function
annotations, which allow use of this: [https://github.com/prechelt/typecheck-
decorator](https://github.com/prechelt/typecheck-decorator)

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.

~~~
reeboo
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.

~~~
rattray
Would you like to reconsider your tone?

~~~
reeboo
No, but let me clarify. Bolting on a form of type checking to a weakly typed
language seems orthogonal to the nature of a language like Python. If you find
yourself saying "I wish I had a type system in this code base, its getting
pretty big and a compiler that does type checking at compile time sure would
make my life easier" maybe you should think about using a more appropriate
tool.

I use Python a lot and it has its uses, but adding this type hint stuff just
seems like an enabler for causing myself pain and denial when I _should_ be
using a more strongly typed language.

~~~
dangirsh
Though I agree with your sentiment, I must mention that there is nothing
"weak" about Python's type system.

You likely meant "dynamic", not "weak". See here:

wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language

~~~
aapycgarb
Python's type system is weak whether they self-identify that way or not. Types
are implicitly converted in a variety of cases, notably True-ness. Meanwhile,
runtime type identity is kind of meaningless; classes and individual objects
can have their behavior meaningfully changed at runtime. The most you can say
about any variable in Python is that it is a descendant of 'object' or else
some primitive type.

~~~
Veedrac
If Python's `if` is weakly typed, then Rust's `for` and `.` are weakly typed.
Few would say that, though.

~~~
cma
One place where Python is pretty weakly typed is going the other way, where it
accepts things like: true + true * 2 - false / true, even outside of if
statements.

I've definitely been bitten by this before, accidentally passing in a book
parameter instead of an int, and having some math work initially and then blow
up months later.

Knuth argues against this kind of implicit bool to integer conversion in
Concrete Mathematics.

~~~
ubernostrum
Nitpick: this isn't an implicit conversion.

There's a lot of history of languages without a real boolean type using
integer 0 and 1 as the sentinel values indicating false-ness and true-ness.

And Python, in a nod to that, implements bool as a subclass of int, of which
only two instances can ever exist (with False having a value of 0 and True
having a value of 1).

So this isn't weak typing -- isinstance(True, int) is True in Python, and
operations like the ones you're mentioning work because of that, for the same
reason any other subclass of int would work.

~~~
cma
Interesting, so technically isn't weak typing, but in practice to me it is a
distinction without a difference. You could make int a subtype of string, and
allow things like "1" \+ 1 == "11" and end up with many of the same problems
of weakly typed languages.

~~~
Veedrac
Well, that would violate the Liskov Substitution Principle.

But I think there's a fundamental divide about what weak typing actually is.
For example, it's entirely possible in Rust to have implemented Add for i32
and String. Even this isn't weak typing in its traditional form.

AFAIK, in this sense weak typing refers to whenever the compiler will
implicitly cast one type to another in order to satisfy a type constraint. C's
number types do this. PHP does this on everything. Javascript has, eg., [] +
[] == "". Python does not do this - all type casts are explicit in the
implementation of the operator or function (which is implemented on the type,
not globally).

It's reasonable to argue that the use of the phrase "weak typing" to mean
"things I don't like about a type-system" is not only well established but
maybe even more useful. It does, however, irritate Python programmers who
don't want their language lumped in with PHP.

------
CrLf
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.

~~~
jghn
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

~~~
prodigal_erik
This. Every test just explores one special case of the invariant I would
prefer to enforce but cannot with today's tooling.

------
ilevkivskyi
See also acceptance letter [https://mail.python.org/pipermail/python-
dev/2015-May/140104...](https://mail.python.org/pipermail/python-
dev/2015-May/140104.html) and the discussion on Reddit
[http://redd.it/36yuk8](http://redd.it/36yuk8)

------
brikis98
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.

[1] [http://www.ybrikman.com/writing/2015/02/06/are-static-
typing...](http://www.ybrikman.com/writing/2015/02/06/are-static-typing-and-
functional/)

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

~~~
chimeracoder
> 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/](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.

~~~
TazeTSchnitzel
TypeScript is a JS superset, though. It's not part of JS itself.

------
hyperpape
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.

------
wcdolphin
This seems exciting. I'm not familiar with the availability of new Python
features. When can I use this in my day to day Python?

~~~
tveita
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://youtrack.jetbrains.com/issue/PY-15206)

------
rectangletangle
I like it, let the developer choose where typing is most appropriate. Also
runtime type assertions really help with identifying bugs, especially NoneType
issues.

------
dimino
This is a tragedy, as it forces comments to contain syntactic value.

~~~
deckiedan
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.

------
Eleutheria
So python becomes nim now?

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
Pretty sure Python is very "enterprise"[1] worthy.

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

~~~
dikaiosune
I remain on the fence myself, but that article mostly argues that it is
_useable_ and used in the enterprise, not that it's worthy of use at that
project size and scale. I think that article, rather than being a strong
technical piece, is a pretty good example of:

[http://en.wikipedia.org/wiki/Argumentum_ad_populum](http://en.wikipedia.org/wiki/Argumentum_ad_populum)

Also, it doesn't take much google-fu to find a counterargument from someone
apparently reputable:

[http://www.quora.com/Why-does-Google-prefer-the-Java-
stack-f...](http://www.quora.com/Why-does-Google-prefer-the-Java-stack-for-
its-products-instead-of-Python/answer/Robert-Love-1)

