[Upstream Bug] VSCode + Pylance + Pyright linter errors on "beartype.typing.TypeAlias"

[rbroderi]

I get errors when trying to use the beartype.typing.TypeAlias instead of typing.TypeAlias,
here are some of the error messages I get:
Key: TypeAlias = str
Expression of type "Type[str]" cannot be assigned to declared type "TypeAlias"
"Type[type]" is incompatible with "Type[TypeAlias]"PylancereportGeneralTypeIssues

CallbackFunction: TypeAlias = Callable[[Key], Any]
Expression of type "(Unknown) -> Any" cannot be assigned to declared type "TypeAlias"
"object" is incompatible with "TypeAlias"PylancereportGeneralTypeIssues

def press(key: Key):
print(f"'{key}' pressed")
Expected class type but received "TypeAlias"PylancereportGeneralTypeIssues

[leycec]

Clearly, Pylance popped too many benzos last night.

beartype.typing.TypeAlias is literally just typing.TypeAlias. The former is a convenient synonym for the latter; the two are the exact same object. Specifically, this is how the beartype.typing subpackage declares TypeAlias

            from typing import (  # type: ignore[attr-defined]
                ...
                TypeAlias as TypeAlias,
                ...
            )

That's it. beartype.typing just imports typing.TypeAlias into itself under the exact same name. This can't be simplified any further, because this is already maximally simple. It's just a simple import, which means that Pylance can't handle even simple imports. This is where I facepalm myself repeatedly on a Reddit livestream to farm upvotes.

What We Goin' Do Is This

Would you mind filing an upstream issue against Pyright's issue tracker, @rbroderi?

You are probably now wondering why I am now talking about "Pyright," because weren't we just talking about Pylance? Right. So, Pyright is Microsoft's static type-checker. Under the hood, Pylance leverages Pyright to statically check types. The type-checking failures you've exhibited are actually being directly emitted by Pyright – not Pylance. Pylance is just forwarding Pyright complaints to you.

This is a critical issue with Pyright, which appears to be unable to cope with PEP 484-compliant implicit type aliases. That's bad, because PEP 484 is nearly a decade old. Every type checker should at least superficially support PEP 484.

To quote the PEP 484 section on type aliases:

Type aliases are defined by simple variable assignments:

Url = str
def retry(url: Url, retry_count: int) -> None: ...

Type aliases may be as complex as type hints in annotations – anything that is acceptable as a type hint is acceptable in a type alias:

from typing import TypeVar, Iterable, Tuple

T = TypeVar('T', int, float, complex)
Vector = Iterable[Tuple[T, T]]

def inproduct(v: Vector[T]) -> T:
    return sum(x*y for x, y in v)

Pyright appears to be failing at that. 🤦 🤦‍♂️ 🤦‍♀️

[leycec]

Please feel free to reopen this if there's anything tangible we can do for you, Pylance, or Pyright to make this work. I loathe closing issues unresolved – but this deflated ball is almost certainly in Pyright's court.

Oh, and thanks for the recent spate of issues! Drop us a line at the bear cave if you hit any further snags or come up with any h0t feature requests.

[rbroderi]

Thank you for the information and I will open an issue with Pyrights upstream issue tracker.

[leycec]

Thanks so much, @rbroderi. I know how time-consuming merely filing GitHub issues can be, because that's pretty much all I did last night. Monday evening, I want you back! 😅

@beartype applauds the amazing work you're doing for us all.

[rbroderi]

opened as issue microsoft/pyright#3363 on pyright. Documenting here for for discoverability.

[agucova]

Issue was closed upstream because Pyright only checks for typing.TypeAlias and won't implement deeper checking:

TypingAlias is one of a handful of special forms that pyright needs to handle early in the "binding" phase, prior to type evaluation. As such, if the symbol is imported by another module and re-exported, pyright does not know that it's the same type until it's too late. You need to import it directly from typing or typing_extensions.

Why was beartype.typing.TypeAlias created in the first place?

[leycec]

...heh. Knew it. Pyright devs seem toxic, so it's little surprise they refuse to fix their blatantly broken and PEP-noncompliant behaviour. As detailed above, PEP 484 requires type checkers to support implicit type aliases:

Type aliases may be as complex as type hints in annotations – anything that is acceptable as a type hint is acceptable in a type alias.

typing.TypeAlias is a type hint. So, any type alias of typing.TypeAlias is also acceptable as a type hint:

# Pyright should support this simple type alias.
from typing import TypeAlias
MyTypeAlias = TypeAlias
my_str_type: MyTypeAlias = str

# Pyright should support this simple type alias, too.
from typing import TypeAlias as MyTypeAlias
my_str_type: MyTypeAlias = str

Pyright doesn't support either. Ergo, Pyright violates PEP 484 – Python's core typing standard. To no one's surprise, Pyright then refuses to fix their standards violations. 😮‍💨

And Pyright's excuse for violating PEP 484...

TypingAlias is one of a handful of special forms that pyright needs to handle early in the "binding" phase, prior to type evaluation.

...is not a valid excuse. Mypy complies with PEP standards. Pyright needs to, too.

If Pyright currently can't because they're improperly handling TypeAlias "early in the 'binding' phase," then they need to stop doing that and start doing what mypy does. Ironically, Pyright is wrong; mypy is right. Low-level implementation details are no excuse for perpetuating wrong behaviour.

Why was beartype.typing.TypeAlias created in the first place?

The beartype.typing submodule is a one-for-one mapping of the typing module. Everything that typing provides, beartype.typing also provides and vice versa.

beartype.typing is a drop-in replacement for typing. Ideally, @beartype users should globally replace all importations of typing throughout their codebases with beartype.typing.

This is a good thing – not a bad thing. beartype.typing is demonstrably superior to typing in increasingly many ways. mypy supports these ways, because mypy is PEP-compliant; Pyright violates these ways, because Pyright is PEP-noncompliant.

This is why standards matter, people. Come on, Microsoft! Throw the community a bone here.

[leycec]

Reluctantly reopening, because upstream refuses to resolve their broken behaviour. It's unclear whether we can circumvent this on behalf of Pylance VSCode users – but maybe we can.

At the least, reopening this will improve discoverability and hopefully provoke some fruitful discussion.

tl;dr

Pylance VSCode users, please prefer typing.Alias to beartype.typing.TypeAlias for the moment. This isn't @beartype's fault, because we comply with PEP 484.

[leycec]

"Clever" yet paradoxically stupid idea: @beartype could probably silence this VSCode complaint by:

1. Detecting when it's being statically type-checked by Pyright.
2. If so, replacing beartype.typing.TypeAlias with typing.Any. TypeAlias is mostly semantically meaningless anyway, so just aliasing TypeAlias to Any mostly does little harm. Of course, that entirely defeats the purpose of using TypeAlias in the first place... but false positives would still be better than what's happening now.

So, something like this is what we're saying:

# In "beartype.typing.__init__":
if TYPE_CHECKING and IS_TYPE_CHECKER_PYRIGHT:
    TypeAlias = Any
else:
    from typing import TypeAlias as TypeAlias

Should work – maybe, in theory. But Pyright's kinda cray-cray, so maybe it'd still expurgate everywhere even if we feed it that.

B-b-but... How Do We Detect Pyright?

I have no idea. I doubt anyone else does, either. The usual approach is something like:

IS_TYPE_CHECKER_PYRIGHT = 'pyright' in sys.modules

Of course, that's fragile and error-prone. Thanks alot, Redmond.

B-b-but... None of the Above Works

Update: No, of course that doesn't work. Static type checkers don't actually run code. That's the whole point; they only parse.

So, @beartype has no opportunity to selectively intervene at static type-checking time in a safe way that would be apply only to Pyright. We don't want to destroy mypy as well, because mypy is fine with beartype.typing.TypeAlias. Our keyboard is hog-tied with a zip tie here.

2022: the year that just keeps on giving. </le_sigh>

[leycec]

Okay. Just begging Pyright to "go away already" is clearly an insufficient solution, despite being my preferred solution. Let's brainstorm.

I don't ❤️ VSCode, because I ❤️‍🔥 Vim. But if I did ❤️ VSCode, here's what I personally would do:

• Disable Pylance type-checking, because Pylance uses Pyright to statically type-check. Pyright violates core Python type-checking standards like PEP 484, which is bad. Specifically:
  1. Open the User Settings dialog.
  2. Search for Type Checking Mode.
  3. Find Python › Analysis: Type Checking Mode in the resulting search hits.
  4. Switch the "default rule set for type checking" to off.
• Enable mypy type-checking, because mypy complies with literally all Python type-checking standards. In fact, mypy is the de facto Python type-checking standard against which all other type checkers (including @beartype and Pyright) are measured. Specifically:
  1. Install mypy.
  2. Install the Mypy VSCode extension.
  3. Rejoice as things actually work for once.

Data scientists and machine learning specialists especially want to switch from Pyright to mypy, because many scientific Python packages ship mypy plugins describing dynamic runtime behaviour. Naturally, Pyright devs refuse to implement a comparable plugin API. 🤦

Time to Open a Can of Whoopie

Because Pylance's bad type-checking makes us look and feel bad, this is mission critical. I'm going to immediately add a new FAQ entry with this exact advice.

If someone who does ❤️ VSCode could verify that the above instructions are both valid and make this issue go away, I'll happily close this after amending our FAQ.

Thanks for all the heads up, all. Everyone rocks! 🪨

[leycec]

Glorious FAQ entry that solves everything is up.

Since pyright refuses to fix its violations of typing standards required by @beartype, our only recourse is to advise all VSCoders (...this means you) to embrace the VSCode Mypy extension. Let's pretend I actually tested those instructions. 😅

Big thanks to @rbroderi for this and the companion issue #126!

[rsokl]

Pyright devs seem toxic, so it's little surprise they refuse to fix their blatantly broken and PEP-noncompliant behaviour.

You might want to pump your brakes here a bit, my friend. pyright is basically a one-man show, which is pretty incredible when you think about how many people depend on pyright via VSCode... it probably has more (inadvertent) users than any other static type checker in the python ecosystem. Moreover, Eric is an indispensable member of the typing community, and I have found him to be quite generous with his time.

our only recourse is to advise all VSCoders (...this means you) to embrace the VSCode Mypy extension

Simply opting for the mypy VSCode extension comes with some serious downsides. Beyond pyright being much more performant than mypy speed wise (it takes mypy 60s to scan the src/ of hydra-zen vs pyright taking <6s!), pyright also supports some important typing features that mypy lacks (which would make them non-compliant with several PEPs...). These include:

• recursive types
• functools.partial (This is why jax has an opaque jit wrapper -- it returns Wrapped like a coward -- because mypy can't handle it! pyright totally handles partial'd decorators without issue)
• variadic generics
• dataclass transforms
• Self

It is absolutely bonkers how quickly (and correctly) pyright implements new typing features! For all of these reasons, I prefer pyright over mypy, even outside of the context of VSCode. (Also, did you know that pyright has a really cool tool for measuring the type completeness of a library?)

I just wanted to share this because I don't think that pyright should be underestimated in its importance nor its utility. And more generally, I just want peace and love among the various Python type-checkers, static and runtime alike ☮️

P.S. the whole time I was writing this I kept thinking of the ad

but I liked Nintendo as a kid! So I felt like a bad guy who was peddling rude, in-your-face advertising lines from the 90s while writing this 😞

[leycec]

...heh. I ❤️‍🔥 the SEGA trash talk. Also, I'm pretty sure I heard the canonical SEGA startup sound while reading that.

I hear and abide by everything my beautiful users are saying. You are not wrong, @rsokl and everyone else. In fact, you're all absolutely right. Like beartype, mypy is deficient in obvious respects. Recursive type hints are the pain point I share with you. But our deficiencies kinda make sense, right?

Eric's a Technical Fellow at Microsoft. It's his job to get Pythonic typing correct. Meanwhile, most of the rest of us in the open-source typing community are mostly unpaid open-source volunteers. It's hard to compete. We're just here for the sheer joy of type hints. ^{...how is that even a thing}

Ain't Nobody Got Time for This

