News for hackers. Stuff that matters.
Re:Python’s “type hints” are a bit of a disappointment to me by throwaway287391 on Thursday April 21, 2022 @10:16PM (#31117498)
> This is definitely not what Python is doing.

Maybe not by default but there is tooling that makes it work that way — that’s exactly how the python build system works at my company. I don’t know the details but when I “build” python code (creating bytecode pyc files) it produces compiler errors and fails to build if I e.g. try to pass an int to an f(x: str). This has usefully caught bugs before I ran some expensive/time-consuming scripts.

I guess you could say this doesn’t count as it’s a separate program doing the type checking but IMO there’s not a clear distinction between that and e.g. having a first type checking pass in the “same” compiler program.

Re:Python’s “type hints” are a bit of a disappointment to me by reikonomusha on Thursday April 21, 2022 @10:23PM (#31117537)
I don't know the latest but PEP 484 writes:

> While these [type] annotations are available at runtime through the usual __annotations__ attribute, no type checking happens at runtime. Instead, the proposal assumes the existence of a separate off-line type checker which users can run over their source code voluntarily.

Re:Python’s “type hints” are a bit of a disappointment to me by throwaway287391 on Thursday April 21, 2022 @10:30PM (#31117577)
Right, it’s definitely still a voluntary feature. What I meant is if you opt in and make it part of your project’s standard build procedure for python code, you effectively get the behavior and benefits of “compile-time type checking” (to the extent that you actually use type annotations in your code).