schema_type_to_python drops anyOf/oneOf constraints to Any

[Solaris-star]

What

schema_type_to_python handles type, enum, const, and JSON Schema type arrays, but not anyOf or oneOf. A property expressed with either union keyword therefore falls through to Any.

That loses constraints when json_schema_dict_to_pydantic feeds the converted type back into structured generation.

Reproduction

from outlines.types.json_schema_utils import schema_type_to_python

print(schema_type_to_python({
    "anyOf": [{"type": "integer"}, {"type": "string"}],
}, "pydantic"))
# typing.Any (expected Union[int, str])

print(schema_type_to_python({
    "oneOf": [{"type": "boolean"}, {"type": "null"}],
}, "pydantic"))
# typing.Any (expected Optional[bool])

The resulting Pydantic schema has no value constraint at all:

M = json_schema_dict_to_pydantic({
    "type": "object",
    "properties": {
        "value": {"anyOf": [{"type": "integer"}, {"type": "string"}]},
    },
    "required": ["value"],
})
print(M.model_json_schema()["properties"]["value"])
# {"title": "Value"}

Expected

Map each branch recursively and combine them with Union, just as the existing JSON Schema type-array path does. For Python typing/Pydantic, oneOf cannot preserve exclusivity for overlapping branches, but retaining the union of allowed value types is still strictly better than widening to Any.

[ErenAta16]

Reproduced on main (be2cd151), and there's a sharper case than the hand-written schema: Pydantic itself emits anyOf, so this is a round-trip loss rather than an edge case.

class Src(BaseModel):
    maybe_int: Optional[int]
    either: Union[int, str]
    plain: int

Pydantic's own schema for that:

maybe_int  {"anyOf": [{"type": "integer"}, {"type": "null"}], "title": "Maybe Int"}
either     {"anyOf": [{"type": "integer"}, {"type": "string"}], "title": "Either"}
plain      {"title": "Plain", "type": "integer"}

after json_schema_dict_to_pydantic(Src.model_json_schema()):

field	original	round-tripped
maybe_int	Optional[int]	Any
either	Union[int, str]	Any
plain	int	int

So any model with an Optional or Union field loses that field's type entirely on the way through, and the regenerated schema is just {"title": "Maybe Int"} — nothing left to constrain generation with.

The other half of the comparison is that the equivalent type-array spelling already works:

{"type": ["integer", "string"]}                            -> Union[int, str]
{"anyOf": [{"type": "integer"}, {"type": "string"}]}       -> Any

Same constraint, two spellings, different outcomes — and the one that fails is the one Pydantic produces.

On the oneOf point in the issue: Union can't express exclusivity, so an input matching two branches would validate under the mapped type when the schema says it shouldn't. That's a widening, but a much smaller one than Any, which accepts everything including types no branch allows.

Worth noting for whoever picks this up: schema_type_to_python is also being changed in #1970 (the additionalProperties branch, same elif t == "object" chain). Since anyOf/oneOf appear at the top of the function before the type dispatch, the two shouldn't collide, but they touch the same function.