Python with type hints still lacks the performance benefits of static typing in a compiled language setting?
You generally don't write Python if you want it to be really fast anyway (non-Python parts like numpy notwithstanding).
Python developers are embracing type hints
271–280 of 581 posts
Re: Python developers are embracing type hints
#272Earlier quoted context omitted.
> The thing that finally got me on board with optional type hints in Python was realizing that they're mainly valuable as documentation. > But it's really valuable documentation! Knowing what types are expected and returned just by looking at a function signature is super useful. So ... you didn't have this realisation prior to using Python type hints? Not from any other language you used prior to Python?
I didn't. I've been mainly a Python, PHP and JavaScript programmer for ~25 years and my experience with typed languages was mostly pre-type-inference Java which felt wildly less productive than my main languages.
That was more because of Java than static typing.
Re: Python developers are embracing type hints
#273I like the type hints. The're not perfect and they've changed a lot between versions, but they really help catch issues early that you'd usually need to write unit tests for. Adding type hints is easier than writing those unit tests.
Then you can focus your tests on more interesting things
You just need to set your build up to actually do the checking as type hints by default are just documentation
Re: Python developers are embracing type hints
#274As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages. When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.
Coming from Java extreme verbosity, I just loved the freedom of python 20 years ago. Working with complex structures with mixed types was a breeze. Yes, it was your responsibility to keep track of correctness, but that also taught me to write better code, and better tests.
Writing tests is harder work than writing the equvalent number of type hints though
Re: Python developers are embracing type hints
#275I like the type hints. The're not perfect and they've changed a lot between versions, but they really help catch issues early that you'd usually need to write unit tests for. Adding type hints is easier than writing those unit tests. Then you can focus your tests on more interesting things You just need to set your build up to actually do the checking as type hints by default are just documentation
My main complaint about them is no first-party support for type checking, you need external packages like beartype decorators.
Re: Python developers are embracing type hints
#276Python's dynamic nature can make it quite difficult to express some things correctly. That, or the type checkers have issues when it comes to understanding what would be considered safe in other languages. Years ago when I knew far less about types and programming, I never had such problems in for example Java. It was sometimes stupid, but I always found a way to express things. Although it could also be, that I merely want more out of inference and and safety. For example recently I wanted a pipeline of steps, but the steps could have any input and output type, as long as that type aligns with the previous step's types and the type checker should also know what the final output type is, and I additionally wanted it to work so that I don't have to add all the steps at once, so that I can construct the pipeline step by step. Tried for hours, but didn't find a working solution that type checks. Also tried with the help of LLMs, which gave superficially looking great code for this, but then there was always some type error somewhere, and they struggled to fix that. Ultimately, I gave up on the type checking between steps and output type of the pipeline, as I realized, that I invested hours into something that might be impossible or way waaay too much work for what I get from it. I would not have spent any time on this without type annotating and would have simply gone with a dynamic solution.
Re: Python developers are embracing type hints
#277Earlier quoted context omitted.
No idea about Python type system, but doesn't it have anything like this? interface IntIndexable { [key: number]: any }
It does! You can specify a protocol like this: class IntIndexable(Protocol[T]): def __getitem__(self, index: int, /) -> T: ... (Edit: formatting)
[deleted]
Re: Python developers are embracing type hints
#278As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages. When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.
OTH I only came to realize that I actually like duck typing in some situations when I tried to add type hints to one of my Python projects (and then removed them again because the actually important types consisted almost entirely of sum types, and what's the point of static typing if anything is a variant anyway). E.g. when Python is used as a 'scripting language' instead of a 'programming language' (like for writin…
Sounds to be more of a symptom of the types of programs and functions you have written, rather than something inherent about types or Python. I've never encountered the type of gerry-mangled scenario you have described no matter how throwaway the code is.
Re: Python developers are embracing type hints
#279Earlier quoted context omitted.
I like Python a lot, and have been using it for personal projects since about 2010. It was only once I started working and encountering long-lived unfamiliar Python codebases regularly that I understood the benefits of type hints. It's not fun to have to trace through 5 or 6 different functions to try to figure out what type is being passed in or returned from something. It's even less fun to find out that someone ma…
> It's not fun to have to trace through 5 or 6 different functions to try to figure out what type is being passed in or returned from something. My position is that what is intended must be made clear between type hints and the docstring. Skipping this makes for difficult to read code and has no place in a professional setting in any non-trivial codebase. This doesn't require type hints to achieve. :param and :rtype…
I agree, although I've found that correct and comprehensive use of the doctoring for this purpose has not existed in the environments I've worked in, or the open source codebases I have needed to understand. Something about type hinting makes people more likely to do it.
Re: Python developers are embracing type hints
#280Earlier quoted context omitted.
Would you? Why? Python has a great experience for a bunch of tasks and with typing you get the developer experience and reliability as well.
> Why? Python’s 3 traditional weak spots, which almost all statically-typed languages do better: performance, parallelism and deployment.
None of those things are to do with typing. Python is slow because it's interpreted, bad at parallelism because of the GIL (which is going away), and bad at deployment because of the messy ecosystem and build tools (although it's pretty good with Nix). Conversely other languages aren't good at those because of static typing.
It is a great choice though for many problems where performance isn't critical (or you can hand the hard work off to a non-Python library like Numpy or Torch). Typing just makes it even better.