4 ms·

I agree with you, although I must say that as an occasional Python user the way type hints are implemented absolutely baffles me. In particular the fact that th

by simias 6y ago

I agree with you, although I must say that as an occasional Python user the way type hints are implemented absolutely baffles me. In particular the fact that they are completely ignored by the standard implementation. They're glorified comments. Given how opinionated the Python maintainers can be, it baffles me that they accepted to get these optional, noisy, half backed type hints into the core language. In my experience given that they're optional and you'll almost never get 100% of your code and its dependencies with correct and up to date signatures it's just a nuisance. Maybe in the right projects if all the devs are very thorough with them it can be helpful, but that's really not my experience. If at least it triggered an assertion at runtime when the type doesn't match it would be massively more useful. And even then, if you're so thorough with your typing, why not just use a proper statically typed language? I really don't get why it's even there to be honest.

mumblemumble 6y ago
> the fact that they are completely ignored by the standard implementation. They're glorified comments. Not quite. You can reflect on and interact with them at run-time, too. This does make it possible to implement run-time checking as a library solution. I can't speak to why run-time checking wasn't built into the language as a default behavior, and the PEP doesn't explain why (though perhaps the answer is in the mailing list), but one possibility is that it would be wasteful. Most functions that are only prepared to accept certain types already have some form of run-time type check baked in, either explicitly or incidentally, so adding a second check would likely introduce overhead without producing a whole lot more type safety.
- uryga 6y ago
  > I can't speak to why run-time checking wasn't built into the language as a default behavior tldr: you other get either huge overhead or need to type annotate everything like it's Java, and it'll still be pretty limited/not super useful --- there's a bunch of libraries that do this, and they're all fundamentally limited [though i guess some of these may just be failures of imagination on my part]: - hard to check generics: if it's a builtin, you have to traverse the whole structure and check every element. and for user-defined collections, the programmer has to to manually instantiate every generic like: CoolSequence[int]([1,2,3]) (which sucks) and every method call/property access needs to be checked - if your function takes a callback, there's no way to typecheck that callback at runtime (without calling it, at which point it's not terribly useful. which extends to all functions i guess) - not much you can do with iterators/generators. can't check if something really is an `Iterator[int]` without exhausting it, and e.g. type-erroring after processing 20 elements because it yielded not-an-int isn't very useful so in the end, even if you wrap Every Damn Thing in a type assertion, you still get the errors very late, not much sooner than your usual "AttributeError: object None has no property named 'foobar'". kind of a worst-of-both-worlds situation
  - pjmlp 6y ago
    > tldr: you other get either huge overhead or need to type annotate everything like it's Java, and it'll still be pretty limited/not super useful Still using Java 8 are we?
    - mumblemumble 6y ago
      I'm pretty sure the level of type annotation you'd get roped into doing would be about on par with what you get in Java 10: function parameter and return types, but not local variable types.
    - uryga 6y ago
      i'm aware Java has type inference now. but i've got some not-so-fond memories of learning it when it didn't :)
swagonomixxx 6y ago
Type hints are not perfect, but IMO after using them for a while, they are significantly better than nothing. If you do the legwork, you can get mypy[0] type-checking done on your codebase in a way that is similar to how TypeScript does type-checking. There are stub files that are provided by project maintainers that are then used by mypy to infer things like e.g the return type of a function. Type hints are also inline in the code, and not technically comments. They can be retrieved from class attributes using facilities from the standard library [1] and can facilitate other tooling that is specific for your project or that are more general. > And even then, if you're so thorough with your typing, why not just use a proper statically typed language? That would remove a lot of the benefit of choosing Python. Python is dynamically typed. Type hints make it possible to do type checking statically, but with a lot of extra leg work (as I described above). Making Python itself statically typed is not something that would interest 99% of the Python community IMO. [0] http://mypy-lang.org/ http://mypy-lang.org/ [1] https://docs.python.org/3/library/typing.html#typing.get_type_hints https://docs.python.org/3/library/typing.html#typing.get_typ...
laurencerowe 6y ago
I wish JS had ignored type annotations built into the language so that TypeScript code could run directly without a transpilation step.
codethief 6y ago
My view is completely opposite to yours. I find type hints extremely useful and every new line of Python code I write uses them. I finally no longer have to do type checking / duck typing in my head but can simply write the types down. Moreover, an IDE like PyCharm will then do the type checking for me, notifying me of potential errors. (Even if I decide not to use Mypy.) Third, I finally only need to look at the signature of standard library functions to see what parameters they accept / what values they return. Previously, I always had to consult the Python documentation.
- kortex 6y ago
  Bingo. I think a big explanation of the wide variance on opinion about type hints is due to reliance on tooling, or lack thereof. Writing type hinted python in Pycharm or Ipython feels like racing in a sports car. Without it, feels like stop and go traffic with the occasional car accident. I can see how if you are using a WYSIWYG editor, type hints feel like more text for little gain. But even then, it really helps document intent. In fact switching to IDEs is partly what made me go from someone who hated static typing to loving it.
  - codethief 6y ago
    > Writing type hinted python in Pycharm or Ipython feels like racing in a sports car. Without it, feels like stop and go traffic with the occasional car accident. This is a beautiful analogy! As for the second part, though, I would say that even if your IDE does not provide automatic type checking, type hints will still add some benefit because: - without type hints you have to do all type checking in your head (across all stack frames). - whereas with type hints you only need to do type checking down to the first level of the stack. To illustrate what I mean, consider the following code: def bar(param1, param2): ... # Some complicated code from which it is not immediately clear what values are allowed for param1 and param2, nor what the return type of the function is. def foo(param): return bar(param, param2="some default value") foo("something something") Now, in order to verify that `foo("something something")` is correct, you have to manually look at foo() and then at bar(). Needless to say, this adds a lot of mental overhead to the game. If we added type hints to both foo() and bar(), however, you would only have to check the signature foo() – which, even in IDEs without type checking, usually amounts to hovering over `foo("something something")`.
dragonwriter 6y ago
> Given how opinionated the Python maintainers can be, it baffles me that they accepted to get these optional, noisy, half backed type hints into the core language Guido joined the Mypy team while he was Python’s BDFL. Also, there’s nothing half baked about either Python’s type hints or Python’s type system, or it's major type checkers. It's not Haskell, sure, but it's an expressive to system, the typecheckers are reasonably smart, and the annotations are readable and sensible if somewhat verbose; there were some infelicities regarding alternate names for core types in annotations, but that's been improved recently. > In my experience given that they're optional and you'll almost never get 100% of your code and its dependencies with correct and up to date signatures it's just a nuisance In my experience they start to provide value in preventing bugs and easing development because of tooling support way below 100% coverage. > If at least it triggered an assertion at runtime when the type doesn't match it would be massively more useful. Python’s type annotations are annotations, and are used by some libraries for runtime (validation, serialization/deserialization, etc ) as well as static checking purposes (e.g., pydantic.) > And even then, if you're so thorough with your typing, why not just use a proper statically typed language? All a “proper statically typed” language is is a language with a static type checker run ahead of time, which Python is of you choose it to be. There's a lot of code in the ecosystem that is more broadly types than it needs to be, because no annotated code which checkers can't infer anything better for use Any, but that's evolving over time as it is more common for popular libraries to be typed, or at least have typings available.
kortex 6y ago
> They're glorified comments This was always kinda false (type hints can be composed unlike eg docstring param @type). But with the introduction of dataclass, this is empirically false. You can readily hook into the type hints, reflect on them, use it to marshal data, etc. Using __post_init__, you can leverage any kind of runtime checks you want to enforce invariants. Also type hints greatly help transpilation. You don't need 100% to reap the benefits. In fact I will annotate small bits of un-typed code and it makes it way easier to reason about.
toyg 6y ago
> it baffles me that they accepted to get these The chorus of people asking for increased typesafety had become too loud to ignore. Type hints gave them enough support to cover 95% of their needs, which were/are largely organizational rather than technical: developers must feel sure they are using the right classes in their code, pulled from the right places in their project, and don’t have to look up docs at every step (because the IDE will autocomplete stuff). What happens later, the low-level implementation, it doesn’t really matter; what matters is the information about types is surfaced somewhere, so that IDEs and tooling can use it to document projects and help developers. That’s what type hints do, and yeah, they are basically glorified docs, but integrating docs into syntax is one of Python’s many traditional strengths (see docstrings, doctests, etc). That’s also why they are optional, thank goodness, so people who don’t have big-org / big-project needs can still be productive.

by simias 6y ago

mumblemumble 6y ago

> the fact that they are completely ignored by the standard implementation. They're glorified comments. Not quite. You can reflect on and interact with them at run-time, too. This does make it possible to implement run-time checking as a library solution. I can't speak to why run-time checking wasn't built into the language as a default behavior, and the PEP doesn't explain why (though perhaps the answer is in the mailing list), but one possibility is that it would be wasteful. Most functions that are only prepared to accept certain types already have some form of run-time type check baked in, either explicitly or incidentally, so adding a second check would likely introduce overhead without producing a whole lot more type safety.

uryga 6y ago
> I can't speak to why run-time checking wasn't built into the language as a default behavior tldr: you other get either huge overhead or need to type annotate everything like it's Java, and it'll still be pretty limited/not super useful --- there's a bunch of libraries that do this, and they're all fundamentally limited [though i guess some of these may just be failures of imagination on my part]: - hard to check generics: if it's a builtin, you have to traverse the whole structure and check every element. and for user-defined collections, the programmer has to to manually instantiate every generic like: CoolSequence[int]([1,2,3]) (which sucks) and every method call/property access needs to be checked - if your function takes a callback, there's no way to typecheck that callback at runtime (without calling it, at which point it's not terribly useful. which extends to all functions i guess) - not much you can do with iterators/generators. can't check if something really is an `Iterator[int]` without exhausting it, and e.g. type-erroring after processing 20 elements because it yielded not-an-int isn't very useful so in the end, even if you wrap Every Damn Thing in a type assertion, you still get the errors very late, not much sooner than your usual "AttributeError: object None has no property named 'foobar'". kind of a worst-of-both-worlds situation
- pjmlp 6y ago
  > tldr: you other get either huge overhead or need to type annotate everything like it's Java, and it'll still be pretty limited/not super useful Still using Java 8 are we?
  - mumblemumble 6y ago
    I'm pretty sure the level of type annotation you'd get roped into doing would be about on par with what you get in Java 10: function parameter and return types, but not local variable types.
  - uryga 6y ago
    i'm aware Java has type inference now. but i've got some not-so-fond memories of learning it when it didn't :)

swagonomixxx 6y ago

Type hints are not perfect, but IMO after using them for a while, they are significantly better than nothing. If you do the legwork, you can get mypy[0] type-checking done on your codebase in a way that is similar to how TypeScript does type-checking. There are stub files that are provided by project maintainers that are then used by mypy to infer things like e.g the return type of a function. Type hints are also inline in the code, and not technically comments. They can be retrieved from class attributes using facilities from the standard library [1] and can facilitate other tooling that is specific for your project or that are more general. > And even then, if you're so thorough with your typing, why not just use a proper statically typed language? That would remove a lot of the benefit of choosing Python. Python is dynamically typed. Type hints make it possible to do type checking statically, but with a lot of extra leg work (as I described above). Making Python itself statically typed is not something that would interest 99% of the Python community IMO. [0] http://mypy-lang.org/ http://mypy-lang.org/ [1] https://docs.python.org/3/library/typing.html#typing.get_type_hints https://docs.python.org/3/library/typing.html#typing.get_typ...

laurencerowe 6y ago

I wish JS had ignored type annotations built into the language so that TypeScript code could run directly without a transpilation step.

codethief 6y ago

My view is completely opposite to yours. I find type hints extremely useful and every new line of Python code I write uses them. I finally no longer have to do type checking / duck typing in my head but can simply write the types down. Moreover, an IDE like PyCharm will then do the type checking for me, notifying me of potential errors. (Even if I decide not to use Mypy.) Third, I finally only need to look at the signature of standard library functions to see what parameters they accept / what values they return. Previously, I always had to consult the Python documentation.

kortex 6y ago
Bingo. I think a big explanation of the wide variance on opinion about type hints is due to reliance on tooling, or lack thereof. Writing type hinted python in Pycharm or Ipython feels like racing in a sports car. Without it, feels like stop and go traffic with the occasional car accident. I can see how if you are using a WYSIWYG editor, type hints feel like more text for little gain. But even then, it really helps document intent. In fact switching to IDEs is partly what made me go from someone who hated static typing to loving it.
- codethief 6y ago
  > Writing type hinted python in Pycharm or Ipython feels like racing in a sports car. Without it, feels like stop and go traffic with the occasional car accident. This is a beautiful analogy! As for the second part, though, I would say that even if your IDE does not provide automatic type checking, type hints will still add some benefit because: - without type hints you have to do all type checking in your head (across all stack frames). - whereas with type hints you only need to do type checking down to the first level of the stack. To illustrate what I mean, consider the following code: def bar(param1, param2): ... # Some complicated code from which it is not immediately clear what values are allowed for param1 and param2, nor what the return type of the function is. def foo(param): return bar(param, param2="some default value") foo("something something") Now, in order to verify that `foo("something something")` is correct, you have to manually look at foo() and then at bar(). Needless to say, this adds a lot of mental overhead to the game. If we added type hints to both foo() and bar(), however, you would only have to check the signature foo() – which, even in IDEs without type checking, usually amounts to hovering over `foo("something something")`.

dragonwriter 6y ago

> Given how opinionated the Python maintainers can be, it baffles me that they accepted to get these optional, noisy, half backed type hints into the core language Guido joined the Mypy team while he was Python’s BDFL. Also, there’s nothing half baked about either Python’s type hints or Python’s type system, or it's major type checkers. It's not Haskell, sure, but it's an expressive to system, the typecheckers are reasonably smart, and the annotations are readable and sensible if somewhat verbose; there were some infelicities regarding alternate names for core types in annotations, but that's been improved recently. > In my experience given that they're optional and you'll almost never get 100% of your code and its dependencies with correct and up to date signatures it's just a nuisance In my experience they start to provide value in preventing bugs and easing development because of tooling support way below 100% coverage. > If at least it triggered an assertion at runtime when the type doesn't match it would be massively more useful. Python’s type annotations are annotations, and are used by some libraries for runtime (validation, serialization/deserialization, etc ) as well as static checking purposes (e.g., pydantic.) > And even then, if you're so thorough with your typing, why not just use a proper statically typed language? All a “proper statically typed” language is is a language with a static type checker run ahead of time, which Python is of you choose it to be. There's a lot of code in the ecosystem that is more broadly types than it needs to be, because no annotated code which checkers can't infer anything better for use Any, but that's evolving over time as it is more common for popular libraries to be typed, or at least have typings available.

kortex 6y ago

> They're glorified comments This was always kinda false (type hints can be composed unlike eg docstring param @type). But with the introduction of dataclass, this is empirically false. You can readily hook into the type hints, reflect on them, use it to marshal data, etc. Using __post_init__, you can leverage any kind of runtime checks you want to enforce invariants. Also type hints greatly help transpilation. You don't need 100% to reap the benefits. In fact I will annotate small bits of un-typed code and it makes it way easier to reason about.

toyg 6y ago

> it baffles me that they accepted to get these The chorus of people asking for increased typesafety had become too loud to ignore. Type hints gave them enough support to cover 95% of their needs, which were/are largely organizational rather than technical: developers must feel sure they are using the right classes in their code, pulled from the right places in their project, and don’t have to look up docs at every step (because the IDE will autocomplete stuff). What happens later, the low-level implementation, it doesn’t really matter; what matters is the information about types is surfaced somewhere, so that IDEs and tooling can use it to document projects and help developers. That’s what type hints do, and yeah, they are basically glorified docs, but integrating docs into syntax is one of Python’s many traditional strengths (see docstrings, doctests, etc). That’s also why they are optional, thank goodness, so people who don’t have big-org / big-project needs can still be productive.