validate: seems to be confused by Union[str, Path] vs Path instance

[slippycheeze]

• typical version: 2.0.14
• Python version: 3,8,3
• Operating System: Windows 10 (also macOS)

Description

I suspect this may be a known issue, caused by having more than one plausible conversion applied to the union type, but:

from pathlib import Path
from typing import *
import typic

good = [str, Path, Union[str], Union[Path]]
for types in good:
    typic.validate(this_type, Path.home())
    # success, whatever you homedir is, like:
    WindowsPath('c:/Users/me')

typic.validate(Union[str, Path], Path.home())
# fails:
ConstraintValueError: Given value <WindowsPath('C:/Users/me')> fails constraints: (constraints=((type=str, nullable=False, coerce=False), (type=Path, nullable=False)), nullable=False)
# also fails, identically other than the order of output
typic.validate(Union[Path, str], Path.home())

This confusing type union came from my discovering that I don't actually want strict mode, I want the type coercion to happen, and removing the strict=True from various things. The original type annotation was Union[str, Path, PosixPath] because I found this on macOS, and worked around it blindly thinking it was odd, but strict=True required it.

Now I'm pretty sure it is a ... well, not ideal, but probably an issue picking which type to coerce into or something?

[seandstewart]

Looks like we have two issues here -

1. Validation is broken for Path-types in Unions.
2. We don't coerce Union-types by default.

A proposed feature is in the works to make (2) possible (#72). Currently, Union-types (other than simple Optionals (e.g., Union[, None])) are not automatically coerced because their resolution is unclear - in your example, for instance, how would the deserializer know whether the appropriate type was a string or path object? This is where discriminators come in.

As a workaround for (2), you'd need to implement your own coercer & type-check and register it with typic.register.

As for (1), this should be a simpler fix. I can have something out this morning to properly support magic metaclasses like this.