On Fri, Dec 24, 2021 at 9:38 AM Anton Agestam <antonagestam@gmail.com> wrote:

(Hoping I figured out how to reply in the thread now... )

(Almost. Your message came through (we have moderation for new list members because of insistent spammers) but my mail reader doesn't show it in the same thread. That happens a lot so let's not worry about it.)

Yes, sorry for the cryptic message but it looks like you got it right. The example isn't impressive but just like Steven is saying the value comes in larger applications. In a web application for instance only the parsing layer will have to deal with the runtime validation of the type. The business logic and database layers can use static type checking to make sure only the narrowed value is allowed. So it's kind of like a NewType plus an "instantiation predicate" (I'm failing to find the correct term, nothing is actually instantiated).

Let me see if I understand what happens here ( https://github.com/antonagestam/phantom-types/blob/main/README.md#examples), without trying to understand the source code: class Name(str, Phantom, predicate=contained({"Jane", "Joe"})): ... greet(Name.parse("Jane")) To the static type checker (mypy, Pyre, pyright etc.) the argument to greet() has type Name, which is a class. But at runtime its __class__ is just str -- but through the magic of __instancecheck__, isinstance("Joe", Name) still returns True. This is indeed cool. It's also cool that because of the isinstance() trick, static checkers will narrow the type correctly after 'if isinstance(x, Name)' or 'assert isinstance(x, Name)'. I suppose there's some caching going on as well? (Throwing in an lru_cache somewhere would seem easy and I can't see a downside.) I'm curious if this is still useful if you want to parse a longer string into components. Could this be made to parse a long string into an HTTP header struct returning a dic[str, str] (or whatever data structure is appropriate)?

I thought it's relevant here since I imagine a NotType would also have to rely a lot on runtime narrowing. If a downstream API takes Sequence & Not[str] and we have a Sequence available, we'd have to narrow it with something like assert not isinstance(..., str).

That makes sense, although the more likely scenario is that the value we have in hand is known to be a list[str], for example. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>

I have been using Anton's library for quite some time now. Mostly together with my own library: typeclasses (FP concept) https://classes.readthedocs.io/en/latest/pages/concept.html#delegates It is a great tool. I can highly recommend it. The main problem is that it does not work with mutable types by design. Why? What? For example, you want to write a phantom type called "ListOfPositiveInt". So it can be used like so: `isinstance(arg, ListOfPositiveInt)`. But, the problem is: `list` is mutable. After this check passes, you can call `arg.append(-100)` and ruin your precise type. That's why it is limited to immutable types only. сб, 25 дек. 2021 г. в 02:22, Eric Traut <eric@traut.com>:

I haven't heard the term "phantom type" previously, but I like the idea. It's conceptually simple and yet quite powerful. Anton, it looks like this is a relatively new library. What has the feedback been so far? Is it getting significant uptake? Do you know if it has been adopted in any large code bases other than your own?

If I understand the motivations behind the "NotType" proposal, it seems to me that phantom types could solve most (all?) of the intended use cases without all of the downsides that I previously raised.

Are there any changes to the current type system, the runtime, or the current static type checker implementations that are needed to support phantom types? From the above discussion and the documentation , it sounds like the answer might be "no".

-Eric _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: n.a.sobolev@gmail.com