News for hackers. Stuff that matters.
Re:Untyped Python: The Python That Was by woodruffw on Saturday December 02, 2023 @04:10PM (#38502086)
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.

Re:Untyped Python: The Python That Was by martinky24 on Saturday December 02, 2023 @04:15PM (#38502121)
If the negligible additional parsing overhead makes or breaks your program, you shouldn't have been writing it in Python in the first place.
Re:Untyped Python: The Python That Was by woodruffw on Saturday December 02, 2023 @04:19PM (#38502138)
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 :-)
Re:Untyped Python: The Python That Was by LtWorf on Saturday December 02, 2023 @05:11PM (#38502629)
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.

Re:Untyped Python: The Python That Was by lawrencejgd on Sunday December 03, 2023 @12:40AM (#38505113)
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.
Re:Untyped Python: The Python That Was by LtWorf on Sunday December 03, 2023 @05:55AM (#38506164)

    from __future__ import annotations
This will break all the runtime type checking modules (such as typedload, which I wrote).
Re:Untyped Python: The Python That Was by dragonwriter on Sunday December 03, 2023 @10:52AM (#38507948)
> 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.
Re:Untyped Python: The Python That Was by LtWorf on Monday December 04, 2023 @04:49PM (#38523621)
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

Re:Untyped Python: The Python That Was by kamikaz1k on Saturday December 02, 2023 @08:21PM (#38503929)
Are they evaluated at runtime? Or just when the bytecode is generated? (Is that considered runtime?)
Re:Untyped Python: The Python That Was by lawrencejgd on Sunday December 03, 2023 @12:46AM (#38505141)
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).