Is the protocol caching still needed?

[jorenham]

Since Python 3.12 runtime-checkable typing.Protocol's use caching and some other tricks to achieve a ~20x speedup: python/cpython#102433

For older Python versions, typing-extensions provides a Protocol variant that includes (most of) these speedups (docs).
For what it's worth: It is used in the optype library, which I use for several of my (other) open- and closed-source projects, but I haven't had any problems with it at all (even though I tend to break everything typing related (not a threat BTW)) 🤷🏻.

I haven't done a benchmark, but regardless of the outcome, this could perhaps be a nice opportunity to make numerary more focused towards what all the cool kids are talking about these days: typing in Python 😎. Even fusion-powered quantum-blockchain AI has got nothing on us!

~

Hoping this banal participial closing causes no offense, I am,

Typically,

Joren S. Hammudoglu,
Typer of Things

[posita]

Thanks, @jorenham! As one might surmise, updates from the various metropoli of performant runtime type checking are slow to reach these backwaters of Appalachia, so we very much appreciate it when kind travelers bring news as they pass through. And please do not worry yourself on the matter of provoking offense. I try to reserve that for much more serious matters which largely ^{but tragically not absolutely} exist outside of software development.

And now for something completely different totally predictable: A rant!

It is deliberate that numerary describes itself as a "codified rant". The fundamental problem is that official "development" ^{and I use that term liberally as applied here} at the intersection of operations and types is a hot mess beyond the most trivial cases ^{and sometimes even then}. Every time I've tried to make use of a structure or feature in the standard library whose documentation is simple, authoritative, and clear, I find that the reality is anything but. There is always some unfinished corner or undeclared edge case that frustrates fitness for the purpose explicitly envisioned by the feature's designer(s).

No matter the path down which I tread, I find myself in the middle a murky swamp impassible with flora, fauna, and developers, who declare my very presence as an intrusion ^{often without patience or explanation, as if under the assumption that non-residents of that bog should magically just know to temper our understanding of the official documentation and various accepted PEPs through the lens of whatever in-the-moment, jargon-laden sentiment or "reasoning" again, used liberally casually littered throughout developer forums, mailing lists, or buried in some comment in some bug report that was closed as "not planned" five years ago}. Through lands far and wide, I have tracked and pursued ABCs, various Supports* conventions, the numeric type hierarchy, generics (to the extent Python has them), protocols, operations and dunder methods, and other head spinning chicanery like that which you've discovered. At the end of every exploration, I encounter the same small group of wizards declaring that I "shall not pass" or that my way lies "back the way I came" and that I should either be satisfied to limit my use to ints and floats or commit to explicit support of a particular third party mathematics library ^{most of which are thankfully at least more forthcoming about what is and isn't supported}.

I have a fantasy that Python 4 will be the typing-finally-works-coherently-and-we-should-be-clear-what-is-deprecated-by-getting-rid-of-everything-Python-developers-no-longer-wish-to-maintain release, but that isn't based on anything in reality and I'm not holding my breath.

In other words, I wonder if your prompt should really read, "Is the protocol caching numerary still needed?"

I love what you've done with the place. (optype just might be the new numerary!)

I would love to see performance numbers comparing Beartype's CachingProtocolMeta to 3.12's improved library version, but it's possible that numerary is no longer needed (or perhaps, more accurately, a dead-end). What I was essentially trying to capture is a way for things to declare capabilities and then allow for other things to offer functionality around those capabilities.

Unless I've misunderstood, this is precisely what optype does!

I still have yet to figure out is how to constrain secondary functionality based on the capabilities of the things on which that functionality should operate. That's probably too vague to be coherent, so an example may be in order. Consider:

R = TypeVar("R")
T = TypeVar("T")
type CanTMulR[T, R] = CanMul[T, R] | CanRMul[R, T]
type CanTAddR[T, R] = CanAdd[T, R] | CanRAdd[R, T]

class MyThingThatDoesMathLikeThingsWithOtherThings(Generic[T]):
    def __init__(self, thing: T):
        self._thing = thing
    def do_the_multiplication_thing(self, other: CanTMulR[T, R]) -> ???:
        if isinstance(other, CanRMul):
            return self._thing * other
        else:
            return other * self._thing
    def do_the_addition_thing(self, other: CanTAddR[T, R]) -> ???:
        if isinstance(other, CanRAdd):
            return self._thing + other
        else:
            return other + self._thing