Ultimately, my conundrum is that open-source volunteer time is scarce. I'd fervently love to openly embrace mypy, pyright, Google's pytype, and every other static type checker. B-b-but... I lack the bandwidth for that. Even supporting mypy is an ongoing manly struggle with destiny, deliverance, and # type: ignore[EVERYTHING-JUST-IGNORE-EVERYTHING-MYPY] debacles.

Mypy is Python's official static type checker. It's clunky, it's chunky, and it's funky. But it's also community-maintained, CLI-friendly, continuous integration (CI)-friendly, pure-Python, lightweight, and the de facto typing standard.

Pyright is none of those things. I don't know how to properly integrate pyright into either our local pytest + tox test suite or our remote GitHub Actions-based CI testing workflow – if pyright even can be. I don't even know how to properly install pyright as a system-wide package under Gentoo Linux, because pyright is crazily implemented in TypeScript (i.e., typed JavaScript) rather than pure-Python. Pyright requires node, which requires npm. Pyright is heavyweight. Pyright requires that I throw scarce resources at non-standard solutions that I personally will never leverage, because it's Vim all the way down at the @leycec cottage.

Pyright is hostile to my interests. Mypy isn't.

Honesty Rears Ugly Head on GitHub

Honestly? I truly abhor all static type checkers. Python isn't statically typed. It's dynamically typed. Trying to pretend otherwise is an exercise in futility and # type: ignore[...] spam.

I don't use static type checking in any real-world projects, because neither I nor my colleagues (...okay, it's just my beautiful wife) would tolerate the maintenance burden. I use @beartype, because @beartype imposes no burdens whatsoever. That's sorta the point, right? That's why we're here. @beartype just gets out of your way so you can get actually meaningful work done. 🧑‍🏭

The real reason @beartype supports mypy is that I can force mypy to get out @beartype's way with minimal to no effort in 2022. Sadly, the same reasoning doesn't extend to pyright.

But Reality Always Bats Last

Of course... that isn't the social reality of the situation. The social reality is, as you say, that pyright is deployed across a huge horizontal slice of Python's dev community. But the personal reality is that Microsoft isn't paying me to support pyright; they're paying Eric to support runtime type checkers like @beartype.

I want everyone to use @beartype. But everyone uses static type checkers. So, I want @beartype to support all actively maintained static type checkers. If I can enable pyright to trivially support @beartype without a vast expenditure of torturous effort on my part, I happily – nay, gleefully! – will. But... I don't know how to do that yet.

Thus, our conundrum continues. </sigh>

[leycec]

Gah! I submit; I concede; I accede. I can't let these shameful pyright incompatibilities lie. Even if it's not @beartype's fault, pyright (like mypy before it) has gracelessly made false positives @beartype's fault.

In the best interests of not looking bad and supporting the best bear bros that GitHub has to offer, I'm officially reopening both this and tangentially related issue #126. My stalwart 5-Day Plan towards a stunning victory against the tyranny of static type-checking is as follows:

1. Package the newest stable release of pyright for Gentoo Linux. Done. I can now actually run pyright, everyone. Rejoice! I even made a Gentoo eclass trivially automating packaging of arbitrary Node.js packages, should anyone be interested. Let's nerd out together. 🤓
2. Silence pyright-specific error codes. Thankfully, pyright supports a # pyright: ignore[{PyrightErrorCode1},...,{PyrightErrorCodeN}] comment pragma for doing so on a line-by-line basis. I note the following "errors":

