Let beartype check custom sequence protocol with inner types #277

tvdboom · 2023-09-01T08:22:12Z

tvdboom
Sep 1, 2023

Hi,

I have written a custom protocol class intended to check one-dimensional, indexable array-like object (read: list, tuple, np.array, pd.Series...). It looks like this:

from typing import TypeVar, Protocol, Iterable, runtime_checkable

T = TypeVar("T")

@runtime_checkable
class Sequence(Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

When using typebear, I can just check the class and it will correctly check if the requested dunder methods are present, but is it possible to also check the content of the sequence, class T?

is_bearable([1, 2], Sequence)  # Passes, good
is_bearable([1, 2], Sequence[int])  # Passes, good
is_bearable([1, 2], Sequence[str])  # Passes, but I want it to fail!

Also: This protocol would also pass any string because it has the required dunder methods. Any way to avoid that?

is_bearable("test", Sequence)  # Passes, but I want it to fail!

Thanks in advance:)

Answered by leycec

Sep 7, 2023

OMG!!! I can't believe this actually works... but it does. The CPython devs responsible for the standard typing module are very strict and typically try to lock down monkey-patching shenanigans like this. Looks like they forgot to prepare for @beartype:

class SequenceProtocol(Protocol[T]):
    '''
    Type hint factory class dynamically creating and returning new
    ``Annotated[SequenceProtocol[...], ...]`` type hints, subscripted by the
    passed type.

    Parameters
    ----------
    X : object
        Arbitrary child type hint with which to subscript the
        :class:`SequenceProtocol` protocol.

    Returns
    ----------
    Annotated
        ``Annotated[SequenceProtocol[X], ..…

View full answer

leycec · 2023-09-02T04:54:05Z

leycec
Sep 2, 2023
Maintainer

typebear

^{typebear has entered the room}

So, I love issues like this. To answer your poignant question, @tvdboom...

but is it possible to also check the content of the sequence, class T?

The answers are... sort of and it's complicated. First, let's talk @beartype. Technically, @beartype could try to implicitly detect which of the 25 existing standard abstract base classes (ABCs) defined by the collections.abc submodule a given Protocol subclass satisfies. Pragmatically, doing so would require that @beartype test each Protocol subclass used as a type hint against each of these 25 ABCs at decoration time. This has worst-case time complexity O(j*k) for j = 25 the number of standard ABCs and k = 17 the maximum number of methods to test for the worst-case standard ABC (which is probably collections.abc.MutableMapping, whose public interface appears to define a shocking 17 methods). That's bad. Like, super-bad. Like, super-terribad.

Understandably, @beartype doesn't do that. Instead, @beartype embraces Python's "Explicit is better than implicit" maxim by requiring you to explicitly declare which standard ABCs your protocol satisfies. In theory, that would be trivial. Just subclass your Protocol subclass from all of the standard ABCs your protocol satisfies. In this case, that's just the standard collections.abc.Sequence ABC: e.g.,

from collections.abc import Sequence as SequenceABC
from typing import TypeVar, Protocol, Iterable, runtime_checkable

T = TypeVar("T")

@runtime_checkable
class Sequence(SequenceABC, Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

Of course, that doesn't work. Why? Because the current implementation of typing.Protocol is super-terribad:

Traceback (most recent call last):
  File "/home/leycec/tmp/mopy.py", line 11, in <module>
    class Sequence(SequenceABC, Protocol[T]):
  File "<frozen abc>", line 106, in __new__
  File "/usr/lib/python3.11/typing.py", line 2094, in __init_subclass__
    raise TypeError('Protocols can only inherit from other'
TypeError: Protocols can only inherit from other protocols, got <class 'collections.abc.Sequence'>

"...uhh. wat?", you may now be thinking. Yes, it is all true. Even though the private typing._ProtocolMeta metaclass subclasses the standard abc.ABCMeta metaclass, the public typing.Protocol class explicitly prevents all subclasses from subclassing any other ABCs – except, bizarrely, this limited list of permissible ABCs:

# In the standard "typing.py" module bundled with Python:
_PROTO_ALLOWLIST = {
    'collections.abc': [
        'Callable', 'Awaitable', 'Iterable', 'Iterator', 'AsyncIterable',
        'Hashable', 'Sized', 'Container', 'Collection', 'Reversible',
    ],
    'contextlib': ['AbstractContextManager', 'AbstractAsyncContextManager'],
}

Noticeably, _PROTO_ALLOWLIST['collections.abc'] omits Sequence. Why? No good reason, obviously. It's probably just an oversight that no one has ever bothered to fix, because no one really cares about typing.Protocol, because typing.Protocol is more-or-less useless for most real-world purposes. It's also extremely slow, which also kinda defeats the purpose of using @beartype.

In fact, there's even a well-known Python issue about this very topic.

Everything is Bad and Here's the Proof

One obvious "solution" would be to just monkey-patch the Sequence ABC back into the private _PROTO_ALLOWLIST['collections.abc'] subdictionary. Superficially, that works; doing that at least allows you to subclass a protocol from collections.abc.Sequence. Pragmatically, that doesn't work at all; @beartype still reports a false positive: e.g.,

from beartype.door import is_bearable
from collections.abc import Sequence as SequenceABC
from typing import TypeVar, Protocol, Iterable, runtime_checkable

import typing
typing._PROTO_ALLOWLIST = {
    'collections.abc': [
        'Callable', 'Awaitable', 'Iterable', 'Iterator', 'AsyncIterable',
        'Hashable', 'Sized', 'Container', 'Collection', 'Reversible',
        'Sequence',
    ],
    'contextlib': ['AbstractContextManager', 'AbstractAsyncContextManager'],
}

T = TypeVar("T")

@runtime_checkable
class Sequence(SequenceABC[T], Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

print(is_bearable([1, 2], Sequence[int]))
print(is_bearable([1, 2], Sequence[str]))

...which prints:

True  # <-- good. this is good.
True  # <-- GAH!! BURN MY EYES!!

Not Everything is Bad and Here's the Proof

Ugh. Let's try a different tact. What if we replace the SequenceABC[T] in the declaration of your Sequence class with both SequenceABC[int] and SequenceABC[str]? The result is cumbersome, but oddly appears to finally yield the expected results:

from beartype.door import is_bearable
from collections.abc import Sequence as SequenceABC
from typing import TypeVar, Protocol, Iterable, runtime_checkable

import typing
typing._PROTO_ALLOWLIST = {
    'collections.abc': [
        'Callable', 'Awaitable', 'Iterable', 'Iterator', 'AsyncIterable',
        'Hashable', 'Sized', 'Container', 'Collection', 'Reversible',
        'Sequence',  # <-- We didn't make crazy. We just fix crazy.
    ],
    'contextlib': ['AbstractContextManager', 'AbstractAsyncContextManager'],
}

T = TypeVar("T")

@runtime_checkable
class SequenceInt(SequenceABC[int], Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

@runtime_checkable
class SequenceStr(SequenceABC[str], Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

print(is_bearable([1, 2], SequenceInt))
print(is_bearable([1, 2], SequenceStr))

...which prints:

True   # <-- good. this is good.
False  # <-- YES!! YES!!!! BY ODIN, WE DID SOMETHING THAT WORKS!!!!!!

Technically, that appears to work. Pragmatically, we had to monkey-patch private internals of the typing module just to get there. Is there no hope whatsoever?

`beartype.typing`: Hold My Beer, `typing`

What if we replace the typing module above with the beartype.typing submodule? For reasons that are not entirely clear to me, that works a little better. We no longer have to monkey-patch either typing or beartype.typing (or use that useless @typing.runtime_checkable decorator), which is certainly an improvement:

from beartype.door import is_bearable
from collections.abc import Sequence as SequenceABC
from beartype.typing import TypeVar, Protocol, Iterable

T = TypeVar("T")

class SequenceInt(SequenceABC[int], Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

class SequenceStr(SequenceABC[str], Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

print(is_bearable([1, 2], SequenceInt))
print(is_bearable([1, 2], SequenceStr))

...which again prints:

True   # <-- good. this is good.
False  # <-- YES!! YES!!!! BY ODIN, WE DID SOMETHING THAT WORKS!!!!!!

Still, that's non-ideal. Manually differentiating your Sequence protocol into separate SequenceInt and SequenceStr protocols fully defeats the purpose of the type variable T. That's not great.

And... that's where I burned out late on a Friday night. There is definitely a @beartype issue here. In the following example, @beartype should propagate the [int] and [str] subscripting your Sequence protocol up to the SequenceABC base class:

from beartype.door import is_bearable
from collections.abc import Sequence as SequenceABC
from beartype.typing import TypeVar, Protocol, Iterable

T = TypeVar("T")

class Sequence(SequenceABC[T], Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

print(is_bearable([1, 2], Sequence[int]))
print(is_bearable([1, 2], Sequence[str]))

That should just work. It doesn't. That's definitely a @beartype issue. That said, since typing.Protocol refuses to play nicely with collections.abc, the only users who will ever even see this issue are users who replace typing.Protocol with beartype.typing.Protocol. Is anyone ever going to do that? Like... seriously?

I kinda doubt it. I'm definitely willing to promote this to a full-blown issue that I eventually resolve for you – but that's probably putting the cart before the horse. Python itself really needs to fix its broken typing.Protocol implementation first. typing.Protocol needs to play nicely with every abstract base class (i.e., class whose metaclass is abc.ABCMeta). Until that happens, us doing anything is pointless.

I am shaking my skinny fists like antennas to heaven.

1 reply

tvdboom Sep 2, 2023
Author

Hi,

thanks so much for the explanation. I understand the problem. No need to try and fix this beartype issue just for my usecase, because even if you did, there is still another problem, namely that using

from beartype.door import is_bearable
from collections.abc import Sequence as SequenceABC
from beartype.typing import TypeVar, Protocol, Iterable

T = TypeVar("T")

class SequenceInt(SequenceABC[int], Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

only works for subclasses of SequenceABC, and not for other "sequences" like np.array or pd.Series, which is what I need at the end.

print(is_bearable(np.array([1, 2]), SequenceInt)  # --> False, should be good

I guess I'll need to write logic to check the inner values of the sequence inside the method.

Thanks again

leycec · 2023-09-02T16:52:39Z

leycec
Sep 2, 2023
Maintainer

...and not for other "sequences" like np.array or pd.Series, which is what I need at the end.

Yup. Absolutely. Unfortunately, this one is on NumPy and Pandas – both of which have long-standing open issues about this exact topic:

The issue with Pandas is mostly backward compatibility. The pandas.DataFrame, pandas.Index, pandas.Series containers absolutely should have subclassed some combination of collections.abc.Mapping and collections.abc.Sequence. Of course, they didn't. Now, it's too late to do that without breaking everything across the Pandas ecosystem.

The issue with NumPy is a little more subtle. Even if NumPy devs had wanted to originally subclass the numpy.ndarray type from collections.abc.Sequence a few decades ago, it's unclear whether they actually could have. NumPy arrays are multidimensional and thus tend not to conform to either the collections.abc.Sequence or collections.abc.MutableSequence APIs. For example:

NumPy arrays can be 0-dimensional, in which case they effectively behave as scalars that are neither iterable nor indexable. Standard sequences, obviously, cannot be 0-dimensional.
NumPy arrays can be multiplied by both floating-point and integer numbers. Standard sequences can only be multiplied by integer numbers (e.g., (1, 2)*2) – but the result is item duplication rather than item multiplication, which is a rather different thing.
NumPy arrays lack most of the public methods that standard sequences define (e.g., count(), index()).
NumPy arrays cannot be reversed. Standard sequences can.

And so on and so on. That said...

I Totally Get What You're Trying to Do Here

I get it, @tvdboom. It's actually a really smart idea – and one that NumPy devs themselves have floated about before:

Maybe it would be possible to convince the python folks to create a new class like SequenceBase that is even below Sequence and does not guarantee .index or .count, but only .__len__ and __getitem__ or such? Its all nice that Sequence has something like index, but it seems a bit weird to force it onto things like numpy by seemingly making it how sequence like things should be duck typed. Are the python folks aware of that this is somewhat problematic?

Basically, your Sequence protocol is an attempt to do exactly what @seberg suggested over a decade ago. That's a good thing, because that was a good idea. Somebody should have done that. Unfortunately, nobody did that. Since nobody did that, it's unclear how @beartype can best support this.

What's really needed is for somebody to just do this already. This is easier said than done. None of the people who cared about this did this, which is concerning. Still, the core idea has merit. Somebody who is not me should author a new PEP standardizing a new collections.abc.SequenceBase ABC, which would look pretty much like:

# In "collections.abc":
from typing import TypeVar

T = TypeVar("T")

class SequenceBase(Collection[T]):
    @abstractmethod
    def __iter__(self) -> Iterable[T]: ...

    @abstractmethod
    def __getitem__(self, item) -> T: ...

    @abstractmethod
    def __len__(self) -> int: ...

Both np.ndarray and pd.Series would then implicitly satisfy that protocol... mostly, except for 0-dimensional NumPy arrays. But maybe everyone just ignores that edge case and pretends that 0-dimensional NumPy arrays don't even exist. I am all for wilful denial.

I am stroking my chin thoughtfully while peering into the distance. 🤔

I guess I'll need to write logic to check the inner values of the sequence inside the method.

...yeah. That pretty much sucks, doesn't it? This is a surprisingly non-trivial topic. The issue, really, is that all of these third-party numeric frameworks like NumPy and Pandas reinvented the wheel rather than playing nicely one with another and the standard Python library.

From my experience, SymPy is the only one that gets this right. SymPy containers and scalars conform to the standard Python ABCs and just behave as expected out-of-the-box. Serenity now, NumPy and Pandas!

^{@leycec after dealing with NumPy and Pandas for an hour}

3 replies

tvdboom Sep 4, 2023
Author

Thanks again for the clarification. I'm still not gonna give up though. Let's try another approach. Would it be possible to do something like this?

from beartype.door import is_bearable
from collections.abc import Sequence as SequenceABC
from beartype.typing import TypeVar, Protocol, Iterable

T = TypeVar("T")

class SequenceProtocol(Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

from beartype.vale import Is
from typing import Annotated 

Sequence = Annotated[SequenceProtocol[X], Is[lambda lst: all(isinstance(i, X) for i in lst)]]

Then I would only need a way to pass the type declared here as X programatically inside the lambda function.

leycec Sep 5, 2023
Maintainer

...heh. You thought of that too, huh? I was wondering if you were going to make that intuitive leap. Unsurprisingly, you made that intuitive leap. You also refused to give up and meekly accept your fate. This explains why your avatar is a supermassive black hole.

Your intuitive leap intersects with a few outstanding feature requests – including:

O(n) linear-time type-checking, which your Is[lambda lst: ...] validator is attempting to reproduce manually but which @beartype itself should already support out-of-the-box.
Type variable-subscriptable validators (i.e., validators that support subscription (indexation) by TypeVar objects), which your undefined X object is sorta serving as a placeholder for.

If @beartype supported some or all of the above things, your excellent simple snippet could be succinctly reduced to something even simpler. But @beartype doesn't support any of those things. So, we have to do what NIST research giant @rtbs-dev did at her related feature request. We write our own type hint factory function dynamically creating and returning new Annotated[SequenceProtocol[...], ...] type hints, subscripted by the passed type:

from beartype.door import is_bearable
from beartype.vale import Is
from beartype.typing import Annotated, TypeVar, Protocol, Iterable

T = TypeVar("T")

class SequenceProtocol(Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

def SequenceProtocolOf(X: object) -> Annotated:
    '''
    Type hint factory function dynamically creating and returning new
    ``Annotated[SequenceProtocol[...], ...]`` type hints, subscripted by the
    passed type.

    Parameters
    ----------
    X : object
        Arbitrary child type hint with which to subscript the
        :class:`SequenceProtocol` protocol.

    Returns
    ----------
    Annotated
        ``Annotated[SequenceProtocol[X], ...]`` type hint validating that *all*
        items of this sequence satisfy this child type hint.
    '''

    return Annotated[SequenceProtocol[X], Is[
        lambda lst: all(is_bearable(i, X) for i in lst)]]

print(is_bearable([1, 2], SequenceProtocol))
print(is_bearable([1, 2], SequenceProtocolOf(int)))
print(is_bearable([1, 2], SequenceProtocolOf(str)))

...which prints:

True
True
False

SUCCESS! 🥳

Oh... and did you see what I did there? I generalized your Is[...] validator to type-check sequence items via is_bearable() rather than isinstance(). Doing so generalizes your protocol to accept arbitrary child type hints, including nested sequences:

print(is_bearable([[1, 2], [3, 4]], SequenceProtocolOf(SequenceProtocolOf(int))))
print(is_bearable([[1, 2], [3, 4]], SequenceProtocolOf(SequenceProtocolOf(str))))

...which prints:

True
False

MOAR SUCCESS! 🥳 🥳

Oh... and you can go even deeper into the supermassive black hole that is @beartype. Since you've already gone this far, you'd might as well just make SequenceProtocolOf a subscriptable type hint factory class resembling:

class SequenceProtocolOf(object):
    '''
    Type hint factory class dynamically creating and returning new
    ``Annotated[SequenceProtocol[...], ...]`` type hints, subscripted by the
    passed type.

    Parameters
    ----------
    X : object
        Arbitrary child type hint with which to subscript the
        :class:`SequenceProtocol` protocol.

    Returns
    ----------
    Annotated
        ``Annotated[SequenceProtocol[X], ...]`` type hint validating that *all*
        items of this sequence satisfy this child type hint.
    '''

    @classmethod
    def __class_getitem__(cls, X: object) -> Annotated:
        return Annotated[SequenceProtocol[X], Is[
            lambda lst: all(is_bearable(i, X) for i in lst)]]

print(is_bearable([1, 2], SequenceProtocol))
print(is_bearable([1, 2], SequenceProtocolOf[int]))
print(is_bearable([1, 2], SequenceProtocolOf[str]))
print(is_bearable([[1, 2], [3, 4]], SequenceProtocolOf[SequenceProtocolOf[int]]))
print(is_bearable([[1, 2], [3, 4]], SequenceProtocolOf[SequenceProtocolOf[str]]))

...which prints:

True
True
False
True
False

EVEN MOAR SUCCESS! 🥳 🥳 🥳

SequenceProtocolOf now both looks and acts like standard typing type hint factories – especially typing.Sequence[...]. The only disadvantage to all this runtime magic is that pure static type-checkers like mypy and pyright will have utterly no idea what you are talking about. But who cares what those dumb-dumbs think, am I right? Anyone? Hellllllllllo? 😞

tvdboom Sep 5, 2023
Author

Awesome!

I am a bit worried though about incomprehensible errors for the users, for example:

Specially since BeartypeDoorHintViolation doesn't say anything to the user and it's very hard to understand from this error that we are expecting a sequence of strings. Is there a way to pass a custom error message to all this? I am probably for too much, but it would be nice... :D

leycec · 2023-09-05T16:27:52Z

leycec
Sep 5, 2023
Maintainer

...heh. Yes, that is appalling. You're not alone in that dark realization either. beartype.vale exceptions are clearly unreadable for a general audience, which is bad. This is why yet another feature request allowing users to define custom violation messages exists!

The idea here is that you'd define a SequenceProtocol.__beartype_violation_message__() dunder method, which @beartype would then call to generate a human-readable violation message. The implementation would sorta resemble:

class SequenceProtocol(Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

    @classmethod
    def __beartype_violation_message__(cls, hint: object, obj: object) -> str:
        if not isinstance(obj, cls):
            return 'not a sequence'

        # Child type hint subscripting this protocol (e.g., "int" for the
        # parent type hint "SequenceProtocol[int]").
        item_hint = hint.__args__[0]

        for item_index, item in enumerate(obj):
            if not is_bearable(item, item_hint):
                return f'item {item_index} {repr(item)} not {repr(item_hint)}'

Something like that, maybe? Naturally, nothing like that currently exists. This is why cats cry. 😿

0 replies

leycec · 2023-09-05T17:44:08Z

leycec
Sep 5, 2023
Maintainer

Oh – and I belatedly realized that you can actually get static type-checking support from mypy and pyright as well. How? typing.TYPE_CHECKING, the insane global boolean that just keeps on giving:

from typing import TYPE_CHECKING

class SequenceProtocol(Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

if TYPE_CHECKING:
    SequenceProtocolOf = SequenceProtocol
else:
    class SequenceProtocolOf(object):
        '''
        Type hint factory class dynamically creating and returning new
        ``Annotated[SequenceProtocol[...], ...]`` type hints, subscripted by the
        passed type.

        Parameters
        ----------
        X : object
            Arbitrary child type hint with which to subscript the
            :class:`SequenceProtocol` protocol.

        Returns
        ----------
        Annotated
            ``Annotated[SequenceProtocol[X], ...]`` type hint validating that *all*
            items of this sequence satisfy this child type hint.
        '''

        @classmethod
        def __class_getitem__(cls, X: object) -> Annotated:
            return Annotated[SequenceProtocol[X], Is[
                lambda lst: all(is_bearable(i, X) for i in lst)]]

It's rough stuff, but that's just how we roll in the QA trenches.

0 replies

tvdboom · 2023-09-07T14:40:27Z

tvdboom
Sep 7, 2023
Author

Hi,

another question that would make the solution mentioned before even better.

In your answer

class SequenceProtocolOf(object):
    '''
    Type hint factory class dynamically creating and returning new
    ``Annotated[SequenceProtocol[...], ...]`` type hints, subscripted by the
    passed type.

    Parameters
    ----------
    X : object
        Arbitrary child type hint with which to subscript the
        :class:`SequenceProtocol` protocol.

    Returns
    ----------
    Annotated
        ``Annotated[SequenceProtocol[X], ...]`` type hint validating that *all*
        items of this sequence satisfy this child type hint.
    '''

    @classmethod
    def __class_getitem__(cls, X: object) -> Annotated:
        return Annotated[SequenceProtocol[X], Is[
            lambda lst: all(is_bearable(i, X) for i in lst)]]

print(is_bearable([1, 2], SequenceProtocol))
print(is_bearable([1, 2], SequenceProtocolOf[int]))
print(is_bearable([1, 2], SequenceProtocolOf[str]))
print(is_bearable([[1, 2], [3, 4]], SequenceProtocolOf[SequenceProtocolOf[int]]))
print(is_bearable([[1, 2], [3, 4]], SequenceProtocolOf[SequenceProtocolOf[str]]))

I didn't notice the first print statemenrt actually checks for the SequenceProtocol class and not SequenceProtocolOf. Is there a way to rewrite one of the two classes to fullfill both use cases (checking with and without subscripted types)?

What I would like is print(is_bearable([1, 2], SequenceProtocolOf)) to return True (currently it returns False).

0 replies

leycec · 2023-09-07T16:18:22Z

leycec
Sep 7, 2023
Maintainer

OMG!!! I can't believe this actually works... but it does. The CPython devs responsible for the standard typing module are very strict and typically try to lock down monkey-patching shenanigans like this. Looks like they forgot to prepare for @beartype:

class SequenceProtocol(Protocol[T]):
    '''
    Type hint factory class dynamically creating and returning new
    ``Annotated[SequenceProtocol[...], ...]`` type hints, subscripted by the
    passed type.

    Parameters
    ----------
    X : object
        Arbitrary child type hint with which to subscript the
        :class:`SequenceProtocol` protocol.

    Returns
    ----------
    Annotated
        ``Annotated[SequenceProtocol[X], ...]`` type hint validating that *all*
        items of this sequence satisfy this child type hint.
    '''

    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

    @classmethod
    def __class_getitem__(cls, X: object) -> Annotated:
        return Annotated[cls, Is[
            lambda lst: all(is_bearable(i, X) for i in lst)]]

print(is_bearable([1, 2], SequenceProtocol))
print(is_bearable([1, 2], SequenceProtocol[int]))
print(is_bearable([1, 2], SequenceProtocol[str]))
print(is_bearable([[1, 2], [3, 4]], SequenceProtocol[SequenceProtocol[int]]))
print(is_bearable([[1, 2], [3, 4]], SequenceProtocol[SequenceProtocol[str]]))

...which prints:

True
True
False
True
False

🤣

The only issue, of course, is that doesn't actually do what you want. It just looks like it does what you want. Although standard Python sequences like list and tuple do define the __class_getitem__() dunder method and thus satisfy this new horrible SequenceProtocol API, I really doubt that either NumPy or Pandas sequences do.

To get this to work for all possible third-party sequence types, we would somehow need to exclude our SequenceProtocol.__class_getitem__() method from inclusion in the SequenceProtocol API. Technically, that might be feasible by @beartype defining a new @beartype.typing.omit_method_from_protocol_api decorator or something. Pragmatically, we are starting to get into the Weirdo Typing Zone where increasingly nothing makes sense and we should reflect on our core value system: e.g.,

# Looks pretty weirdo, bro.
from beartype.typing import omit_method_from_protocol_api

class SequenceProtocol(Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

    @omit_method_from_protocol_api  # <-- so weirdo, so rando
    @classmethod
    def __class_getitem__(cls, X: object) -> Annotated:
        return Annotated[cls, Is[
            lambda lst: all(is_bearable(i, X) for i in lst)]]

😭

We are now bumping up against the finite limit of bugs in the @beartype and Python codebases.

1 reply

tvdboom Sep 7, 2023
Author

Alright, I agree with you that is a bit too random. But for the fun of it I tried running this:

class SequenceProtocol(Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

    @classmethod
    def __class_getitem__(cls, X: object) -> Annotated:
        return Annotated[cls, Is[
            lambda lst: all(is_bearable(i, X) for i in lst)]]

and it didn't returned the results I expected.

As you said, list and tuple satisfy this API, but what about numpy and pandas?

hasattr(pd.Series, "__class_getitem__")  # --> False
is_bearable(pd.Series([1, 2]), SequenceProtocol)  # --> True
is_bearable(pd.Series([1, 2]), SequenceProtocol[int])  # --> True
is_bearable(pd.Series([1, 2]), SequenceProtocol[str])  # --> False

Seems to work even if pd.Series doesn't have the required __class_getitem__ method.

And numpy?

hasattr(np.array, "__class_getitem__")  # --> False
is_bearable(np.array([1, 2]), SequenceProtocol)  # --> True
is_bearable(np.array([1, 2]), SequenceProtocol[int])  # --> False
is_bearable(np.array([1, 2]), SequenceProtocol[str])  # --> False

Behaves differently than pd.Series. So what's heppening here?

tvdboom · 2023-09-10T08:19:03Z

tvdboom
Sep 10, 2023
Author

Although standard Python sequences like list and tuple do define the class_getitem() dunder method and thus satisfy this new horrible SequenceProtocol API, I really doubt that either NumPy or Pandas sequences do.

I think the __class_getitem__ method in the protocol is not being checked. For example, string hasn't class_getitem but still the checks passes (ideally, I would like string to not pass the protocol, but it seems there are no methods shared between list, tuple, pd.Series and np.array that str doesn't have, so how to achieve that...).

is_bearable("teststring", SequenceProtocol)  # -> True

Also, unfortunately, the accepted answer is still not working as we thought it did. It works for list, tuple and pd.Series, but not for numpy arrays.

from beartype.door import is_bearable
from beartype.vale import Is
from beartype.typing import Annotated, TypeVar, Protocol, Iterable

T = TypeVar("T")

class SequenceProtocol(Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

class SequenceProtocolOf(object):
    '''
    Type hint factory class dynamically creating and returning new
    ``Annotated[SequenceProtocol[...], ...]`` type hints, subscripted by the
    passed type.

    Parameters
    ----------
    X : object
        Arbitrary child type hint with which to subscript the
        :class:`SequenceProtocol` protocol.

    Returns
    ----------
    Annotated
        ``Annotated[SequenceProtocol[X], ...]`` type hint validating that *all*
        items of this sequence satisfy this child type hint.
    '''

    @classmethod
    def __class_getitem__(cls, X: object) -> Annotated:
        return Annotated[SequenceProtocol[X], Is[
            lambda lst: all(is_bearable(i, X) for i in lst)]]

print(is_bearable(np.array([1, 2]), SequenceProtocol))
print(is_bearable(np.array([1, 2]), SequenceProtocolOf[int]))
print(is_bearable(np.array([[1, 2], [3, 4]]), SequenceProtocolOf[SequenceProtocolOf[int]]))

returns

true
false
false

1 reply

tvdboom Sep 22, 2023
Author

I must rectify. The accepted solution does work. Numpy fails because np.array([1, 2]) creates values of type np.integer, and not of type int. I still don't understand why protocol is not checking for __class_getitem__ though... Maybe it just skips classmethods?

leycec · 2023-09-23T02:07:08Z

leycec
Sep 23, 2023
Maintainer

I still don't understand why protocol is not checking for __class_getitem__ though... Maybe it just skips @classmethods?

Yup. That's exactly it. beartype.typing.Protocol is currently bugged; it silently ignores @classmethods (and probably @staticmethods, too). But the standard typing.Protocol ABC handles @classmethods (and probably @staticmethods, too) correctly. In other words, both beartype.typing.Protocol and typing.Protocol are horribly deficient – but in completely different ways.

I should probably escalate this to an official @beartype bug. There's not much we can do about the official typing.Protocol implementation, but we should at least fix our own non-standard beartype.typing.Protocol implementation. But... I am tired and it's Friday night. Instead, let's just release @beartype 0.16.2 with completely unrelated bug fixes already! 😩

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Let beartype check custom sequence protocol with inner types #277

{{title}}

Replies: 8 comments 6 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

Select a reply

Let beartype check custom sequence protocol with inner types #277

tvdboom Sep 1, 2023

Replies: 8 comments · 6 replies

leycec Sep 2, 2023 Maintainer

Everything is Bad and Here's the Proof

Not Everything is Bad and Here's the Proof

beartype.typing: Hold My Beer, typing

tvdboom Sep 2, 2023 Author

leycec Sep 2, 2023 Maintainer

I Totally Get What You're Trying to Do Here

tvdboom Sep 4, 2023 Author

leycec Sep 5, 2023 Maintainer

tvdboom Sep 5, 2023 Author

leycec Sep 5, 2023 Maintainer

leycec Sep 5, 2023 Maintainer

tvdboom Sep 7, 2023 Author

leycec Sep 7, 2023 Maintainer

tvdboom Sep 7, 2023 Author

tvdboom Sep 10, 2023 Author

tvdboom Sep 22, 2023 Author

leycec Sep 23, 2023 Maintainer

tvdboom
Sep 1, 2023

Replies: 8 comments 6 replies

leycec
Sep 2, 2023
Maintainer

`beartype.typing`: Hold My Beer, `typing`

tvdboom Sep 2, 2023
Author

leycec
Sep 2, 2023
Maintainer

tvdboom Sep 4, 2023
Author

leycec Sep 5, 2023
Maintainer

tvdboom Sep 5, 2023
Author

leycec
Sep 5, 2023
Maintainer

leycec
Sep 5, 2023
Maintainer

tvdboom
Sep 7, 2023
Author

leycec
Sep 7, 2023
Maintainer

tvdboom Sep 7, 2023
Author

tvdboom
Sep 10, 2023
Author

tvdboom Sep 22, 2023
Author

leycec
Sep 23, 2023
Maintainer