11–20 of 70 posts
The only reason to consider type hints is for a performance increase and there wasn't any mention of that. What can you really expect from using type hints accurately?
> I don’t know how many people are doing this, but tools like mypyc will use type hints to compile Python code to something faster, like C extensions.
A few other examples for the sections given: Runtime behaviour determination: the stdlib [dataclasses]( https://docs.python.org/3/library/dataclasses.html#module-da... ) Dataclasses is notable because it's the only example (I'm aware of) of type hints effecting runtime behavior as part of the stdlib. Compiler instructions: mypyc was (one of?) the first to do this, but Cython actually supports this natively now, and i…
FWIW, `typing.NamedTuple` did this in Python 3.5, three years before dataclasses was introduced in 3.7.
class Foo(typing.NamedTuple):
a: int
b: str
f = Foo(a=1, b="hello")
print(f.b) # "hello"I'm a heavy user of type hints and enable pyright and mypy's strict modes whenever possible. However, you can't always be strict: if you use almost any package in the data science/ML ecosystem, you're unlikely to get good type inference and checking[1]. In those cases, it can still be useful to type some parameters and return values to benefit from _some_ checking, even if you don't have 100% coverage. Type hints als…
A mechanism like Haskell's type application seems like it could solve at least most, maybe all of those problems.
This sort of thing is why I gave up Python. I could see having strong typing. Or optional strong typing. But unchecked type hints are just silly. The way everybody else seems to be going is strong typing at function interfaces, with automatic inference of as much else as can be done easily. C++ (since "auto"), Go, Rust, etc.
> The way everybody else seems to be going is strong typing at function interfaces, with automatic inference of as much else as can be done easily Both mypy and pyright will do that. If your function return type is annotated, they will infer the type of the receiving variable. If you have two branches where a variable can receive two types, pyright will infer the union type. Similar for None. Example: a = input() if…
This still makes me seethe. We have pip, poetry, conda, and more. The Python folks knew that multiple incompatible systems would arise from a grammar spec without a behavior spec. And here we are. Python doesn't do anything useful with the types, but third-parties are left to their own devices.
The issue that I have with Python type hints is they they don't go nearly far enough in describing the data being manipulated. Specifically, I'm thinking of stuff like the dimensionality and cardinality of Numpy arrays or Pandas frames. Usually that's the stuff where I have most questions when I look at Python code and the type system as it's being used now offers no help there.
The issue that I have with Python type hints is they they don't go nearly far enough in describing the data being manipulated. Specifically, I'm thinking of stuff like the dimensionality and cardinality of Numpy arrays or Pandas frames. Usually that's the stuff where I have most questions when I look at Python code and the type system as it's being used now offers no help there.
You just need those libraries to embrace it really, then you could theoretically have type constructors that provide well-typed NxM matrix types or whatever, allowing you to enforce that [[1,2],[3,4]] is an instance of matrix_t(2, 2).
I don't see how python could possibly make such inferences for arbitrary libraries.
Earlier quoted context omitted.
> The way everybody else seems to be going is strong typing at function interfaces, with automatic inference of as much else as can be done easily Both mypy and pyright will do that. If your function return type is annotated, they will infer the type of the receiving variable. If you have two branches where a variable can receive two types, pyright will infer the union type. Similar for None. Example: a = input() if…
> Both mypy and pyright will do that. This still makes me seethe. We have pip, poetry, conda, and more. The Python folks knew that multiple incompatible systems would arise from a grammar spec without a behavior spec. And here we are. Python doesn't do anything useful with the types, but third-parties are left to their own devices.
Python typecheckers predate in-language annotations and drove the spec, not vice versa.
The only reason to consider type hints is for a performance increase and there wasn't any mention of that. What can you really expect from using type hints accurately?
No, the reason to consider type hints is because it makes it easier to understand existing code and write new code that interacts with it correctly. Comprehensibility and correctness are more important than performace.
Crystal is compiled with static typing but looks like Ruby. The type specification it uses emulates gradual typing of dynamic languages.