There are two specific problems I don't yet know how to solve. (To be fair, numerary doesn't solve these either.)

1. How to declare/detect ^{at least statically, but ideally at runtime as well} that MyThingThatDoesMathLikeThingsWithOtherThings.do_the_multiplication_thing is unavailable if CanTMulR[T, R] doesn't resolve, but other methods may still work.
2. How to infer the return type of (e.g.) MyThingThatDoesMathLikeThingsWithOtherThings.do_the_multiplication_thing based on what T and R are (i.e., reveal_type(MyThingThatDoesMathLikeThingsWithOtherThings(2).do_the_multiplication_thing("I") yields str). Maybe something like ResultTypeForMul[T, R] | ResultTypeForRMul[R, T]? Although that isn't quite right. What I really mean is ResultTypeForMulOrRMulIfMulNotAvailable[T, R].

I don't know whether either problem is solvable given the current state of the world? The second may require some kind of "registration" mechanism? As an aside, division (__div__ and __rdiv__) has always been my go-to case, because it violates the naive assumption that A __op__ B always yields one of A or B (e.g., int / int -> float).

What do we do, tho, bro?!

Complicating a simple reversion to the standard library version is that (much of) CachingProtocolMeta is actually part of beartype. It's true that numerary provides its own work-arounds for declaring/overriding inclusion/exclusion for runtime checking, but those rely heavily on the proprietary internals of Beartype's implementation. There are a couple options I can see, pending some performance validation:

1. Revert/remove beartype's _CachingProtocolMeta and pin numerary's reliance on beartype to an upper bound where it was still present (and possibly declare numerary as officially deprecated and use its README to advocate for adopting optype instead 🥳).
2. Revert/remove beartype's _CachingProtocolMeta and remove numerary's include/exclude mechanism altogether (which means runtime type checking would be ... erm ... less correct 😬).
3. Revert/remove beartype's _CachingProtocolMeta and re-implement numerary's include/exclude mechanism such that it is self-contained within numerary.

Assuming there's no longer any performance benefit to beartype's _CachingProtocolMeta, the last option feels like the "right" thing to do ^{assuming anyone is actually using numerary for anything useful, which is probably a stretch}.

[jorenham]

Wow, that must be the best response I've ever gotten; you have my thanks 🏆 .

Every time I've tried to make use of a structure or feature in the standard library whose documentation is simple, authoritative, and clear, I find that the reality is anything but.

This is my experience as well: Seemingly simple things like binary operators, or iterations, are ridiculously to correctly type, often resulting in a mess of type aliases, protocols, overloads, typeshed PR's that get rejected for fallacious reasons, and angry neighbors telling you to stop screaming at your screen at 4 a.m...

I encounter the same small group of wizards declaring that I "shall not pass" or that my way lies "back the way I came"

I think that I have encountered this buggy endboss a couple of times as well. It's one of their special attacks that gets me, usually its either "dogma beam" or "fallacy cannon", or when they're at 1HP, they exploit a glitch that replaces them with an another, almost identical, boss.

In other words, I wonder if your prompt should really read, "Is the protocol caching numerary still needed?"

Yes, it is!
The numbers stdlib creates more problems than it solves, collections.abc doesn't seem to care about numbers, and there's that thing where at runtime you have that bool <: int, but whilst type checking it's treated as if complex <: float <: int <: bool (type-checkers allow it if you e.g. pass a bool to some def f(x: int), which is just rude to those with a bool-allergy).

Plus, there are more that one type of number; e.g. fractions.Fraction, decimal.Decimal, or any of the subtypes of numpy.number[Any].
And even when you dump you integer-like input into an int(x), you can't just accept everything that implements __int__ or __index__; e.g. numpy.ndarray implements both, but unless it is 0-dimensional, it'll raise a TypeError; which is impossible to type from within numpy itself (or at least until numpy fully supports shape typing).
I'm not sure whether this can all be covered by numerary, but I know that optype is too low-level do even come close.

Relying on typeshed alone won't do you much good either, as they're just typed versions of the runtime.
But what's needed is a bridge between the world of runtime and the world of typing.
That bridge will have to be shaped like a bunch of typing protocols that are flexible, but not too loose: Stiff bridges break, loose bridges wobble.
And currently, many people attempt to use the numbers lib as a bridge, even though it's made of moldy cardboard and duct-tape.

There are two specific problems I don't yet know how to solve. (To be fair, numerary doesn't solve these either.)

