Better DX with custom decorators

[pauleveritt]

In Pyramid etc. you write @view(context=Customer). In Antidote you would write this as: @implements(View).when(qualified_by=Customer).

This is nice as it lets framework writers create domain-specific concepts pretty easily.

In Hopscotch I made it easy to write custom decorators such as @view using a base class.

I wonder if we could promote this pattern in Antidote using as a partial function.

[Finistere]

I'm not sure to see what could be really simplified for @view by Antidote in the following example:

from typing import Callable, Type, TypeVar

from antidote import implements, interface, world


@interface
class View:
    pass


V = TypeVar('V', bound=Type[View])


def view(context: object) -> Callable[[V], V]:
    def decorate(cls: V) -> V:
        implements(View).when(qualified_by=context)(cls)
        return cls

    return decorate


Customer = object()


@view(context=Customer)
class ViewImpl(View):
    pass

IMHO, that's as far as it can get.

[pauleveritt]

This was really cool!

Then I changed it to a Protocol and of course, it failed because TypeVar and Protocol etc. etc. Is there any variation that would be meaningful in a Protocol oriented system?

[Finistere]

Using Protocols and @inject works for me:

from typing import Callable, Protocol, Type, TypeVar

from antidote import implements, inject, interface, world


@interface
class View(Protocol):
    pass


V = TypeVar('V', bound=Type[View])


def view(context: object) -> Callable[[V], V]:
    def decorate(cls: V) -> V:
        implements(View).when(qualified_by=context)(cls)
        return cls

    return decorate


Customer = object()


@view(context=Customer)
class ViewImpl:
    pass


@inject
def f(customer_view: View = inject.me()) -> View:
    return customer_view


assert f() is world.get(ViewImpl)

However, it's a good point, I didn't expect the following Mypy error when calling world.get[View].single() with a Protocol:

Only concrete class can be given where "Type[View]" is expected

It's unclear to me how to properly handle this though...

[pauleveritt]

Yes, that error was part of what I uncovered with mypy.

[pauleveritt]

@Finistere Would it be worth me putting out a call on Twitter for suggestions? I don't think the Antidote parts are part of the issue.

[Finistere]

Well currently the solution would be either just using injection with @inject which works or do a cast:

world.get(cast(Type[View], View))

@inject
def get_view(view: View = inject.me()) -> View:
    return view

It's explained in the PEP544 https://peps.python.org/pep-0544/#type-and-class-objects-vs-protocols why View is not considered a Type[View] which seems logical to me. All in all, it's only a typing issue so a cast/# type: ignore does "solve" it and world.get should be considerably less used than @inject as it's not dependency injection anymore.

[Finistere]

I suppose what we would need here is a ProtocolType[View] or something like it, to explicitly state we also accept a Protocol.