phantom-types icon indicating copy to clipboard operation
phantom-types copied to clipboard

Consider refactoring the `.parse()` method into a typeclass

Open antonagestam opened this issue 3 years ago • 0 comments

https://github.com/dry-python/classes

  • [ ] Figure out if a typeclasses are compatible with phantom types
  • [ ] Come up with a reasonable API that is optimally backwards compatible the .parse() method. Is there value in allowing them to co-exist?

The background is I want to introduce dateutil-backed parsing for TZAware, but I don't want to make dateutil a required dependency. So the idea is to only define the parse function for TZAware when dateutil is installed. The type could still be usable without its parsing capabilities, e.g. to exclude non-tz-aware datetimes without having the ability to parse string-formatted timestamps.


Further reasoning: perhaps the .parse() method of every phantom type should be a typeclass? That way, by default TZAware.parse() would be implemented for datetime.datetime. When dateutil is installed TZAware.parse() would also be implemented for str and int.

antonagestam avatar Apr 22 '22 09:04 antonagestam