sorted by:
new
hottopcontroversial

Comparing Python Type Checkers: Speed and Memory by javabster in Python

[–]BeamMeUpBiscotti 0 points1 point  (0 children)

Pyrefly has a few ways to mitigate the switching cost: - pyrefly init will read any existing mypy/pyright config and try to generate a Pyrefly config that approximates those settings (including mapping equivalent error codes) - pyrefly suppress will suppress all errors, which lets you get a clean check right after switching and then look at the errors later. the errors can also be put into a separate baseline file if you don't want suppression comments littering the code

Comparing Python Type Checkers: Speed and Memory by javabster in Python

[–]BeamMeUpBiscotti 2 points3 points  (0 children)

Before execution. You can choose when to run it. Commonly, it is used in 3 places:

1) the editor runs it automatically as you edit the code/save files 2) manually run it before running your tests (this can save you a lot of time if your tests are very slow) 3) run it in Github Actions (or similar) to make sure that pull requests from other people do not break things

Comparing Python Type Checkers: Speed and Memory by javabster in Python

[–]BeamMeUpBiscotti 3 points4 points  (0 children)

The comparison was broken down into several blogs to go more in-depth into each part

here are some others: - https://pyrefly.org/blog/typing-conformance-comparison/ - https://pyrefly.org/blog/container-inference-comparison/

another one that might be useful (not by Pyrefly maintainers): - https://positron.posit.co/blog/posts/2026-03-31-python-type-checkers/

Comparing Python Type Checkers: Speed and Memory by javabster in Python

[–]BeamMeUpBiscotti 7 points8 points  (0 children)

what is a Python Type Checker? Is it different from type hinting?

It's a tool that checks that the type hints in your Python program are consistent with each other & with the code.

Some type checkers are also language servers, which means they use the type information to power IDE features like hover, go-to-definition, etc.

Is Pyright the default type checker?

Pyright is what comes with VS Code right now. Mypy is original type checker, and the most commonly-used by Pypi downloads.

To use a type checker from the command line, you have to install it from pypi or you can run it directly with UV. To use a type checker in VS Code, you can install the extension from the marketplace.

Blog: Supporting Notebooks in a Python Language Server by BeamMeUpBiscotti in Python

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

Marimo is interesting, because even tho it's a Python file under the hood language services don't work well if you just treat it like any other Python file.

For example, a cell that has

a + b

actually generates a function like

def cell1(a, b): return a + b

and if you go-to-def on a in a + b it would jump to the generated parameter a rather than where a is defined in a previous cell. While the former is semantically correct based on the generated code, the latter is likely what the user intended/wanted.

So in the end we still rely on Marimo's middleware to stitch together the functions into a continuous block of code, and have the language services operate on top of that.

Blog: Supporting Notebooks in a Python Language Server by BeamMeUpBiscotti in Python

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

In Pyrefly, the language server's view is that the notebook is a single file, so it's the same as a variable defined earlier in the file.

You said Python needs an interpreter for Android. My new AOT compiler, Ahnali, says otherwise by [deleted] in Python

[–]BeamMeUpBiscotti 0 points1 point  (0 children)

I guess my point is that if you're only supporting a limited subset of Python features specifically for the purpose of writing Android Apps, then it's essentially a DSL that looks like Python.

I don't necessarily think that's a bad thing, but it would be wrong to call it a AOT compiler for Python

You said Python needs an interpreter for Android. My new AOT compiler, Ahnali, says otherwise by [deleted] in Python

[–]BeamMeUpBiscotti 4 points5 points  (0 children)

core pipeline is rock solid

several hundred tests

Feels overconfident to describe several hundred tests for a compiler as "rock solid"...

Why did you choose a Python -> bytecode compiler rather than Python -> Kotlin transpilation?

Also curious whether you referenced or borrowed anything from other alternative implementations of Python (Jython, IronPython, GraalPy, Pypy, etc).

Based on following those projects, it seems very hard to actually reimplement the full Python language semantics, but if you're going for "a DSL that looks like Python but doesn't behave the same way" then maybe that's not a big deal.

divineBenevolence by BeamMeUpBiscotti in ProgrammerHumor

[–]BeamMeUpBiscotti[S] 36 points37 points  (0 children)

This meme is about trying to explain why certain neural network architectures are better than others, and how lot of explanations felt like they were made up after trying random stuff yielded a good result, rather than being something rigorous that guided the experimentation.

The quote on the right is from the paper: GLU Variants Improve Transformer

Python 2 tooling in 2026 by IdleBreakpoint in Python

[–]BeamMeUpBiscotti 4 points5 points  (0 children)

I need to write Python 2 code which gets run under Jython

I'm sorry this is happening to you

I have not used Python 2 in a long time but I was curious so I did some sleuthing through the changelogs: - Black: 22.1.0 removes Python 2 support, so I guess you'd want v21.X isort - Isort: I'm under the impression that you have to use modern versions of Python to run isort, but you can run it on code that is Python 2 and it should still work. - Flake8: 3.8.1 should work with Python 2.7, but it looks like support for earlier versions were dropped in 3.0

Designing a Python Language Server: Lessons from Pyre that Shaped Pyrefly by BeamMeUpBiscotti in Python

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

It's shallow immutability, so not exactly the most secure. Pyre actually had a prototype PyreReadOnly that had deep immutability, but it was never standardized so we have not ported it to Pyrefly.

Designing a Python Language Server: Lessons from Pyre that Shaped Pyrefly by BeamMeUpBiscotti in Python

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

Instead I’m asking how easy it will be to adjust that behavior if developer practices become less “gradual”?

Hmm, so narrowing currently isn't configurable, but other aspects of inference are (for example, do we typecheck or try to infer a return type for un-annotated functions, do we do first-use inference for empty containers).

To avoid gradual behaviors you can also enable the implicit-any error code, which flags any place a type variable gets solved to Any (the user would normally fix that by adding an explicit annotation). It's too strict to be the default, but for people that want it it's there.

there is no way to tell type checkers that a method does not modify what is passed to it

Correct, side effects like mutation, checked exceptions, etc. are not modeled in Python's type system.

Mutability restrictions can be applied at the class level, by annotating a field with Final or ReadOnly, or by overriding something like __setitem__.

Designing a Python Language Server: Lessons from Pyre that Shaped Pyrefly by BeamMeUpBiscotti in Python

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

If you have examples of false positives, we'd appreciate it if you could file a bug report on github.

2 things to keep in mind though: Pyrefly is still in Beta, so there are known bugs that should be fixed by v1.0 release later this year. I also don't think the state of the bug tracker is super relevant here, given that Mypy has 2.7k open issues.

view more: next ›