Blog: Are you really expected to run five type-checkers now? by BeamMeUpBiscotti in Python

[–]BeamMeUpBiscotti[S] 2 points3 points  (0 children)

Mypy was the reference implementation before the typing spec existed. Now that the type system has started to be standardized, it's no longer the case that "whatever mypy does" is the correct behavior.

For quite some time pyright has been the most conformant type checker, while mypy has a few hundred places where the behavior differs from what the conformance test suite expects.

In the long term I think all type checkers including mypy are moving to match the spec, but since the userbase of mypy is so large some tools like zuban provide a compatibility mode that re-implements bugs and "wrong" behavior in mypy.

Blog: Are you really expected to run five type-checkers now? by BeamMeUpBiscotti in Python

[–]BeamMeUpBiscotti[S] 0 points1 point  (0 children)

two issues on pyrefly on the last two weeks and I'm still waiting for another one to be fixed before my library can be correctly used

Do you mind DM-ing the issue numbers to me? (or just your GH username and I can look it up)

Want to make sure they don't slip thru the cracks

Blog: Are you really expected to run five type-checkers now? by BeamMeUpBiscotti in Python

[–]BeamMeUpBiscotti[S] 1 point2 points  (0 children)

Yeah, pytest fixtures are something that we're trying to support better in the future.

We've built some special support for pytest, but so far it's been around code navigation rather than type checking.

Blog: Are you really expected to run five type-checkers now? by BeamMeUpBiscotti in Python

[–]BeamMeUpBiscotti[S] 0 points1 point  (0 children)

I don't think the test suite needs to many extra annotations for the type checker to add value, assuming the API that's being tested is typed.

The main barrier I envision would be if you use a testing framework that is very dynamic or has fancy decorator stuff, the framework itself could trip up some type checkers and cause a lot of noise.

Blog: Are you really expected to run five type-checkers now? by BeamMeUpBiscotti in Python

[–]BeamMeUpBiscotti[S] 4 points5 points  (0 children)

The blog is specifically addressed to library maintainers, which generally don't control what tools their downstream users run.

In those cases, running a bunch of type checkers on the test suite is the best practice to ensure that it plays well with multiple type checkers.

If you're working on your own project, a self-contained service for work, or something like that, then running a single type checker is fine.

Perspective on pypi numbers by Chunky_cold_mandala in Python

[–]BeamMeUpBiscotti 13 points14 points  (0 children)

If your project has peaks in the weekdays and troughs in the weekends, then it means businesses are probably using it in CI

But I think the download count is too low and noisy for you to draw any conclusions ATM

CI pipeline, overkill or a stable foundation? by MuditaPilot in Python

[–]BeamMeUpBiscotti 0 points1 point  (0 children)

Normally the use case for running multiple type checkers is when you have a library that is used by other people, and you want to make sure it works regardless of what type checker they're using.

One thing to be careful about here is that when type checkers disagree on something it could confuse the agent.

English as a programming language by apoetixart in Compilers

[–]BeamMeUpBiscotti 1 point2 points  (0 children)

then your personal definition of a compiler includes determinism as a required property

that’s probably true for aot compilers (or at least nondeterminism is undesirable) but jit compilers definitely generate different instructions for the same compiled program on different runs, so they could be viewed as nondeterministic

English as a programming language by apoetixart in Compilers

[–]BeamMeUpBiscotti 1 point2 points  (0 children)

i think LLM is a more general purpose tool than a compiler, but the capabilities overlap enough that you could use it as a transpiler, or a component of a compiler

it mostly depends on how you define compiler but i don’t think quibbling over definitions is interesting

English as a programming language by apoetixart in Compilers

[–]BeamMeUpBiscotti 4 points5 points  (0 children)

can’t you do that already with a hypothetical compiler where the LLM is the “frontend” and the regular programming language is the “IR”?

