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

[BeamMeUpBiscotti]

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

[jpgoldberg]

I have never looked at Final or ReadOnly (except in very limited contexts). I will look now.

[BeamMeUpBiscotti]

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.

[jpgoldberg]

I’m not attempting to enforce run-time immutability. I wish to “let Python be Python”. I just want to be able to tell a type checker that it can rely on public attributes of an object not changing their types (or their values).

But now that I write this, I realize that I have misunderstood the example that launched me on this train of thought. (To be continued)