Replies: 1 comment
-
Fascinating. I was wondering when someone was going to notice how strongly @beartype diverges from strict conformance with PEP 673. To be blunt, this is entirely intentional. @beartype is a pragmatic type-checker; that's why it runs at runtime rather than static analysis time. @beartype intentionally rejects those aspects of typing standards that are actively harmful to real-world quality assurance. As example, @beartype rejects the PEP 484-compliant implicit numeric tower by default, because accepting that by default would invite a silent loss of precision in numerical APIs, which would be actively harmful to real-world quality assurance; instead, @beartype allows end users to explicitly enable the implicit numeric tower by configuring @beartype accordingly (e.g., as Static type-checkers like What Are You Talking About, @leycec?...heh. I kinda just rambled incoherently there, didn't I? Please don't answer that. What I am trying to say here is that most of the common use cases that PEP 673 rejects are actually valid use cases that PEP 673 should have instead accepted. These include:
class Foo:
# Rejected (Self is treated as unknown).
def has_existing_self_annotation(self: T) -> Self: ... I literally have no idea why @beartype should even reject that, in theory. What does
You... Kinda Have a Point There, @leycecI know, right? I kinda do. So... why didn't PEP 673 just accept those use cases then if they're supposedly so valid? Because PEP 673 was authored only for static type-checkers. The intended audience is In the case of PEP 673, most of the use cases that PEP 673 rejects are rejected merely because they're hard for static type-checkers. But that's a bad reason to reject those use cases. The rest of the use cases that PEP 673 rejects are rejected purely for ideological reasons. But that's also a bad reason to reject those use cases. Type-checking isn't about purity. It's about practicality. Purity is the enemy of type-checking, because purity invites nonsensical false positives that waste everyone's time. @beartype always errs on the side of practicality. This is the way. Thus spake the bear. 💪 🐻 Oh – and thanks so much for submitting this fascinating discussion topic, @dkamm. I love rambling at voluminous length about the intersection of philosophy and quality assurance. You can probably tell that I'm a utilitarian pragmatist at heart rather than a Platonic idealist. Go, go, greatest good for the greatest number! QA forevah. |
Beta Was this translation helpful? Give feedback.
-
I believe this FAQ example from "the current class" recommends an invalid use of
Self
because it returns a concrete type. See https://peps.python.org/pep-0673/#valid-locations-for-selfSeems like Forward Reference or Postponed Evaluation is necessary for these cases
Beta Was this translation helpful? Give feedback.
All reactions