add tagged union about pydantic-core

[samuelcolvin]

As you may already know I love unions: smart, strict and tagged ones 😄

What about trade unions?

---

syntax looks good.

Questions:

1. Does the field have to be a literal? I think yes.
2. We currently have multiple different sorts of literal, are you going to allow all of them?
3. Maybe this should be a separate validator? Not for performance, more to make it less complex and easier to develop.
4. How are you going to implement it? perhaps you could expose some of the logic in literal as public functions, then reuse them in TaggedUnion? The other option is to change the schema syntax to add a intermediate dict under choice that can include "tags" - this would make generating schema more complex, but it would avoid the need (at least in pydantic-core schema) for the tag as a field, and would make your logic much simpler, you could also limit tags to being string more explicitly. Something like:

'type': 'model',
'fields': {
    'pet': {
        'schema': {
            'type': 'union',
            'tag': 'species',
            'choices': [
                {
                    'tag': 'cat',
                    'schema': {
                        'type': 'model',
                        'fields': {
                            'species': {'schema': {'type': 'literal', 'expected': ['cat']}},
                            'lives': {'schema': {'type': 'int'}, 'default': 9},
                        },
                    }
                },
                {
                    'tag': 'dog',
                    # or maybe
                    'tags': ['dog', 'fox'],
                    {
                        'type': 'model',
                        'fields': {
                            # note that here we don't **need** to have species as a field
                            'barks': {'schema': {'type': 'bool'}},
                        },
                    },
                  }
            ],
        }
    },
},

This is completely up to you, I can see both working and we can probably support both in pydantic.

[PrettyWood]

Does the field have to be a literal? I think yes.

Yes I think we need to check for tagged unions that

• all fields are models
• all models have a field with the tag name and a type literal
• all literal values have no overlap
  and then cache them into a Hashmap (or even FxHashMap?) for immediate validator lookup

We currently have multiple different sorts of literal, are you going to allow all of them?

I was planning to only support string literals (so LiteralSingleString and LiteralMultipleStrings). We could support int literals but I've never seen a usecase in my life so 🤷

Maybe this should be a separate validator? Not for performance, more to make it less complex and easier to develop.

Yep I was tempted! Maybe suggest tagged-union as type. I'll probably go with this approach

The other option is to change the schema syntax to add a intermediate dict under choice that can include "tags"

Probably a good idea! It should avoid adding public methods on fields just for tagged unions. I'll play a bit with the code tonight and come back with a proposal 👍

[samuelcolvin]

sounds good, just strings (both single and multiple) makes sense so they fix into map.

If we went with the different schema, then we no longer care that all choices are models, since we only look at the tag or tags key.

Probably a good idea! It should avoid adding public methods on fields just for tagged unions.

If we did go with the first syntax, no need to add new methods to the trait, just implement that logic as standalone functions in literal.rs, then import and use them in union.rs as well as in the build functions in literal types.

[samuelcolvin]

Might be worth looking at LookupKey in #88 we could reuse it in tagged unions to allow the tag to be somewhere other than the top level dict while reusing existing logic.

[samuelcolvin]

Might be worth looking at LookupKey in #88 we could reuse it in tagged unions to allow the tag to be somewhere other than the top level dict while reusing existing logic.

This is what pydantic/pydantic#4180 wants.

Having thought about this more, I think moving tag / tags into a parent dict and reusing LookupKey is a good idea. LookupKey is now well optimised with support for reusing PyStrings etc.

[samuelcolvin]

@PrettyWood any idea when you might get to work on this?

I need it for #131.

No big hurry. I'm happy to wait a while or take over this if you think you'll be able to work on it.

[PrettyWood]

@samuelcolvin I'm still on holiday until Sunday. And I'll first work on launching Q3 for my company before working more on OSS (even though I'd love to right now).
I had planned to start working on it in 2-3 weeks. I didn't know you needed it too 😆
IMO if you can work on it right now it's better. I know you have everything in mind and probably want to release a v1 asap.
I have only my phone on me but it should be enough to review the code if you wish 🙂

[samuelcolvin]

Understood. Enjoy your holiday and don't worry about it.

I'll let you know when I have a PR and it's completely up to you if you want to review it.