1. How to declare/detect at least statically, but ideally at runtime as well that MyThingThatDoesMathLikeThingsWithOtherThings.do_the_multiplication_thing is unavailable if CanTMulR[T, R] doesn't resolve, but other methods may still work.
2. How to infer the return type of (e.g.) MyThingThatDoesMathLikeThingsWithOtherThings.do_the_multiplication_thing based on what T and R are (i.e., reveal_type(MyThingThatDoesMathLikeThingsWithOtherThings(2).do_the_multiplication_thing("I") yields str). Maybe something like ResultTypeForMul[T, R] | ResultTypeForRMul[R, T]? Although that isn't quite right. What I really mean is ResultTypeForMulOrRMulIfMulNotAvailable[T, R].

How about something like this?

from __future__ import annotations

from typing import Any, Generic, TypeVar, overload
from optype import CanMul, CanRMul

_T_co = TypeVar('_T_co', covariant=True)
_R = TypeVar('_R')
_RHS = TypeVar('_RHS')


class SomeThingThatDoesMathLikeThingsWithOtherThings(Generic[_T_co]):
    def __init__(self, thing: _T_co) -> None:
        self._thing = thing

    @overload
    def do_the_multiplication_thing(
        self,
        other: CanRMul[_T_co, _R],
    ) -> _R: ...
    @overload
    def do_the_multiplication_thing(
        self,
        other: CanMul[_T_co, _R],
    ) -> _R: ...
    @overload
    def do_the_multiplication_thing(
        self: SomeThingThatDoesMathLikeThingsWithOtherThings[CanMul[_RHS, _R]],
        other: _RHS,
    ) -> _R: ...
    def do_the_multiplication_thing(
        self,
        other: CanRMul[_T_co, _R] | CanMul[_T_co, _R] | Any,
    ) -> _R:
        if isinstance(other, CanRMul):
            return self._thing * other
        if isinstance(other, CanMul):
            return other * self._thing
        return self._thing * other

Complicating a simple reversion to the standard library version is that (much of) CachingProtocolMeta is actually part of beartype. It's true that numerary provides its own work-arounds for declaring/overriding inclusion/exclusion for runtime checking, but those rely heavily on the proprietary internals of Beartype's implementation. There are a couple options I can see, pending some performance validation:

Purely in terms of isinstance speed, the Python 3.12+ runtime-protocols are great.
But because of that, they are very imprecise, and often result in false-positives, of which many should be easily avoidable.

So consider the following standard boilerplate code for some regular business application:

from typing import SupportsIndex, Self


class SomethingPositiveYouCanCountOn:
    """
    >>> _ = SomethingPositiveYouCanCountOn()
    >>> +_
    +_
    >>> ++++_
    ++++_
    """
    def __init__(self, /, *, _start: SupportsIndex = 0) -> None:
        self._value = int(_start)

    def __pos__(self) -> Self:
        return type(self)(_start=self._value + 1)

    def __repr__(self) -> str:
        return '+' * self._value + '_'


class SomethingThatLooksPositiveButIsNot:
    __pos__ = NotImplemented

How can we want to predict whether some x can have a + in front of it, but without actually trying it (i.e. what you do in practice if you want to avoid side-effects, e.g. sloths taking over the world, forcing humans to act as their trees).

Runtime-protocols are the way to go here:

>>> from optype import CanPos
>>> isinstance(SomethingPositiveYouCanCountOn(), CanPos)
True

Now let's check SomethingThatLooksPositiveButIsNot:

>>> isinstance(SomethingThatLooksPositiveButIsNot(), CanPos)
True

Ouch.

So let's check what every 3-year old python developer knows: that even if __pos__ is implemented, +x can only be used on the instance, but not on the type itself

>>> isinstance(SomethingThatLooksPositiveButIsNot, CanPos)
True

So yes, a better typing.Protocol might be a good idea 🦥

[posita]

So this was kind of rad (cc @leycec; hat tip to @AlexWaygood for the beartype mention; apologies that I'm only just now getting caught up on all of this):

Given that behaviour, it could well be reasonable to slap a cache on the whole _ProtocolMeta.__instancecheck__ call, similar to the way beartype does it... .

I also missed this:

FYI, all the changes that have been made to typing_extensions.Protocol in v4.6.0 are also going to be included in typing.Protocol in Python 3.12. The changes (to both typing.Protocol and typing_extensions.Protocol) were mostly made in order to achieve a 20x speedup for isinstance() checks against runtime-checkable protocols.

As well as the fact that typing_extensions.Protocol is much faster than typing.Protocol on <3.12, typing_extensions also backports several significant bugfixes that have been made to typing.Protocol in recent Python versions, but haven't been backported as far as Python 3.8.

If I'm reading that right, using typing_extensions.Protocol for Python <3.12 may very well be good enough to sunset beartype.typing._typingpep544._CachingProtocolMeta. I still want to do some perf testing, though. This would have to be optional, meaning maybe beartype could use the typing_extensions.Protocol if available, but I don't think it would (or should) tolerate a dependency.

However, based on your examples, @jorenham, (which are unsurprising to those who know how __instancecheck__ is implemented), I think numerary's registration bit may still be needed. I would love it if this could be done via Python's existing machinery. However, while ABCMeta allows explicit registration to avoid false negatives, it does not afford explicit exclusion to avoid false positives like the ones you identify. Without realizing it, numerary ended up trying to implement what turned out to be an old idea (cf. this, this, and this).

I'll try to tinker some more once I can carve out some time.

[AlexWaygood]

Yeah, would definitely encourage y'all to do detailed perf testing before making any decisions. We made a ton of optimisations to isinstance() checks against typing.Protocol in 3.12 and they're way faster than they were in 3.11, but:

• They're still really slow compared to isinstance() checks against other classes
• For a runtime-checking protocol with many protocol members (15 or 20), I think they're actually slower than they were in 3.11
• We don't do caching to the same degree as beartype because we have to be backwards compatible with behaviour on previous Python versions
• Not all optimisations could be backported to typing_extensions: some of the optimisations were achieved by optimising inspect.getattr_static, and those couldn't be realistically backported to typing_extensions.

There's a benchmark script in the PR description for python/cpython#103280 (comment) that you might find useful

[leycec]

Since Lithuanian breakdancer Dominika Banevič just got robbed in the B-Girls Olympics gold medal Breaking battle, I must now console myself with some fast-acting GitHubbing. I drain my sorrows in keyboard warrioring. </ahem> What I meant to say was:

Thanks so much, @AlexWaygood! That PR benchmark script is especially awesome. If CPython's official typing.Protocol implementation is anywhere near @beartype's mostly unmaintainable beartype.typing.Protocol implementation, I'll delightedly kick the latter to the curb. While that cat is fast as lightning, @beartype's current approach is also:

• Badly broken for class methods. I noticed a year or two ago that beartype.typing.Protocol silently ignores class methods, whereas typing.Protocol appears to properly detect class methods. In theory, beartype.typing.Protocol could be fixed to properly detect class methods as well. In practice, it might be preferable to just amputate this gangrenous limb from the @beartype codebase and let somebody else who is smarter than me maintain this special madness.
• Unmaintainable. Let us never forget that.

Will @leycec actually do something? Will @posita save the bitter day? Stay tuned as we all just watch more caustic Olympics.

[posita]

Apologies for losing the thread (well beyond this discussion, but that's a more personal story for another time), even after @jorenham's very polite nudge. 😬

I'd like to pick this up, with a few goals in mind, that might mean something very different for numerary (possibly including its demise). Specifically:

1. I would like to have something capable of "inferring" operator result types from arbitrary operand types. I use scare quotes to indicate a very broad (perhaps even vague) application of "infer". This could include automated generation of files for interactions among user-provided types.
2. I would like those result types to be both statically and runtime type-check-able.

I'm sure there are twisted counter-examples, but what I basically want is something to take, e.g., a sympy.Float and a decimal.Decimal and figure out all the workable operator combinations such that type checkers "know" that when multiplying the two, you'll get a sympy.Float. A more complicated example is to be able to determine the type of the result of, e.g., multiplying a numpy.array created from non-numpy (user-defined) types with another non-numpy (user-defined) type.

I feel like we're almost there, that somewhere in the Lovecraftian void between optype and numerary--that one can't quite glimpse except for just a nauseating moment at the margins of one's periphery--lives a dark solution that can be called forth into this plane of existence through some ancient rite. (It's also quite possible optype does this already, and I lack sufficient understanding.)

Consider something like the following, where the author doesn't know about sympy and never contemplated use with decimal.Decimal:

# ...
class Thing[_T](...):
    def __init__(self, v: _T):
        self.v = v
    def __mul__[_RT](self, r: _RT) -> Thing[Mul[_T, _RT]]:
        return Thing(self.v * r)

A user of Thing wants to try it with sympy.Floats and decimal.Decimals and finds it works perfectly well at runtime. However, the user also wants type checking without having to bug the author of Thing. Maybe they can do something like this:

% gen_op_types --reciprocol --output my_op_types.py sympy.Float decimal.Decimal  # --reciprocol tries each type as both the left and right operand of binary operators

include my_op_types  # ???
reveal_type(Thing(decimal.Decimal('1')) * sympy.Float(1))  # -> Thing[sympy.Float]

I think leaning on type checkers alone isn't going to get this done for a variety of reasons^{of which I've ranted far too many times to remember, much less usefully reproduce here}, but I do think it's possible (or at least "good enough" in many cases) to observe resulting types by actually trying operators with operands. If there's a way to move from that observation to the expansion/interpretation of generic type definitions, I think we have a shot.

Given the deterioration of my gray matter, this, of course, is likely: a) not feasible; b) the worst idea ever; or c) both.