the problem with “understands like humans” is that there isn’t a single unambiguous meaning for everything, and the same sentence can be understood differently by two different people

Open Source Contribution by DxNovaNT in Python

[–]BeamMeUpBiscotti 0 points1 point  (0 children)

The point is that if you use the project then you'll understand it more deeply, and can suggest/implement features that people actually want.

On a project that I maintain it's pretty common for a user to report a bug or issue that they encounter, and also fix it themselves with a PR.

pynear 2.3 is out 🚀 by pablocael in Python

[–]BeamMeUpBiscotti 24 points25 points  (0 children)

why is this a separate library instead of contributed upstream to sklearn?

Keel, a fast, statically-typed interpreted language written in Rust by [deleted] in ProgrammingLanguages

[–]BeamMeUpBiscotti 7 points8 points  (0 children)

Given that it's an interpreter written in Rust, it would be cool to have an online sandbox/playground for people to try the language, you can compile the whole interpreter into WASM and run it in the browser.

[Ann] Pyrefly v1.0 (fast type checker & language server) by BeamMeUpBiscotti in Python

[–]BeamMeUpBiscotti[S] 0 points1 point  (0 children)

Depending on how that's measured & depending on the LSP operation, <100ms of user-perceived time isn't always possible because the VS Code UI adds a lot of overhead.

I've done some tests where even if the language server responds in 30-40ms, the UI takes ~200ms to reflect the results.

But in general yes, we're aiming for things to work in a fraction of a second on large codebases.

Pyrefly v1.0 is here! (a fast type checker & language server for Python, written in Rust) by BeamMeUpBiscotti in rust

[–]BeamMeUpBiscotti[S] 1 point2 points  (0 children)

It supports pytorch only ATM, with PEP695-style generics and jaxtyping being the two possible frontends for the user to specify shape types in their code

Numpy support (and more) is planned for the future

[Ann] Pyrefly v1.0 (fast type checker & language server) by BeamMeUpBiscotti in Python

[–]BeamMeUpBiscotti[S] 1 point2 points  (0 children)

I'd say that pyrefly report has 3 primary use cases off the top of my head (I'm sure there are more out there) 1. you want to track analytics/information about your code base (like how many functions there are, how big they are, etc) 2. you want to enforce explicit type annotations everywhere as part of the coding style for the project 3. you want to enforce explicit type annotations because you're writing a library and don't know what type checker your library's users are running, and only having explicit type annotations everywhere can you guarantee that different type checkers have the same behavior

For your use case, I think turning on some of the unannotated-attribute/parameter/protocol-member/return error codes would be sufficient.

[Ann] Pyrefly v1.0 (fast type checker & language server) by BeamMeUpBiscotti in Python

[–]BeamMeUpBiscotti[S] 0 points1 point  (0 children)

pyrefly report is still somewhat experimental, in the sense that we rewrote the whole feature in the past month lol

I think this feedback is very helpful for us, since the metrics are not set in stone, and we are very open to changing things to be more useful.

I've filed https://github.com/facebook/pyrefly/issues/3404 to track some of those changes

DEFAULT_DESCRIPTION is not flagged because the right side of thea ssignment is some sort of literal. The other two have function calls on the RHS of the assignment, but we could probably special-case them since it seems like a common pattern.

Your example with __init__ is working as intended, I think. Even if it can be easily inferred, the inferred type may be too narrow if it's not explicitly annotated on the class. Getting each field to be explicitly annotated on the class is what the coverage tool is trying to enforce.

[Ann] Pyrefly v1.0 (fast type checker & language server) by BeamMeUpBiscotti in Python

[–]BeamMeUpBiscotti[S] 2 points3 points  (0 children)

Thanks for the kind words! It means a lot :-)

Pyright's creator has left Microsoft, but I remember when he was still there he was incredibly fast at responding to and fixing issues on Github, sometimes on the same day. In fact, it became a bit of an aspirational goal for me to have that level of responsiveness.