[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] PEP 544 (Protocols): adding a protocol to a class post-hoc


PEP 544 specifies this address as "Discussions-To" so I hope I'm at the
right address.

I think protocols as defined in the PEP are a very interesting idea and I'm
thinking of ways of applying them. The first use case is in the context of

attrs has a number of functions that work only on attrs classes; asdict for
example (turns an attrs class into a dictionary recursively). We can't
really type hint this properly using nominal subtyping since attrs classes
don't have an exclusive ancestor. But it sounds like we could use
structural subtyping!

An attrs class has a special class-level field, __attrs_attrs__, which
holds the attribute definitions. So maybe we can define a protocol:

class AttrsClass(Protocol):
    __attrs_attrs__: ClassVar[Tuple[Attribute, ...]]

then we could define asdict as (simplified):

def asdict(inst: AttrsClass) -> Dict[str, Any]:

and it should work out. My question is how to actually add this protocol to
attrs classes. Now, we currently have an attrs plugin in mypy so maybe some
magic in there could make it happen in this particular case.

My second use case is a small library I've developed for work, which
basically wraps attrs and generates and sticks methods on a class for
serialization/deserialization. Consider the following short program, which
does not typecheck on the current mypy.

class Serializable(Protocol):
    def __serialize__(self) -> int:

def make_serializable(cl: Type) -> Type:
    cl = attr.s(cl)
    cl.__serialize__ = lambda self: 1
    return cl

class A:
    a: int = attr.ib()

def serialize(inst: Serializable) -> int:
    return inst.__serialize__()


error: Argument 1 to "serialize" has incompatible type "A"; expected
error: Too many arguments for "A"

I have no desire to write a mypy plugin for this library. So I guess what
is needed is a way to annotate the class decorator, telling mypy it's
adding a protocol to a class. It seems to have trouble getting to this
conclusion by itself. (The second error implies the attrs plugin doesn't
handle wrapping attr.s, which is unfortunate but a different issue.)

I have found this pattern of decorating classes and enriching them with
additional methods at run-time really powerful, especially when used with
run-time parsing of type information (that often gets a bad rep on this
list, I've noticed :) The structural typing subsystem seems like a good fit
for use cases like this, and I think it'd be a shame if we couldn't make it
work somehow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180701/feb9ced5/attachment.html>