10 ms·
One reason was so the type system could be backported. You can install the typing module all the way back to Python 2.7, where list[int] will never work but not
by duckerude 6y ago
One reason was so the type system could be backported. You can install the typing module all the way back to Python 2.7, where list[int] will never work but nothing prohibits typing.List[int].
The system has been rolled out slowly in general, without hasty changes to the core language.
There's a similar change coming in 3.10: https://docs.python.org/3.10/whatsnew/3.10.html#pep604-new-type-operator https://docs.python.org/3.10/whatsnew/3.10.html#pep604-new-t...
- hsbauauvhabzb 6y agoAny word on if strong typing enforcement will ever happen? I’m sure it’ll only ever be optional but it’s the single biggest wart in the language imo.
- gnulinux 6y agoWhy? Just use mypy and disable Any types. So, it's not longer optional. Then make it so that if mypy fails, your code doesn't run. test-all: mypy main.py pytest test/main.py
- lozenge 6y agoThis relies on your third party library type annotations being accurate.
- joshuamorton 6y agoThat's true of any type system.
- DonaldPShimoda 6y agoNo it isn't. In a static type system, you're not relying on annotations because the types are all known statically. But in a dynamic type system, you can have regions of untyped code where the best your third party static analyzer can do is slap "Any" on them and you watch as the precision of your type checking erodes to nothing.
- joshuamorton 6y agoWhat is `public static void main(string args)` but an "annotation"? You can stick "untyped" code in any language. You just have to annotate things with `Object` and cast them.
- sdht0 6y agoA more appropriate example is: `var list = new ArrayList<String>();` [1] The compiler figures out the type of `list` without "annotations". Same with C++'s `auto` and Rust's `let`. [1] https://openjdk.java.net/jeps/286 https://openjdk.java.net/jeps/286
- joshuamorton 6y agoTo clarify, no, this is a complete non-sequitor. The ability for a type system to do inference has no bearing on whether or not the types are checked or not. To make things even more confusing, as an example, python can have type inference (pytype) or not (mypy). In either case, annotations are type checked.
- sdht0 6y agoThe other discussions have already pointed out some limitations in your interpretation (heh) of types. I think the key difference between the annotations in Python and types in Java, or even more strongly in languages like Rust and Haskell, is how they are used in the language ecosystem. In Java and Rust, the types are cental to how programmers think in those languages. A large part of the dev cycle goes into ensuring the types are consistent. In python, these type annotations are a relatively recent addition that the community has not completely adopted yet. A lot of real-world python code will have no types, thus the (3rd party) python type checkers will fail to ensure the benefits of having strong consistent types. And how can we then justify "types" like Object in Java or Any in Rust? Well, sometimes we do want to write code where we want to tell the compiler to stop checking types. However, these are more of an escape hatch rather than a central part of the language ecosystem. As someone else already pointed out, the Java or Rust community does not go about writing code with only Object or Any, even though they can in principle. But in python, that's what the community has been doing till now. It goes the other way too. If the python community starts taking the type annotations seriously, it will start approaching the same usefulness as in these other static languages with good type systems. Then we can start expecting that the 3rd party library type annotations being accurate, which started this discussion in the first place.
- philwelch 6y agoOr existing in the first place. Or being fundamentally possible to implement in the first place (I say, glaring at boto3).
- orf 6y agomypy-boto3 works fantastically: https://mypy-boto3.readthedocs.io/en/latest/ https://mypy-boto3.readthedocs.io/en/latest/
- philwelch 6y agoHuh, interesting: > Auto discovery of types for boto3.client and boto3.session calls I'm curious how this is possible. I didn't realize mypy could inspect function arguments and use them to determine the returned type.
- duckerude 6y agotyping.Literal makes a lot possible as of 3.8: https://docs.python.org/3/library/typing.html#typing.Literal https://docs.python.org/3/library/typing.html#typing.Literal
- hsbauauvhabzb 6y agoAt one point there was exactly zero support for python3 by third party libraries, it took >10 years but we got there. I see it as ‘use strict’ in JS land
- ebg13 6y ago> Just use mypy Mypy doesn't work for code that isn't statically available before runtime. Though there are ways to do runtime type checking as well.
- giancarlostoro 6y agoIt would probably never happen and I dont see why it should ever matter. You can always use tooling to enforce it as another comment mentioned. I would argue if you decide to type annotate a whole project you should just go for it. I have been type annotating my project over time in the hopes I eventually have just enough context about what I am doing. Also a good IDE will show you any place wrong types are criss crossed.
- nerdponx 6y agoThis is an explicitly stated non-goal of type annotations in Python across several official documents.
- DonaldPShimoda 6y agoA technical note: Python is (relatively) strongly typed, but it is not statically typed. And the lack of static typing is a fundamental feature of the language. I doubt very much whether a static type system will ever be implemented in Python proper.
- m45t3r 6y ago> There's a similar change coming in 3.10 Wow, this is pretty exciting. Hope we also see match being accepted in Python 3.10, so this would make (for me at least) one of the best Python releases in years.
- hannibalhorn 6y agoI like adding | as an alias for Union, and the PEP has lots of examples of where typing.Union gets gnarly really quick, but that doesn't seem like a great example in the changelog: def square(number: int | float) -> int | float: return number ** 2 A TypeVar constrained to int and float, T = TypeVar('T', int, float), should be used instead to indicate that the return type is the same as the argument type, no?
- pansa2 6y agoThis example demonstrates why I don't understand Python's type annotations. They seem to be incompatible with the language's core principle of duck typing. Why would you constrain a function like `square` to only accept `int`s and `float`s? What if I want to square, say, a `fractions.Fraction`?
- heavyset_go 6y agoType annotations are just hints and aren't enforced at runtime. You can pass whatever you want into that function, and you can also create a union type with the Fraction if you want the annotations to match your application.
- pansa2 6y ago> You can pass whatever you want into that function Not really. Doing so won't cause an error at runtime, but it will produce an error when you run the type checker.
- musicale 6y ago> One reason was so the type system could be backported. You can install the typing module all the way back to Python 2.7, where list[int] will never work but nothing prohibits typing.List[int]. The system has been rolled out slowly in general, without hasty changes to the core language. If only they'd had that idea a bit earlier in the Python 3 life cycle...
- ehsankia 6y agoI'm confused, type annotations is not supported in Py 2 anyways, and if you're gonna use type comments a la `# type: list[int]` then it doesn't matter really, does it?
- duckerude 6y agoSimple type annotations can be entirely in comments, but for more complex usage you might want to execute code, like type aliases: MyContainer = List[int] On top of that, the typing module was also backported to Python 3 versions before 3.5, where you do have annotation syntax.
- coldtea 6y ago>You can install the typing module all the way back to Python 2.7, where list[int] will never work but nothing prohibits typing.List[int]. Why though? Even in 2.7, isn't the : type and -> type part just taken as annotation (that is, could just be ignored and not clash because it's a valid type)? Or was it some parser shortcoming?