Changes to list, tuple, set, frozenset coersion

Stop coercing set / frozenset to list / tuple?

Although this is not “loosing information”, the result is not deterministic/repeatable.

E.g. if you have the Field Tuple[PositiveInt, NegativeInt, str] then the input set {1, -1, 'a'} will work sometimes, and fail sometimes - this is pretty confusing.

I think we should change this.

Stop coercing list / tuple to set / frozenset?

Should we allow coercing a list to a set? In this case we are “loosing information” (e.g. order), however creating a set from a list is often desired - e.g. when parsing a format (yaml, toml etc.) that only has a list type.

I think we should not change this

Add coercing dict_key to set / frozenset?

Not that common, but we have it now and I think it kind of makes sense since dict_key “feels like” (sorry to be fluffy) a set.

I guess since dict_key are ordered, it should be fine to coerce them to list and tuple too.

I guess as with currently, we should allow dict_values to all these types too?

I think we should change this.

Generators?

In pydantic V1 we allow converting a generator to any of these types.

I think we should allow converting a generator to a list or tuple, but not set or frozenset.

@PrettyWood @tiangolo thoughts?

[PrettyWood]

I didn’t mean to cover JSON parsing separately. Better to have one rule for all.

I think we need to either add two clauses to the cod-philosophy theory of pydantic type coercion:

• If coercion of the input type to the output type is not deterministic, throw an error. HARD RULE - never broken.
• we’re more permissive when downcasting than upcasting - or more generally - we’re more willing to coerce to a more specific less common type from a more general common type than visa versa - e.g. str -> Path, list -> set. SOFT RULE.

👍 As long as the rule is clear and explicit it’s great

[PrettyWood]

In fact the sentence If the input data has a SINGLE and INTUITIVE representation here explains already why sets should not be coerced to lists for example: since {1, 2, 3} is not the only representation, {2, 1, 3} is also valid

---

@samuelcolvin I opened https://github.com/samuelcolvin/pydantic-core/pull/208 IMO if list -> set is allowed, generator -> set should be allowed too (iterators). We can start by tackling those two points on which we seem to agree. Other changes on coercion can always be made afterwards