4 ms·

> Here is what has changed: we no longer trust developers as much and we are re-introducing the complexity that we were fighting. Modern Python can at times be

> Here is what has changed: we no longer trust developers as much and we are re-introducing the complexity that we were fighting. Modern Python can at times be impossible to comprehend for a developer. In a way in some areas we are creating the new Java. We became the people we originally displaced. Just that when we are not careful we are on a path to the world's worst Java. We put typing on a language that does not support it, our interpreter is slow, it has a GIL. If you believe type hints in Python are a net negative, then just don't use them. I also don't get the performance argument: Type hints aren't evaluated at runtime, so whether code has them or not shouldn't matter for performance.

woodruffw 3y ago
I agree with you, but for correctness' sake: > I also don't get the performance argument: Type hints aren't evaluated at runtime, so whether code has them or not shouldn't matter for performance. Type hints actually are evaluated at runtime, since they're part of the syntax tree. They just aren't checked for correctness, so the (small, but sometimes non-negligible) amount of parsing overhead they add is essentially lost performance.
- martinky24 3y ago
  If the negligible additional parsing overhead makes or breaks your program, you shouldn't have been writing it in Python in the first place.
  - woodruffw 3y ago
    I agree. I don't think it's a very good argument for a language or ecosystem like Python. But it's important to be right factually about it not mattering, versus claiming that it has no performance impact at all :-)
- LtWorf 3y ago
  It might not be so small, if you import a module just to declare a type, that's an import that happens at runtime, that might not be needed. The correct way would be to do conditional imports that are only performed while typechecking in this case. But I'd expect the issue to happen often.
  - lawrencejgd 3y ago
    In Python you can use this: from __future__ import annotations from typing import TYPE_CHECKING if TYPE_CHECKING: import mymodule def myfunc(arg: mymodule.MyType) -> bool: return bool(arg) This will make type annotations to be converted internally to strings. TYPE_CHECKING is a constant that's always false except when you use a type checker, so mymodule will never be imported on runtime, but the type checker will think that it was imported.
    - LtWorf 3y ago
      from __future__ import annotations This will break all the runtime type checking modules (such as typedload, which I wrote).
      - dragonwriter 3y ago
        > This will break all the runtime type checking modules (such as typedload, which I wrote). Most runtime type checking modules I am aware of support from __future__ import annotations E.g., typeguard, Pydantic, beartype, among others.
        LtWorf 3y ago
        they "support" it, but many things will break, for the simple reason that there is absolutely no way to resolve certain types at runtime. In fact the main reason why it's a future is because the pydantic people complained that it broke stuff. When I had complained earlier, Guido didn't give 2 shits, although it broke typedload, a library I wrote that is very similar to pydantic, when pydantic didn't exist. So I know what I am saying
- kamikaz1k 3y ago
  Are they evaluated at runtime? Or just when the bytecode is generated? (Is that considered runtime?)
  - lawrencejgd 3y ago
    They're evaluated at runtime, but CPython never checks if type hints are right or not. If you use "from __future__ import annotations" then they're converted to strings, so they could even have references to objects that don't exists (this is for a better performance).
singhrac 3y ago
I don’t agree with all of his points either but I think what he meant by that was a separate, semicolon’d statement that the interpreter is slow (not that typing is slowing it down). I think he’s saying that types are useful for performance optimizations in other languages but Python is not meant to be that.
hipsteralert007 3y ago
[flagged]
- kindaagree202 3y ago
  Most people just want to read info, enter their data, get feedback and go on with their day. They don't care about smooth transitions, spa, etc. The only thing they care about is if it works correctly and their expectations are met. There are applications where all the unnecessary abstractions might make sense but those are the exception not the rule.
9dev 3y ago
> we no longer trust developers as much and we are re-introducing the complexity that we were fighting. I hate this spin to somehow make it about not trusting developers to do their job right. As if it was an insult to test for correctness. Imagine skipping pre-flight checks for accomplished pilots, or load calculations for renowned bridge engineers. This hubris of some software developers assuming to be hyper-correct geniuses really alienates me.

woodruffw 3y ago

I agree with you, but for correctness' sake: > I also don't get the performance argument: Type hints aren't evaluated at runtime, so whether code has them or not shouldn't matter for performance. Type hints actually are evaluated at runtime, since they're part of the syntax tree. They just aren't checked for correctness, so the (small, but sometimes non-negligible) amount of parsing overhead they add is essentially lost performance.

martinky24 3y ago
If the negligible additional parsing overhead makes or breaks your program, you shouldn't have been writing it in Python in the first place.
- woodruffw 3y ago
  I agree. I don't think it's a very good argument for a language or ecosystem like Python. But it's important to be right factually about it not mattering, versus claiming that it has no performance impact at all :-)
LtWorf 3y ago
It might not be so small, if you import a module just to declare a type, that's an import that happens at runtime, that might not be needed. The correct way would be to do conditional imports that are only performed while typechecking in this case. But I'd expect the issue to happen often.
- lawrencejgd 3y ago
  In Python you can use this: from __future__ import annotations from typing import TYPE_CHECKING if TYPE_CHECKING: import mymodule def myfunc(arg: mymodule.MyType) -> bool: return bool(arg) This will make type annotations to be converted internally to strings. TYPE_CHECKING is a constant that's always false except when you use a type checker, so mymodule will never be imported on runtime, but the type checker will think that it was imported.
  - LtWorf 3y ago
    from __future__ import annotations This will break all the runtime type checking modules (such as typedload, which I wrote).
    - dragonwriter 3y ago
      > This will break all the runtime type checking modules (such as typedload, which I wrote). Most runtime type checking modules I am aware of support from __future__ import annotations E.g., typeguard, Pydantic, beartype, among others.
      - LtWorf 3y ago
        they "support" it, but many things will break, for the simple reason that there is absolutely no way to resolve certain types at runtime. In fact the main reason why it's a future is because the pydantic people complained that it broke stuff. When I had complained earlier, Guido didn't give 2 shits, although it broke typedload, a library I wrote that is very similar to pydantic, when pydantic didn't exist. So I know what I am saying
kamikaz1k 3y ago
Are they evaluated at runtime? Or just when the bytecode is generated? (Is that considered runtime?)
- lawrencejgd 3y ago
  They're evaluated at runtime, but CPython never checks if type hints are right or not. If you use "from __future__ import annotations" then they're converted to strings, so they could even have references to objects that don't exists (this is for a better performance).

singhrac 3y ago

I don’t agree with all of his points either but I think what he meant by that was a separate, semicolon’d statement that the interpreter is slow (not that typing is slowing it down). I think he’s saying that types are useful for performance optimizations in other languages but Python is not meant to be that.

hipsteralert007 3y ago

[flagged]

kindaagree202 3y ago
Most people just want to read info, enter their data, get feedback and go on with their day. They don't care about smooth transitions, spa, etc. The only thing they care about is if it works correctly and their expectations are met. There are applications where all the unnecessary abstractions might make sense but those are the exception not the rule.

9dev 3y ago

> we no longer trust developers as much and we are re-introducing the complexity that we were fighting. I hate this spin to somehow make it about not trusting developers to do their job right. As if it was an insult to test for correctness. Imagine skipping pre-flight checks for accomplished pilots, or load calculations for renowned bridge engineers. This hubris of some software developers assuming to be hyper-correct geniuses really alienates me.