[jorenham]

Consider something like the following, where the author doesn't know about sympy and never contemplated use with decimal.Decimal:

# ...
class Thing[_T](...):
    def __init__(self, v: _T):
        self.v = v
    def __mul__[_RT](self, r: _RT) -> Thing[Mul[_T, _RT]]:
        return Thing(self.v * r)

A user of Thing wants to try it with sympy.Floats and decimal.Decimals and finds it works perfectly well at runtime. However, the user also wants type checking without having to bug the author of Thing.

Aha! That sounds like a job for optype!

import optype as op

class Thing[_T](...):
    def __init__(self, v: _T):
        self.v = v

    @overload
    def __mul__[InT, OutT](self: Thing[op.CanMul[InT, OutT]], r: InT, /) -> Thing[OutT]: ...
    @overload
    def __mul__[InT, OutT](self: Thing[InT], r: op.CanRMul[InT, OutT], /) -> Thing[OutT]: ...

• CanMul protocol docs
• CanRMul reciprotocol docs

😎

[leycec]

I take umbrage at the optypes one-liner:

Stop fighting your type checker — work with it.

Nay! Fight it. Static type-checkers suuuuuuck. It's all false positives and time wasters in their unctuous world. Fight that which wastes time. Do not succumb to that good night of QA. Which brings me to...

