I've heavily tested all of the config / runtime setting combos for each applicable schema type in pydantic-core. It feels redundant to do so here as well, so I've gone with the simple model only approach.

This makes me think the literal pattern would really fit better here.. If having this boolean pattern on two configuration values only introduced the inconsistency when setting both validate_by_alias=False, validate_by_name=False, it would be fine (I don't see why users would do so), but I won't be surprised if many users find it counter-intuitive that you also need to set validate_by_name=True here.

I think it's worth reconsidering, cc @samuelcolvin

Also, what should happen if you set validate_by_alias=False, but explicitly set by_alias=True or by_name=True during validation?

Also, what should happen if you set validate_by_alias=False, but explicitly set by_alias=True or by_name=True during validation?

Validation time settings always take priority, when set. This is the same with strict.

I'm sympathetic to the literal pattern argument. If we were starting fully from scratch, I think it might make more sense. Specifically, the boolean traps can be a bit confusing. In particular, the fact that you have to set validate_by_name=True if validate_by_alias=False explicitly is a bit confusing, especially for new users.

One thing we could do to mitigate this challenge is automatically set validate_by_name=True if a user sets validate_By_alias=False.

My thoughts re why we should stick with the 2 boolean flags:

• It represents less change to this setting compared to a switch to literals - there's already a lot of change going on here, and I'm hesitant to introduce a setting type change as well.
• 2 boolean flags provide greater configurability for interaction between config and runtime settings, as you can override one behavior and not the other. It's also helpful to have unset markers for each thing. For example:

M1: validate_by_alias = True, validate_by_name = False
M2: validate_by_alias = False, validate_by_name = True

runtime setting: by_name = True

==>

M1: alias and name validation
M2: name only validation

This can't be achieved with the literal approach. Either you'd use:

• validate_by='name', and M1 would lose alias validation

• validate_by='name and alias' and M2 would no longer avoid validating with alias

• Autocomplete is easier with boolean flags, and the behavior is relatively intuitive

Aliases are one of the most common (if not the most commonly used) field tool, so I do think this decision is quite important. I also understand that if we go with bools here, we're stuck with that until at least V4.

Yes, as discussed on Slack, thanks for summing things up here, this might be useful as a reference in case we get questions about the current API.

As we discussed as well, defaulting validate_by_name to True if validate_by_alias is set to False is postponed after this PR, and should be tackled either before 2.11 or after. Leaving this conversation unresolved so that it's easier to find it later.

I'm thinking if we should have another pair of ConfigDict settings instantiate_by_name and instantiate_by_alias to distinguish it from model_validate_X (and we should allow them to coexist, resulting in an overloaded __init__).

For background see #8379 (comment) and #6762

You mean instanciate_by_* only take effect on direct instantiation (i.e. Model(...))?

This would really complicate the API. Using __init__ directly is better suited when you provide the arguments directly (e.g. Model(a=1, b='test')). In that case, the user can simply provide the aliases (and this is what static type checkers will enforce, we have no control over it).

If you want to validate data where you don't control the provided keys, then model_validate() is better suited anyway: Model.model_validate({'a': 1, 'b': 'test'}), and you can provide by_name=True there.

Using __init__ directly is better suited when you provide the arguments directly (e.g. Model(a=1, b='test')).

This is exactly why some (I would say most if we consider popular serialization frameworks in other languages) developers are reluctant to use alias in a direct instantiation. Field names are carefully chosen according to language conventions, e.g. snake_case for Python, while aliases are decided by business logic. We wouldn't like to see things like Model(SomeRandomValue=147, Env_Global='test') in a Python code review, and it would be unfortunate if we need to annotate every model_validate_X call for this reason.

If we don't want that complexity, I would suggest enforcing validate_by_name for __init__ (keep the current behavior in v2 for compatibility). This is intuitive and aligned with dataclass and other frameworks in statically typed languages.

validate_by_name logic still applies to __init__ :)

This is intuitive and aligned with dataclass and other frameworks in statically typed languages.

Dataclasses don't make use of aliases, but this is something supported by the @dataclass_transform spec, and as per the fields specifiers section:

alias is an optional str parameter that provides an alternative name for the field. This alternative name is used in the synthesized __init__ method.

But I get your point, Model(SomeRandomValue=147, Env_Global='test') feels weird in Python code. The fact that type checkers will enforce aliases in __init__ is unfortunate though.

This merits a broader discussion, currently we don't have a proper distinction between direct instantiation (__init__) and the model_validate(_*) methods when it comes to validation behavior.

@stevapple, feel free to open an issue with a summary of this discussion!