10 ms·

I'm excited about PEP 585 https://www.python.org/dev/peps/pep-0585/ https://www.python.org/dev/peps/pep-0585/ Now you can use list, dict, tuple instead of typi

I'm excited about PEP 585 https://www.python.org/dev/peps/pep-0585/ https://www.python.org/dev/peps/pep-0585/ Now you can use list, dict, tuple instead of typing.List, typing.Dict, typing.Tuple.

ZephyrBlu 6y ago
This is what put me off using type hints. Now I think I might actually add them to my code.
gnulinux 6y ago
Why wasn't done in the first place? What was the rationale of using typing.List? Did they want to reserve `dict[x]` for some other semantics?
- ddavis 6y ago
  The PEP abstract says this: "Static typing as defined by PEPs 484, 526, 544, 560, and 563 was built incrementally on top of the existing Python runtime and constrained by existing syntax and runtime behavior"
- renewiltord 6y ago
  Well, `list` and friends were functions to construct those objects. So presumably they did it this way to prioritize adding typing over getting it perfect. I think it was the right choice.
  - stefano 6y ago
    It was a problem only because somehow they decided that type annotations should evaluate to something meaningful at runtime, instead of being a compile-time only construct like in every other language.
    - smitty1e 6y ago
      "Somehow they decided" is rooted in the desire to make typing optional, and absolutely not a requirement.
      - setr 6y ago
        Wouldn't compiler selective enforcement achieve the same goal? It seems to me the difference is that other programs can be implemented to do the typechecking (eg mypy) rather than the compiler doing so itself
        ben-schaaf 6y ago
        It lets you do things like `functools.singledispatchmethod`.
    - m45t3r 6y ago
      Any language with reflections needs to evaluate types as something meaningful at runtime.
      - lmm 6y ago
        The runtime mirror doesn't have to have the same name as the compile-time type. Look at Java where you have to do weird things with class objects to do reflective access.
  - nerdponx 6y ago
    list is also a type. Maybe that wasn't true in older versions, but it's true now.
- 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 ago
    Any 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 ago
      Why? 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 ago
        This relies on your third party library type annotations being accurate.
        joshuamorton 6y ago
        That's true of any type system.
        DonaldPShimoda 6y ago
        No 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.
- dragonwriter 6y ago
  I suspect a big part is the general desire to minimize the runtime impact of typing support,especially on code not using it; there's a bunch of infrastructure added to the core classes that now can be generic types to support that.
- BozeWolf 6y ago
  This is how i understood it (from https://www.python.org/dev/peps/pep-0563/ https://www.python.org/dev/peps/pep-0563/). Correct me if im wrong please. One of the reasons was that `list[int]` could not be done, as that would refer to a list index. Same as you would do `my_var = [1,2,3]` `my_var[0]` Therefore it was possible to use just `int` as a type. From python 3.9 (unless you used from __future__ import annotations in 3.7+) type hints are not parsed "as python", at function definition time, but more or less as text. In 3.9 `list[int]` does not want an item from object `list` at index 'int' when using it as a type annotation. The typing library did not have these issues because the `types` altered the way the objects worked. Probably (didnt check it!) by overriding __getitem__ and the likes.
mrfusion 6y ago
I’m not understanding.
- duckerude 6y ago
  This is how you spelled a list of ints before: from typing import List List[int] Now you can just write this: list[int]
  - newbie2020 6y ago
    Was having a hard time understanding the PEP until this compact comment. Thanks!

I'm excited about PEP 585 https://www.python.org/dev/peps/pep-0585/ https://www.python.org/dev/peps/pep-0585/ Now you can use list, dict, tuple instead of typing.List, typing.Dict, typing.Tuple.

ZephyrBlu 6y ago

This is what put me off using type hints. Now I think I might actually add them to my code.

gnulinux 6y ago

Why wasn't done in the first place? What was the rationale of using typing.List? Did they want to reserve `dict[x]` for some other semantics?

ddavis 6y ago
The PEP abstract says this: "Static typing as defined by PEPs 484, 526, 544, 560, and 563 was built incrementally on top of the existing Python runtime and constrained by existing syntax and runtime behavior"
renewiltord 6y ago
Well, `list` and friends were functions to construct those objects. So presumably they did it this way to prioritize adding typing over getting it perfect. I think it was the right choice.
- stefano 6y ago
  It was a problem only because somehow they decided that type annotations should evaluate to something meaningful at runtime, instead of being a compile-time only construct like in every other language.
  - smitty1e 6y ago
    "Somehow they decided" is rooted in the desire to make typing optional, and absolutely not a requirement.
    - setr 6y ago
      Wouldn't compiler selective enforcement achieve the same goal? It seems to me the difference is that other programs can be implemented to do the typechecking (eg mypy) rather than the compiler doing so itself
      - ben-schaaf 6y ago
        It lets you do things like `functools.singledispatchmethod`.
  - m45t3r 6y ago
    Any language with reflections needs to evaluate types as something meaningful at runtime.
    - lmm 6y ago
      The runtime mirror doesn't have to have the same name as the compile-time type. Look at Java where you have to do weird things with class objects to do reflective access.
- nerdponx 6y ago
  list is also a type. Maybe that wasn't true in older versions, but it's true now.
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 ago
  Any 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 ago
    Why? 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 ago
      This relies on your third party library type annotations being accurate.
      - joshuamorton 6y ago
        That's true of any type system.
        DonaldPShimoda 6y ago
        No 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.
dragonwriter 6y ago
I suspect a big part is the general desire to minimize the runtime impact of typing support,especially on code not using it; there's a bunch of infrastructure added to the core classes that now can be generic types to support that.
BozeWolf 6y ago
This is how i understood it (from https://www.python.org/dev/peps/pep-0563/ https://www.python.org/dev/peps/pep-0563/). Correct me if im wrong please. One of the reasons was that `list[int]` could not be done, as that would refer to a list index. Same as you would do `my_var = [1,2,3]` `my_var[0]` Therefore it was possible to use just `int` as a type. From python 3.9 (unless you used from __future__ import annotations in 3.7+) type hints are not parsed "as python", at function definition time, but more or less as text. In 3.9 `list[int]` does not want an item from object `list` at index 'int' when using it as a type annotation. The typing library did not have these issues because the `types` altered the way the objects worked. Probably (didnt check it!) by overriding __getitem__ and the likes.

mrfusion 6y ago

I’m not understanding.

duckerude 6y ago
This is how you spelled a list of ints before: from typing import List List[int] Now you can just write this: list[int]
- newbie2020 6y ago
  Was having a hard time understanding the PEP until this compact comment. Thanks!