That Which Wastes Time

Maintaining our wayward beartype.typing.Protocol fork these long years has not been fun. It breaks whenever typing maintainers blink at the Protocol implementation. It's also buggy... still. I'm not even going to tell you how it's buggy.

Very well. beartype.typing.Protocol doesn't support class methods. It's thus not even a valid drop-in for typing.Protocol. That's the worst kind of awful: QA that doesn't pass QA muster. It's also apparently superfluous now, because typing.Protocol is as fast as paint drying now. Good. The 5-Year @beartype Plan of forward-thinking success is thus as follows:

1. Wait for beartype.typing.Protocol to break again. Inevitably, it will. It always does. Until it does, though, diverting scarce attention to beartype.typing.Protocol is just breaking something that sorta works. No point in doing that. No one's complaining at us... yet.
2. Quietly rip out beartype.typing.Protocol in favour of the default typing.Protocol implementation. Easy-peasy.

Laziness is the only virtue. Even Cthulhu watching the Eldritch God Flix streaming channel down in R'lyeh knows this. As for...

numerary vs optype

@posita, it would sadden me to see you bring numerary out behind the woodshed.

I have no insight as to whether optype is superior. Scalar typing is outside my wheelhouse. My wheelhouse mostly just contains old video game consoles with obscure names like "WonderSwan!!!", PC-98, ^{not an actual PC, of course... wat!?} and MSX. Now there's a lit console name. MSX. Just sounds cool. WonderSwan? Not so much.

