Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lazy deserialiser not found depending on order of registration #488

Open
DiamondJoseph opened this issue Oct 10, 2022 · 1 comment
Open
Labels
question Further information is requested

Comments

@DiamondJoseph
Copy link

When registering a lazy deserialiser for a type that extends Protocol, the type can be made not findable by the addition of an unrelated type. The following code correctly finds the deserialiser, unless Bar is registered before Foo- Bar can also be found if baz is removed.

from typing import Protocol, runtime_checkable

from apischema import deserialize, deserializer
from apischema.conversions import Conversion


@runtime_checkable
class Foo(Protocol):
    ...


@runtime_checkable
class Bar(Protocol):
    def baz(self):
        ...


for protocol in [Foo, Bar]:
    deserializer(
        lazy=lambda: Conversion(lambda as_str: ..., source=str, target=protocol),
        target=protocol,
    )


assert deserialize(Bar, "foo") == ...
@wyfo wyfo added the question Further information is requested label Dec 12, 2022
@wyfo
Copy link
Owner

wyfo commented Dec 12, 2022

I'm not sure to understand the issue, but there is a bug in your example: lambda: Conversion(lambda as_str: ..., source=str, target=protocol) should be lambda protocol=protocol: Conversion(lambda as_str: ..., source=str, target=protocol) (see https://stackoverflow.com/questions/7546285/creating-lambda-inside-a-loop for example)

By fixing your example, I can either write for protocol in [Foo, Bar] or for protocol in [Bar, Foo] and both works, so I cannot reproduce your issue. Am I missing something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants