pathlib.Path support

It would be nice if there were a Marshmallow field for (de)serializing pathlib.Path objects since these are often more convenient to work with than raw strings and os.path functions. I typically use Marshmallow via marshmallow_dataclass and can work around this with hooks but having builtin support for Paths would be a great addition.

[deckar01]

I would recommend separate field types for validating the mutually exclusive attributes.

class Path(Field)
class Directory(Path)
class File(Path)

Using constructor args for optional validation is convenient, but providing validator classes avoids complex method signatures, if chains, and storing them all as instance properties. Much less code to maintain and more performant. You could minimize the API surface area by making a pass through validator for the boolean checks.

class Relative(Validator)
class Path(Validator):
    ...
    def __call__(self, path):
        for name, expected in self.checks:
            actual = getattr(path, name)()
            if  actual != expected:
                raise ValidationError(...)

Path(validate=[validate.Path(is_absolute=True), validate.Relative('/var/www/')])

I’m not sure if fields for the “pure” paths would need to be exposed also. pathlib doesn’t seem to offer any validation when the path isn’t on the current file system.

[mivade]

What would the is_dir/file/mount/... API look like as field validation?

That’s really the question to me and probably what makes this a bit tricky. I could see something like this:

def __init__(
    self,
    exists: Optional[bool] = None,
    is_dir: Optional[bool] = None,
    is_mount: Optional[bool] = None,
    is_file: Optional[bool] = None,
    ...
) -> None:
    ....

but this is a bit awkward since it wouldn’t make sense to have both is_dir and is_file set to True. This could of course be checked for but it could lead to some odd semantics. I wonder if it might make more sense to define validators that get passed in with the validate kwarg? I do think we might want some convenience boolean options such as resolve, expanduser, etc. which would call Path.resolve, Path.expanduser. Similarly it might be good to have a path_class argument that takes in the type of path class to use.