enforce VS pyright

Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.

Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.

> type hints are not binding.

There are projects [0][1] that allow you to enforce type hints at runtime if you so choose.

It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.

> Type checking is your job after all, ...[and that] requires maintenance.

There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.

> There is an Any type and it renders everything useless

I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.

> Duck type compatibility of int and float

The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".

> Most projects need third-party type hints

Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.

> Sadly, dataclasses ignore type hints as well

Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).

> Type inference and lazy programmers

The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].

> Exceptions are not covered [like Java]

I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.

[0] https://github.com/RussBaz/enforce

[1] https://github.com/agronholm/typeguard

[2] https://github.com/microsoft/pyright

[3] https://pydantic-docs.helpmanual.io

[4] https://github.com/tiangolo/fastapi

[5] https://github.com/microsoft/pyright/blob/main/docs/configur...

[6] https://mypy.readthedocs.io/en/stable/config_file.html#confv...

Not by default. But there are libraries to enforce types. https://github.com/RussBaz/enforce or/and https://pydantic-docs.helpmanual.io/

Pyright is a fast type checker meant for large Python source bases. It can run in a “watch” mode and performs fast incremental updates when files are modified.

However, I made it faster for my use-case by changing some settings. Neovim allows to have these settings in the setup function for LSP. I was trying to figure out how do I change these settings with doom emacs. Pyright docs suggest to have these settings in pyrightconfig.json.

Not exactly what you are looking for but maybe useful to others.

https://github.com/microsoft/pyright/blob/main/docs/mypy-com...

You can use pyright instead[0]. It is the FOSS version of pyright, but having some features missing.

[0]: https://github.com/microsoft/pyright

Unfortunately, pyright explicitly stated that they are not interested in inlay hints or other language server features, that those will only be added to pylance. That's why I added it myself instead of submitting a pull request to pyright. See https://github.com/microsoft/pyright/issues/4325

return { -- add pyright to lspconfig { "neovim/nvim-lspconfig", ---@class PluginLspOpts opts = { ---@type lspconfig.options servers = { -- Listed servers will be automatically loaded to buffers jsonls = { settings = { json = { format = { enable = true, }, }, validate = { enable = true }, }, }, pyright = { settings = { python = { analysis = { -- https://github.com/microsoft/pyright/blob/main/docs/settings.md autoSearchPaths = false, useLibraryCodeForTypes = true, diagnosticMode = "openFilesOnly", }, }, }, }, }, -- Add folding capability to use LSP for ufo plugin capabilities = { textDocument = { foldingRange = { dynamicRegistration = false, lineFoldingOnly = true, }, }, }, }, }, }

[{ "resource": "/Documents/Coding/VSCode/Projects/Photoeditor/PhotoEditor.py", "owner": "_generated_diagnostic_collection_name_#0", "code": { "value": "reportMissingModuleSource", "target": { "$mid": 1, "external": "https://github.com/microsoft/pyright/blob/main/docs/configuration.md#reportMissingModuleSource", "path": "/microsoft/pyright/blob/main/docs/configuration.md", "scheme": "https", "authority": "github.com", "fragment": "reportMissingModuleSource" } }, "severity": 4, "message": "Import \"requests\" could not be resolved from source", "source": "Pylance", "startLineNumber": 2, "startColumn": 8, "endLineNumber": 2, "endColumn": 16 }]

I don't use astro, but you can configure pyright by using a pyrightconfig.json or directly in the LSP configuration.

I prefer jedi over pyright as pyright has crippled documentation support outside of VSCode. I also found jedi is make correct suggestions based on inferred type in some situations where pyright would need type annotation to provide completions, pyright is significantly faster though. Jedi with mypy and flake8 is comparable to pyright I think, but unfortunately mypy wasn't working over tramp. Also isort wasn't working over tramp, but jedi, black, importmagic and flake8 all worked.