cattrs VS typing

I'd suggest you look at my cattrs (https://catt.rs) library as a good serde lookalike in Python (sum type support present and getting better), and to use attrs instead of dataclasses in general.

Pydantic is by far not the only library of its kind, with prominent members of the same class being attrs, cattrs or even plain dataclasses for some use cases.

That being said, data serialization is a very common thing to do, so naturally there are tons of libraries that automate it for you. Personally, using dataclasses and cattrs is my goto way for doing such things.

I'm fond of attrs and cattrs myself, attrs make creating data classes a snap, writing all of the stupid code python requires to have a dataclass. Note the new built in dataclass is actually a limited copy of attrs. https://www.attrs.org/en/stable/ and https://github.com/python-attrs/cattrs

This month, I've released version 0.17, and it's now blazing fast; there is in fact no more comparison with Pydantic, which more than 5x slower (up to 30x in serialization). It's also faster than alternatives like mashumaro or cattrs. (See the quick benchmark result in documentation, and the code)

```

Cattrs has some problems with generics [1] [2]. Dacite and marshmallow-dataclasses don't support generics well either, with some issues around Union types.

They do work well for simple python types but what I'd like to see is guarantee that the serialisation operation is completely reversible and if not raise warning/exception.

[1] https://github.com/Tinche/cattrs/issues/149

Iterable[str] is unfortunately evil as it matches str which is often unintended. (see: https://github.com/python/typing/issues/256) One would need both NOT-type and AND-type in order to properly handle these.

The basic motivation behind them is that functions can have arguments that can only take a specific set of values, and those functions return values/types change based on that input. Common examples are (you can find more here):

While yes 26 people liked the idea here: https://github.com/python/typing/issues/193

but looking at relevant issues on GitHub it seems this has been shot down repeatedly. python/typing#18, python/typing#213

See https://github.com/python/typing/issues/256 for a discussion.

Lower bounds are not supported for TypeVars, unfortunately.

Mypy allows that because initial versions of PEP-484 allowed that. This has changed; here's the current wording on the PEP:

> This is no longer the recommended behavior. Type checkers should move towards requiring the optional type to be made explicit.

https://www.python.org/dev/peps/pep-0484/#id29

Dunno, other, larger projects than the one I'm working on seem to run up against this from time to time. (rasa_core, to pick one example from near the top of a Google search; also Telethon, Blender, TensorFlow, Pandas. Guido also filed a bug on the typing module in an early version of Python 3.5 because of unexpected implications of this particular issue, so the problem isn't exactly purely theoretical.) That's aside from the wish for conceptual purity in the call signatures of classes and their subclasses, which is not always and automatically a bad wish to have; and the notion that a language that prides itself on its introspective faculties might want to make introspection of classes from the top of a class hierarchy possible, at least in theory? Perhaps to facility learning about the language and/or visualizing large class hierarchies easily, for instance?