Skip to content

Order of alias given in AliasChoices yield different results #408

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
andlogreg opened this issue Sep 18, 2024 · 3 comments · Fixed by #411
Closed

Order of alias given in AliasChoices yield different results #408

andlogreg opened this issue Sep 18, 2024 · 3 comments · Fixed by #411
Labels
bug Something isn't working

Comments

@andlogreg
Copy link

Versions:

pydantic                       2.9.2
pydantic_core                  2.23.4
pydantic-settings              [current main branch so that this fix is present: https://github.com/pydantic/pydantic-settings/pull/400]

In the continuation of #406 I've found that the order of the alias given in AliasChoices change the behaviour, which I believe, shouldn't be the case.

Given the following example:

# test_config.py
from pydantic import Field
from pydantic_settings import BaseSettings, SettingsConfigDict
from pydantic import Field, AliasChoices, BaseModel, AliasGenerator, ConfigDict
from typing import List

validation_alias_a = lambda x: AliasChoices(x, x.replace('_','-'))
validation_alias_b = lambda x: AliasChoices(x.replace('_','-'), x)

my_validation_alias = validation_alias_a

class SubModel(BaseModel):
    sub_list: List[str] = Field(
        default_factory=list, description="A list argument",
    )
    model_config = ConfigDict(
        alias_generator=AliasGenerator(validation_alias=my_validation_alias)
    )

class MySettings(BaseSettings):
    sub_model: SubModel = Field(
        SubModel(),
    )

    model_config = SettingsConfigDict(
        cli_parse_args=True,
        env_nested_delimiter="__",
        alias_generator=AliasGenerator(validation_alias=my_validation_alias)
    )

settings = MySettings()

print(settings)

The following works as expected:

# python test_config.py --sub-model.sub-list=a,b,c
sub_model=SubModel(sub_list=['a', 'b', 'c'])

But if I change the validation_alias:

(...)
my_validation_alias = validation_alias_b
(...)

Then the following fails

# python test_config.py --sub-model.sub-list=a,b,c
Traceback (most recent call last):
  File "./test_config.py", line 30, in <module>
    settings = MySettings()
  File "/usr/local/lib/python3.10/site-packages/pydantic_settings/main.py", line 155, in __init__
    super().__init__(
  File "/usr/local/lib/python3.10/site-packages/pydantic/main.py", line 212, in __init__
    validated_self = self.__pydantic_validator__.validate_python(data, self_instance=self)
pydantic_core._pydantic_core.ValidationError: 1 validation error for MySettings
sub_model.sub-list
  Input should be a valid list [type=list_type, input_value='["a","b","c"]', input_type=str]
    For further information visit https://errors.pydantic.dev/2.9/v/list_type

In fact, if both of the alias do not include the field name itself (the x), for example:

(...)
validation_alias_a = lambda x: AliasChoices(x.replace('_','__'), x.replace('_','-'))
validation_alias_b = lambda x: AliasChoices(x.replace('_','-'), x.replace('_','__'))
(...)

then the error is always thrown.


Not sure if it's in pydantic or pydantic-settings. But I guess this is a bug?

Note this is not a deal breaker since with the workaround of including x as the first alias choice mitigates it.

@hramezani
Copy link
Member

Thanks @andlogreg for reporting this bug.

I've created #411 as a fix. Could you please confirm?

@hramezani hramezani added bug Something isn't working and removed unconfirmed labels Sep 19, 2024
@andlogreg
Copy link
Author

Thanks @andlogreg for reporting this bug.

I've created #411 as a fix. Could you please confirm?

Thanks @hramezani I can confirm the example above works.

@hramezani
Copy link
Member

Thanks @andlogreg for confirming!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants