pydantic compatible types

[xneanq]

Hi I was fiddling around trying to implement pydantic compatible subclasses of whenever classes potentially to add to pydantic-extra-types but they're marked @Final

What's the reason for them to be @Final?

Any chance you would implement pydantic methods or lift the @Final restriction?

[ariebovenberg]

Hi @xneanq, thanks for opening this issue.

Regarding @final: they are marked this way for two reasons:

1. In my experience, designing a class for subclassing requires special attention (i.e. documenting what you can override, what parts are stable, method call order, etc.). Since all classes in whenever are designed as concrete classes, it was most straightforward to simply mark them as "final". It prevents subclassing since the classes aren't designed for it.
2. The rust extension is able to optimize performance in some cases because there are no unexpected subclasses.

That said, Pydantic compatibility seems like a good idea, considering its popularity 👍 . What would needed to be implement in order to be pydantic-compatible? Perhaps some kind of patching can be done 🤔

[illphil]

looking at the pendulum_dt.py in pydantic-extra-types it looks like a few methods would need to be implemented which look fairly simple

I'm not sure the neatest was to proceed, my first thoughts revolve around a mixin class implementing the required methods conditional on pydantic being available perhaps via extras

[ariebovenberg]

At the moment, my preferred way would be to add the required methods directly to the whenever library.

This may take some time to implement though, as I want to do make sure it integrates well with pydantics customization options.

If you need pydantic support today, the best solution would be to use Annotated, as described here

[ariebovenberg]

Looking at pendulum_dt more closely, you should be able to build a similarly functioning whenever plugin without subclassing:

# pydantic_extra_types/whenever.py
from whenever import LocalDateTime as _LocalDateTime
from typing import Annotated

class _LocalDateTimePydanticAnnotation:
    @classmethod
    def __get_pydantic_core_schema__(...): ...
    @classmethod
    def __get_pydantic_json_schema__(...): ...

LocalDateTime = Annotated[_LocalDateTime, _LocalDateTimePydanticAnnotation]

the result:

from pydantic_extra_types.whenever import LocalDateTime

class MyModel(Model):
    x: LocalDateTime

# still usable as a class
LocalDateTime.MIN  # still works
LocalDateTime(2020, 1, 1)  # also works

note that in the long term, it'd always be nicer to do:

from whenever import LocalDateTime

class MyPydanticModel(Model):
    x: LocalDateTime  # usable directly

[illphil]

sounds like you've got the next release in the bag ;)

[ariebovenberg]

@illphil well, I suppose it's a two-phase thing:

1. add the Annotated thing to pydantic_extra_types. @illphil @xneanq feel free to take this up. No changes to whenever needed.
2. in the long term, add support to whenever directly. However, seeing as option (1) is so reasonable, it's unsure if this would even be needed.

[dusktreader]

@ariebovenberg I've opened this PR in pydantic-extra-types to add in annotated types for most of whenever's tyeps: pydantic/pydantic-extra-types#310

[ariebovenberg]

Hi @dusktreader thanks but maybe wait off on this until the next release of whenever, which includes some relevant changes and may even add pydantic support built-in

[dusktreader]

@ariebovenberg: OK. I will close the PR.

[ariebovenberg]

@dusktreader sorry for the confusion 😬 . Looking at your PR, it looks like we can reuse most of it 👍 . I'm mostly AFK this week, so I can look it over in detail later.

[ariebovenberg]

@dusktreader looking at your PR, pydantic support is quite a bit more complex than I thought. Perhaps you can help me understand some pydantic_core's validation API:

• Is it customary for a validator to "try everything until something works"? i.e. in your example, we first try ISO, then RFC2822. What's to stop from trying dateutil.parse afterwards? I'm not saying we should, but is where to draw the line? Pydantic has quite idiosyncratic some logic to how it parses datetimes. My own preference is to keep things simple—just parsing ISO. Or do many people really need to "parse whatever"?
• In your PR, you use no_info_wrap_validator_function but don't seem to use the "inner" handler. Could we just use no_info_plain_validator_function to simplify? Or is there some other reason to use the wrapping validator, perhaps it sets some useful metadata?
• Is it necessary to support pydantic v1? Or is everybody already moved to V2?

[ariebovenberg]

Also note: pydantic support won't make it into the very next release (0.8) because it's already quite big as-is. Pydantic support is near the top of the list for features after this though