optype might be superior. But it might not be. Ultimately, though, at the end of the day... does it matter? As long as numerary costs you nothing to maintain, it's worth maintaining. Of course, maybe numerary costs you something to maintain. After all, you had to read all of this. That was a cost. And the cost was precious sanity points.

^{maybe it's not you, cat. MAYBE IT'S SOCIETY}

[jorenham]

Nay! Fight it.

🫡

Static type-checkers suuuuuuck.

Yes, they do. But I think that in large part their suckitudiness is an inevitable consequence of Python's sketchy type system spec. Even the perfect static type-checker would still have a certain base level of suckitudiness (roughly ~19% according to my calculations).

Then there's also a trade-off between type-safety and the level of suckitudiness. Because as you increase type-safety, you'll inevitably increase the false-positive rate, causing you to move up along the suckitudinal axis.

Taking this to the extreme (*grunts intelligibly*) by univariately minimizing the suckitudiness, you'll end up with the following type-checker:

import sys

if __name__ == "__main__":
    print("0 errors found!")
    sys.exit(0)

(But obviously this should be rewritten in rust for performance reasons.)

If you would instead optimize purely for type-safety, this is what you'd end up with:

import sys

if __name__ == "__main__":
    print("∞ errors found")
    sys.exit(1)

Python programs can raise anywhere anytime (e.g. KeyboardInterrupt), but that's impossible to guard against using static typing, so every Python program is theoretically type-unsafe.

I have no insight as to whether optype is superior.

They solve different problems, so they're both Pareto optimal.

But perhaps jorenham/optype#252 could change that? Although I suppose something like that could also be a nice(r?) fit for beartype (you're welcome to steal the idea; I won't sue :P).

[posita]

numerary vs optype

@posita, it would sadden me to see you bring numerary out behind the woodshed.

I have no insight as to whether optype is superior. Scalar typing is outside my wheelhouse. My wheelhouse mostly just contains old video game consoles with obscure names like "WonderSwan!!!", PC-98, not an actual PC, of course... wat!? and MSX. Now there's a lit console name. MSX. Just sounds cool. WonderSwan? Not so much.

optype might be superior. But it might not be. Ultimately, though, at the end of the day... does it matter? As long as numerary costs you nothing to maintain, it's worth maintaining. Of course, maybe numerary costs you something to maintain. After all, you had to read all of this. That was a cost. And the cost was precious sanity points.

First, and most importantly, long live Boulder Dash.

Second, and much less importantly, I don't know that numerary costs me anything to maintain, other than it nags at my soul as never having solved the problem I set out to solve with it, which makes for a 100% dissatisfaction rate for numerary's customer...(s?). ^{Determining population size is left as an exercise to the onlooker.} Can one attempt to spend sanity points one does not have? I am not sure what my sanity credit score is, but I'm sure it's low.

As far as I can tell, the project's main "benefits" are limited to (now arcane) dark magic runtime type-checking performance improvements ^{lurking ominously in beartype's core, the legitimacy of which this very issue calls into question} and runtime type-checking overrides which have that hidden-away-in-some-config-like-init-somewhere ick factor. The whole Supports protocols thing? Not so much, as far as I can tell.

Rest easy, bold Keeper of the Type of Bear! Such things can be banished into deeper corners of the ursine heart ^{or, maybe spleen makes for a more accurate metaphor}, if that is what you wish. 🙇 My only fear is what awaits us on that path, for I cannot yet see its end.

Or, we could move the whole bit back into numerary where it will likely harm no one and can be safely relegated to a long forgotten, overgrown side road no longer visible from the superhighway of man's ongoing search for typing perfection. I lack strong opinions ^{on this, at least}.

[posita]

Aha! That sounds like a job for optype!

import optype as op

class Thing_T:
def init(self, v: _T):
self.v = v

@overload
def __mul__[InT, OutT](self: Thing[op.CanMul[InT, OutT]], r: InT, /) -> Thing[OutT]: ...
@overload
def __mul__[InT, OutT](self: Thing[InT], r: op.CanRMul[InT, OutT], /) -> Thing[OutT]: ...

* [`CanMul` protocol docs](https://jorenham.github.io/optype/reference/core/binary/)

* [`CanRMul` reciprotocol docs](https://jorenham.github.io/optype/reference/core/reflected/)

😎

Perhaps I lack the requisite understanding, but I am failing to see how our theoretical user (customer of Thing, sympy, and decimal) can extend this to achieve a proper output for reveal_type(Thing(sympy.Integer(2)) * decimal.Decimal("1"))? Consider:

# op_play.py
import optype
import typing

T = typing.TypeVar("T")
InT = typing.TypeVar("InT")
OutT = typing.TypeVar("OutT")

class Thing(typing.Generic[T]):
    def __init__(self, v: T):
        self.v = v

    @typing.overload
    def __mul__(self: "Thing[optype.CanMul[InT, OutT]]", r: InT, /) -> "Thing[OutT]": ...
    @typing.overload
    def __mul__(self: "Thing[InT]", r: optype.CanRMul[InT, OutT], /) -> "Thing[OutT]": ...

    def __mul__(self: "Thing", r):
        return Thing(self.v * r)


import decimal
import itertools
import numpy
import sympy

types = (
    "sympy.Integer",
    # "numpy.int64",
    # "int",
    "decimal.Decimal",
)

for lt, rt in itertools.permutations(types, 2):
    lc, rc = eval(lt), eval(rt)
    print(f"{lt}(1) * {rt}(1) = {lc(1) * rc(1)} ({type(lc(1) * rc(1))})")
    # print(f"{lt}(2) * {rt}(2) = {lc(2) * rc(2)} ({type(lc(2) * rc(2))})")

for lt, rt in itertools.permutations(types, 2):
    print(f"    reveal_type({lt}(1) * {rt}(1))")
    print(f"    reveal_type(Thing({lt}(1)) * {rt}(1))")
    # print(f"    reveal_type({lt}(2) * {rt}(2))")
    # print(f"    reveal_type(Thing({lt}(2)) * {rt}(2))")

if typing.TYPE_CHECKING:
    # Each of these should be sympy.core.numbers.Float (at least according to what we
    # discovered at runtime)
    reveal_type(sympy.Integer(1) * decimal.Decimal(1))
    reveal_type(decimal.Decimal(1) * sympy.Integer(1))

    # Each of these should be Thing[sympy.core.numbers.Float] (at least according to
    # what we discovered at runtime)
    reveal_type(Thing(sympy.Integer(1)) * decimal.Decimal(1))
    reveal_type(Thing(decimal.Decimal(1)) * sympy.Integer(1))

% ( set -ux ; .tox/py313/bin/python3 op_play.py ; .tox/py313/bin/mypy op_play.py )
+-zsh:517> .tox/py313/bin/python3 op_play.py
sympy.Integer(1) * decimal.Decimal(1) = 1.00000000000000 (<class 'sympy.core.numbers.Float'>)
decimal.Decimal(1) * sympy.Integer(1) = 1.00000000000000 (<class 'sympy.core.numbers.Float'>)
    reveal_type(sympy.Integer(1) * decimal.Decimal(1))
    reveal_type(Thing(sympy.Integer(1)) * decimal.Decimal(1))
    reveal_type(decimal.Decimal(1) * sympy.Integer(1))
    reveal_type(Thing(decimal.Decimal(1)) * sympy.Integer(1))
+-zsh:517> .tox/py313/bin/mypy op_play.py
op_play.py:48: note: Revealed type is "Any"
op_play.py:49: note: Revealed type is "Any"
op_play.py:53: note: Revealed type is "op_play.Thing[Any]"
op_play.py:54: note: Revealed type is "Any"
Success: no issues found in 1 source file

The authors of decimal, sympy, and Thing didn't contemplate each other, and yet we want them to play nicely, and maybe even be properly typed. So what we need is something not written by any of those authors that tells our type checker that when we do decimal.Decimal(1) * sympy.Integer(1), we'll get a sympy.Float (or equivalent). My thought is that one could try to enumerate and perform such operations and inspect the result of the operation to infer the result type. Assuming this could be done (I think it can), what would we do with that information so that the optype-ified Thing could make use of it? Forgive me if this is obvious, and I lack sufficient understanding to see it.

[leycec]

THE TREASURE OF TARDOS. Bald wizened sad dude in the red secret society cape looks suspiciously like me on a good day. I'll just let that sink in for a moment.

Also, I vibe with this last-ditch effort to preserve beartype.typing.Protocol for future generations:

Or, we could move the whole bit back into numerary where it will likely harm no one and can be safely relegated to a long forgotten, overgrown side road no longer visible from the superhighway of man's ongoing search for typing perfection.

Yes! The next time beartype.typing.Protocol falls down on its one job, I'll ping you. At that time, please salvage what can be salvaged from the trainwreck of our mutual enthusiasm for writing spaghetti well-documented, extremely maintainable God-tier code.

You're both really funny. Clearly, everyone here Paretos. I can see it all now. You two are so similar in fundamental design outlook, IQ-high humour, ^{it's a contest. they wouldn't even let me in the door!} and queasy INTP-ness. It's only natural you're at each other's QA throats. Allow me to cozy up with a fistful of popcorn as you duke it out in this arena of public justice.

And now.

The Moment We've All Been Waiting For All Our Lives

You are both hereby invited to the opening ceremony of @beartype's live Zulip chatline. Zulip is like IRC. Both have stinky UX and UI that reeks of the America Online era of a better Internet – when nobody but the most diehard, dyed-in-the-modem-wool keyboard warrior dared venture into the choppy seas of "cyberspace." The difference is nobody still uses IRC. Or... do they? DO THEY!?

Gods. Remember when we called this ineluctable jewel of digital weirdness "cyberspace," everybody? Now there is a word I have not heard in a very long time. Cyberspace. A childlike yet menacing aura surrounds that word. Cue "The Treasure of Tardos." I'm crying too, bald wizened sad dude.

[posita]

@jorenham, sorry if I'm dense, but how do I use optype to tell a type checker than when a generic container of type T is multiplied with an object of type B that the result will be a the generic container of type B (or even C)? I'm trying to wrap my head around your work, but I'm not sure I follow, even with the example you provided. Consider:

# optype_thing.py
import decimal
import operator
import optype as op
import typing

T = typing.TypeVar("T")
InT = typing.TypeVar("InT")
OutT = typing.TypeVar("OutT")

class Thing(typing.Generic[T]):
    v: T

    def __init__(self, v: T):
        self.v = v

    @typing.overload
    def __mul__(self: "Thing[op.CanMul[InT, OutT]]", r: InT, /) -> "Thing[OutT]": ...
    @typing.overload
    def __mul__(self: "Thing[InT]", r: op.CanRMul[InT, OutT], /) -> "Thing[OutT]": ...
    def __mul__(self, r):
        return Thing(operator.__mul__(self.v, r))

    def __repr__(self):
        return f"Thing({self.v!r})"

print(Thing(decimal.Decimal(3)) * 8)
print(Thing(3) * 8)

if typing.TYPE_CHECKING:
    reveal_type(decimal.Decimal(1) * 1)  # decimal.Decimal
    reveal_type(Thing(decimal.Decimal(1)) * 1)  # Any
    reveal_type(3 * 8)  # builtins.int
    reveal_type(Thing(3) * 8)  # Any

% python --version
Python 3.12.13
% python optype_thing.py
Thing(Decimal('24'))
Thing(24)
% mypy optype_thing.py
optype_thing.py:25: error: Unsupported operand types for * ("Thing[Decimal]" and "int")  [operator]
optype_thing.py:29: note: Revealed type is "decimal.Decimal"
optype_thing.py:30: note: Revealed type is "Any"
optype_thing.py:30: error: Unsupported operand types for * ("Thing[Decimal]" and "int")  [operator]
optype_thing.py:31: note: Revealed type is "builtins.int"
optype_thing.py:32: note: Revealed type is "optype_thing.Thing[builtins.int]"
Found 2 errors in 1 file (checked 1 source file)

What am I doing wrong?

[jorenham]

If you make T@Thing covariant, then it'll work as expected (unless you're using mypy, that is):

(I turned it into a .pyi for convenience. The only static-typing difference with your example is the covariant typar.)