$ pyright beartype
No configuration file found.
No pyproject.toml file found.
stubPath /home/leycec/py/beartype/typings is not a valid directory.
Assuming Python platform Linux
Searching for source files
Found 178 source files
pyright 1.1.254
/home/leycec/py/beartype/beartype/meta.py
/home/leycec/py/beartype/beartype/_decor/decorcore.py
  /home/leycec/py/beartype/beartype/_decor/decorcore.py:159:6 - error: Function with declared type of "BeartypeableT@beartype_object_safe" must return value
    Type "None" cannot be assigned to type "BeartypeableT@beartype_object_safe" (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/_decor/decormain.py
  /home/leycec/py/beartype/beartype/_decor/decormain.py:88:14 - warning: TypeVar "BeartypeableT" appears only once in generic function signature (reportInvalidTypeVarUse)
/home/leycec/py/beartype/beartype/_decor/_code/codemain.py
  /home/leycec/py/beartype/beartype/_decor/_code/codemain.py:636:12 - error: "func_wrapper_code" is possibly unbound (reportUnboundVariable)
  /home/leycec/py/beartype/beartype/_decor/_code/codemain.py:91:12 - warning: "STAR_IMPORTS_CONSIDERED_HARMFUL" is specified in __all__ but is not present in module (reportUnsupportedDunderAll)
/home/leycec/py/beartype/beartype/_decor/_code/codesnip.py
/home/leycec/py/beartype/beartype/_decor/_error/errormain.py
  /home/leycec/py/beartype/beartype/_decor/_error/errormain.py:292:20 - error: Argument of type "int | None" cannot be assigned to parameter "random_int" of type "int" in function "__init__"
    Type "int | None" cannot be assigned to type "int"
      Type "None" cannot be assigned to type "int" (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/_util/cache/utilcachecall.py
  /home/leycec/py/beartype/beartype/_util/cache/utilcachecall.py:315:23 - error: Invalid exception class or object
    "Iota" does not derive from BaseException (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/_util/cache/pool/utilcachepoollistfixed.py
/home/leycec/py/beartype/beartype/_util/func/utilfunccode.py
  /home/leycec/py/beartype/beartype/_util/func/utilfunccode.py:143:17 - error: Argument of type "str" cannot be assigned to parameter "message" of type "Warning" in function "warn"
    "str" is incompatible with "Warning" (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/_util/func/utilfunccode.py:243:17 - error: Argument of type "str" cannot be assigned to parameter "message" of type "Warning" in function "warn"
    "str" is incompatible with "Warning" (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/_util/func/utilfunccode.py:319:33 - error: Argument of type "str" cannot be assigned to parameter "message" of type "Warning" in function "warn"
    "str" is incompatible with "Warning" (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/_util/func/utilfunccode.py:364:41 - error: Argument of type "str" cannot be assigned to parameter "message" of type "Warning" in function "warn"
    "str" is incompatible with "Warning" (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/_util/func/utilfunccode.py:389:33 - error: Argument of type "str" cannot be assigned to parameter "message" of type "Warning" in function "warn"
    "str" is incompatible with "Warning" (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/_util/func/utilfunccode.py:405:21 - error: Argument of type "str" cannot be assigned to parameter "message" of type "Warning" in function "warn"
    "str" is incompatible with "Warning" (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/_util/hint/utilhintconv.py
  /home/leycec/py/beartype/beartype/_util/hint/utilhintconv.py:395:22 - error: Expected class type but received "object" (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/_util/hint/pep/proposal/utilpep544.py
  /home/leycec/py/beartype/beartype/_util/hint/pep/proposal/utilpep544.py:559:29 - error: Illegal type annotation: variable not allowed unless it is a type alias (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/_util/hint/pep/proposal/utilpep544.py:52:1 - error: Declaration "_Pep544IO" is obscured by a declaration of the same name (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/_util/hint/pep/proposal/utilpep544.py:112:1 - error: Declaration "_Pep544TextIO" is obscured by a declaration of the same name (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/_util/hint/pep/proposal/utilpep585.py
  /home/leycec/py/beartype/beartype/_util/hint/pep/proposal/utilpep585.py:79:9 - error: Function declaration "is_hint_pep585_generic" is obscured by a declaration of the same name (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/_util/hint/pep/proposal/pep484/utilpep484union.py
  /home/leycec/py/beartype/beartype/_util/hint/pep/proposal/pep484/utilpep484union.py:55:18 - error: Cannot access member "__getitem__" for type "Type[Union]"
    Member "__getitem__" is unknown (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/_util/hint/pep/proposal/pep484585/utilpep484585ref.py
  /home/leycec/py/beartype/beartype/_util/hint/pep/proposal/pep484585/utilpep484585ref.py:185:11 - error: Illegal type annotation: variable not allowed unless it is a type alias (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/_util/hint/pep/proposal/pep484585/utilpep484585ref.py:124:11 - error: Illegal type annotation: variable not allowed unless it is a type alias (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/_util/hint/pep/proposal/pep484585/utilpep484585ref.py:242:11 - error: Illegal type annotation: variable not allowed unless it is a type alias (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/_util/hint/pep/proposal/pep484585/utilpep484585type.py
  /home/leycec/py/beartype/beartype/_util/hint/pep/proposal/pep484585/utilpep484585type.py:55:6 - error: Illegal type annotation: variable not allowed unless it is a type alias (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/_util/mod/utilmodtest.py
  /home/leycec/py/beartype/beartype/_util/mod/utilmodtest.py:247:52 - error: Argument of type "Requirement | None" cannot be assigned to parameter "dist" of type "Requirement | str | Distribution" in function "get_distribution"
    Type "Requirement | None" cannot be assigned to type "Requirement | str | Distribution"
      Type "None" cannot be assigned to type "Requirement | str | Distribution"
        Type "None" cannot be assigned to type "Requirement"
        Type "None" cannot be assigned to type "str"
        Type "None" cannot be assigned to type "Distribution" (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/claw/_clawloader.py
  /home/leycec/py/beartype/beartype/claw/_clawloader.py:29:5 - error: "_bootstrap_external" is unknown import symbol (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/claw/_clawloader.py:468:39 - error: No parameter named "_optimize" (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/typing/__init__.py
  /home/leycec/py/beartype/beartype/typing/__init__.py:176:17 - error: "reveal_type" is unknown import symbol (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/typing/_typingcache.py
  /home/leycec/py/beartype/beartype/typing/_typingcache.py:120:23 - error: Invalid exception class or object
    "object" does not derive from BaseException (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/typing/_typingpep544.py
  /home/leycec/py/beartype/beartype/typing/_typingpep544.py:38:9 - error: "EXCLUDED_ATTRIBUTES" is unknown import symbol (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/typing/_typingpep544.py:195:13 - warning: __new__ override should take a "cls" parameter (reportSelfClsParameterName)
  /home/leycec/py/beartype/beartype/typing/_typingpep544.py:360:9 - error: "Generic" requires at least one type argument
  /home/leycec/py/beartype/beartype/typing/_typingpep544.py:430:32 - error: Cannot access member "__class_getitem__" for type "Type[Protocol]"
    Member "__class_getitem__" is unknown (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/typing/_typingpep544.py:459:37 - error: Cannot access member "__class_getitem__" for type "Type[Protocol]"
    Member "__class_getitem__" is unknown (reportGeneralTypeIssues)
  /home/leycec/py/beartype/beartype/typing/_typingpep544.py:467:37 - error: Cannot access member "__class_getitem__" for type "Type[Protocol]"
    Member "__class_getitem__" is unknown (reportGeneralTypeIssues)
/home/leycec/py/beartype/beartype/vale/_core/_valecore.py
/home/leycec/py/beartype/beartype/vale/_is/_valeisabc.py
  /home/leycec/py/beartype/beartype/vale/_is/_valeisabc.py:45:23 - error: Metaclass cannot be generic (reportGeneralTypeIssues)
31 errors, 100 warnings, 0 informations 
Completed in 8.737sec

Kinda getting the feeling that pyright isn't respecting my time here. Most or all of those appear to be false positives, especially as mypy insists everything is fine.

I exhale slowly without raising my disastrous blood pressure any higher. 😮‍💨

[leycec]

I have good news. I have bad news.

Give It to Me Straight, Doc

The good news is @beartype now officially supports pyright! Rejoice, typing gentleman – for we have vanquished a vacuous evil this day:

$ pyright beartype
No configuration file found.
No pyproject.toml file found.
stubPath /home/leycec/py/beartype/typings is not a valid directory.
Assuming Python platform Linux
Searching for source files
Found 177 source files
pyright 1.1.254
0 errors, 0 warnings, 0 informations 
Completed in 13.868sec

0 errors, 0 warnings, 0 informations, people.

_{Yes, pyright wants us to believe that "informations" is the plural form of "information." It isn't; like the few remaining hairs on my shining head, the English noun "information" is uncountable and thus has no plural. And... that should tell you everything you need to know about pyright.}

But I digress. Ultimately, this means we have resolved the related issue #126. pyright should no longer say this (...or anything, really) when confronted with @beartype in real-world code:

Type of "beartype" is partially unknown
Type of "beartype" is "Overload[(obj: BeartypeableT@beartype) ->
    BeartypeableT@beartype, (*, conf: BeartypeConf) -> 
   ((BeartypeableT@BeartypeConfedDecorator) -> 
   BeartypeableT@BeartypeConfedDecorator),
   (obj: BeartypeableT@beartype, *, conf: BeartypeConf = BeartypeConf()) -> 
   (BeartypeableT@BeartypeReturn | ((BeartypeableT@BeartypeConfedDecorator) ->
   BeartypeableT@BeartypeConfedDecorator))]"

Our upcoming beartype 0.11.0 release thus extends static type-checking support to both mypy and pyright. Pretty sure that makes us the first large-scale Python package to explicitly support both – but I'm pretty sure someone in the peanut gallery is about to prove me wrong. ^{Do it!}

Until then, please dangerously install @beartype from git to silence pyright complaints:

python -m pip install git+https://github.com/beartype/beartype.git@720d779a1a4fdb830d6374cc5dc40e6e54153042

So... How Bad Is this Bad News?

Not that bad, actually! How often does that happen, guys?

The bad news is that this issue that we are discussing here still isn't a @beartype issue, as expected. It's an upstream pyright issue. Fairly certain we can't resolve this on our end. I'd happily monkey-patch this if we could with a sketchy kludge that makes our test suite sweat bullets – but pyright is TypeScript, so there's nothing to monkey-patch.

Instead, we need pyright to do something about this. But Eric isn't inclined to do anything about this, because he's Eric. Sadly, the upstreamwontfix tag is more appropriate than even I suspected.

Do Something, You! Do Something or Face Wrath!

...yeah. I totally get it. I'd be annoyed, too.

The only consolation here is that beartype.typing.TypeAlias is just a trivial alias for typing.TypeAlias. So, please just do this for the moment:

# Instead of this...
from beartype.typing import TypeAlias

# ...please do this!
from typing import TypeAlias

# Pyright should no longer complain about this.
MyTypeHint: TypeAlias = bool | int | str | None

With apologies, I hang my head as tears stream down my dirt-streaked cheeks. Thus ends another tale of woe and debauchery in the pits of Python typing. 🥲

[rsokl]

I have bad news.

# Instead of this...
from beartype.typing import TypeAlias

# ...please do this!
from typing import TypeAlias

With apologies...

This is the least bad bad news ever; I am used to doing far worse just to get certain typing features to work across Python versions. But this just goes to show that @beartype's standards are sky high! 🚀 🚀 🚀

This is awesome! @beartype is looking real

right now. Thank you for this incredible work and for suffering through the herculean effort of supporting both pyright and mypy.

Pretty sure that makes us the first large-scale Python package to explicitly support both

You may be right! At least the first large-scale Python package that is heavily steeped in Python's typing system!

[leycec]

OMG. That apropos promo shot of a 128-in-1 MegaDrive cart stacked on a classic trash Data East SNES cart stacked on an obscure NES cart with a boss logo even I have never seen before but am now desperately scavenging Google Image for.

I see your 8- and 16-bit childhood nostalgia bit-packing and raise you... the MegaDrive Tower of Doom.

Unrelatedly, GitHub's OpenAI Codex-fueled Copilot just launched. What is this nightmare fuel in IDE form? Now paired programming is an abstract cloud-hosted quasi-daemonic entity critiquing everything I code in real time against everything Guido and Soklaski are coding in real time. That's just great, guys.

Pretty sure this timeline ends with a creepy yet wise Alan Watts AI snarkily suggesting that He will catalyze the Singularity sooner than I can release beartype 1.0.0. And what will gall the most is... Alan Watts AI will not be wrong.