Rename to phantom-types?

[antonagestam]

https://kataskeue.com/gdp.pdf

[sobolevn]

Hi, @antonagestam!

I am a big fan of your work! This package looks amazing.
I do some research on how to make a good validation library in Python (see dry-python/returns#258).
And I really like the concept of Phantom types and things around it.

So, I am really looking forward to having something like this in our dry-python ecosystem.
I have also registered a new package name for this project: https://pypi.org/project/phantoms/

So, maybe you want to:

1. Consider moving this package to dry-python org with some further improvements?
2. Helping us with advice in building our own solution in case you are not interested in moving your project?

We also have a chat where we can discuss this: https://t.me/drypython

[antonagestam]

Hi @sobolevn!

First of all, thanks for reaching out! As you know, a lot of your work inspires me as well.

At this point I don't feel like giving up control of the library. I have a few ideas for types that I want to implement, and I want to see how working with the library as is works when used in a larger application. I might make some drastic API changes for things that aren't as well polished as they could be yet. That said, I am very open to collaborating on this project and warmly welcome thoughts, concrete feedback, ideas and other forms of contribution.

As for using this library for validation, I would look at the dacite example. We've been using dacite (without phantom types) in production for about 6 months for a large e-commerce project. It greatly helps in moving towards domain-driven/type-driven validation.

I just finished work on implementing a wrapper around the phonenumbers lib which I think is interesting because it shows that it's possible to inject normalization into the types themselves (while seemingly obvious in hindsight, it took some thinking for me to figure out how well that would work).

I still have a few unanswered questions when it comes to validation, I think mostly about how to deal with composite types in a nice way. For instance how to type a model where the phone numbers validity depends on a country code field. This should mostly be about how to pipe values to the correct places in instantiation though, and shouldn't necessarily affect the phantom type implementation.

[antonagestam]

@sobolevn Ps. I hope my answer doesn't sound discouraging, it would be awesome to find a way to collaborate!

[sobolevn]

Ps. I hope my answer doesn't sound discouraging, it would be awesome to find a way to collaborate!

Of course not! I know how fun it is to work on your own stuff when you can make all the decisions, take any steps, etc.

So, in this case I will experiment on my own implementation of phantoms. My idea was that we should create two files for each module: some.py and some.pyi.

Here's an example of a phantom type:

# some.py

def NotEmpty(i):
    assert len(i) > 0  # or what-ever
    return i

# some.pyi

class NotEmpty(Container[T]):
    ...

This way we can truly remove types from runtime. Or if TYPE_CHECKING magic might also work for some cases.
I would be happy to show your a prototype sometime soon! 👍

[antonagestam]

@sobolevn That's an interesting solution! However, I don't think I would be satisfied with it for a few reasons:

• I think creating types need to feel lightweight in order for people to adopt it as an alternative to writing validation functions. And so I think requiring the use of stub files would add some friction to adoption. I sort of consider this to be an issue with coherence.
• It doesn't work with established type guards, e.g. I can't use if isinstance(l, NotEmpty): ....

Looking forward to inspecting the prototype! :)

[antonagestam]

@sobolevn I experimented a bit with binding parsers to a dataclass field using Annotated: https://gist.github.com/antonagestam/bc437a063536704eca3d60166fd65e32