Hacker News Reader

Comment by SushiHippie | Hacker News Reader

For typing **kwargs there are TypedDicts https://peps.python.org/pep-0692/

If your function just wraps another you can use the same type hints as the other function with functools.wraps https://docs.python.org/3/library/functools.html#functools.w...

View on HN

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.

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.

They need to embrace the LSP

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'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.

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.

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"?..

Well on Pycharm 2022.3 which is what I still have installed even this simple function doesn't show any error.

  def foo() -> int:
      pass

I sure hope they improved the type checker in later versions...

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.

https://mypy.readthedocs.io/en/stable/stubs.html#using-stub-...

> Um lol what do you think the error is here? This is widely accepted syntax for a stub.

No it isn't. The accepted stub syntax is an ellipses (...).

A competent type checker like pyright will error on this code.

  Function with declared return type "int" must return value on all code paths
    Type "None" cannot be assigned to type "int"

And if you need more proof that pycharm is useless as a type checker:

  def foo(b) -> int:
      if b:
          return 1

A classic error where you forget to return a value from all paths and pycharm is silent.

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:

And why would I care about mypy docs? pyright does the correct thing by showing an error.

In any case, the second example is definitely not a stub.

this is the weirdest "head in sand" moment; you literally called out mypy as a desirable alternative

>And to add insult to injury Pycharm doesn't even have a pyright plugin and the mypy plugin is extremely slow and buggy.

ie you recognize that aligning with mypy is desirable.

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.

Each type checker can implement however strict rules it wants. And pyright gives the correct answer here:

  Expression of type "None" cannot be assigned to declared type "int"
    Type "None" cannot be assigned to type "int"

It's not recommended anymore. Optional types should be explicit. https://peps.python.org/pep-0484/#union-types

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.

There is also typing.ParamSpec when the purpose is to write a generic wrapper:

https://docs.python.org/3/library/typing.html#typing.ParamSp...

I think pep 612 is trying to make the ergonomics better for the 'forwarding' / pass-through case (when .wraps isn't appropriate)

https://peps.python.org/pep-0612/

Interesting, looks like they ended up having to introduce typing.Unpack, to differentiate the ambiguity with the the TypedDict referring to the type of all the kwargs, vs just Mapping[str, TypedDict]

Not ideal but not too bad either.

In this section, what is this slash in the function definition for the second foo() ?

https://peps.python.org/pep-0692/#keyword-collisions

Reply on news.ycombinator.com