While functools.wraps does propagate __annotations__ by default, be aware that not all IDE-integrated type checkers handle that properly. It's easy in PyCharm, for example, to use functools.wraps such that the wrapper function is treated by the IDE as untyped.
Underneath, this is because many (most?) type checkers for Python aren't actually running the code in order to access annotation information, and are instead parsing it "from the outside" using complex and fallible techniques of variable reliability. That said, it's a testament to JetBrains' excellent work that PyCharm's checker works as well as it does, given how crazily metaprogrammed even simple Python often turns out to be.
Pycharm has the worst type checker that exists today.
It may have been the best a few years back but others have suppressed it considerably.
I recently switched from Pycharm to vscode which uses pyright and it's night and day on the amount of type errors it catches, it considerably improved the quality of my code and confidence during refactoring.
And to add insult to injury Pycharm doesn't even have a pyright plugin and the mypy plugin is extremely slow and buggy.
It’s sad to see this happen to be honest. Seems like Jet Brains is getting distracted from their core value proposition: good IDEs. If electron based IDEs are becoming more responsive and performant than their “native” IDEs they have major priority problems.
What even distracts them? IDEs are supposedly the only thing they do. Well, maybe except for Kotlin. And it's not like their IDEs are very cheap either. I mean, not that cheep that I'd like the idea of being too much mentally invested into something, that barely competes with a free source-code editor, let alone lags behind it.
I don't actually know but my assumption is that that they're working with a very old codebase based on the "bespoke parsing and plugins for every language" paradigm that served them well for decades. Meanwhile eg VSCode is using the "language server with treesitter and queryable compiler genetically integrated over a standard API" model that's only recently become widespread.
When I first learned about LSPs it was immediately clear to me they would run circles around the "traditional" IDEs. I'd given up on using IDEs because I found them too finicky and error prone, but LSPs have been a total game changer.
I'm pretty sure they make most of their money from TeamCity build agents.
IntelliJ (the Java+ IDE) always has a community edition that is open source. I can vouch that it is truly free and not crippleware. For most Java programmer, this edition is sufficient.
There is Fleet, which they purport to be their next gen IDE. Which I haven’t even tried, though I am am avid pycharm user, so maybe it’s not getting the results they hope for?
Any examples? I don't write Python that much nowadays, and while I'm sure its type checker doesn't do everything, I kinda never felt disappointed by what it does. Maybe, a considerable part of that is that I still don't really think of Python as a type-checked language, so everything an IDE does for me still feels like quite a bit of an improvement over how I used to write code in Python for a long, long time. But really, "night and day on the amount of type errors"?..
On the other hand, Pycharm will show an error if you replace the pass keyword with any statement. Seems like a deliberate behavior - it declines to typecheck a stub.
Um lol what do you think the error is here? This is widely accepted syntax for a stub. So yes it does return None if run but it's not expected to ever be run. So pretty ironic that you would blame pycharm (which is indeed excellent) for your own misunderstanding.
I linked directly to the section of mypy docs that shows you are wrong - all you have to do is click the link to understand that you are wrong:
>(Using stub file syntax at runtime). You may also occasionally need to elide actual logic in regular Python code... You can also elide default arguments as long as the function body also contains no runtime logic: the function body only contains a single ellipsis, the pass statement, or a raise NotImplementedError(). It is also acceptable for the function body to contain a docstring. For example:
That’s not a type error in python. All types in puthon (afaik) accept ‘None’ as a value.
For example, try:
a : int = None
It will succeed. This is done (I think) so you can tell whether optional arguments are defined, declare variables before use (eg if you have a conditional with two branches both setting a different value for a variable sibce python blocks aren’t expressions) and that kind of thing.
There definitely seems to be a few areas since the Fleet announcement that have given me pause on JetBrains.
Their Python support has t kept up with other tools as noted. I’ve see a similar decline in the ability for for them to keep up to date with things like Svelte, Vue, Astro etc too.
Underneath, this is because many (most?) type checkers for Python aren't actually running the code in order to access annotation information, and are instead parsing it "from the outside" using complex and fallible techniques of variable reliability. That said, it's a testament to JetBrains' excellent work that PyCharm's checker works as well as it does, given how crazily metaprogrammed even simple Python often turns out to be.