Present Field Name Rather Than Alias When Using Intellisense

[BTripp1986]

Initial Checks

• I have searched Google & GitHub for similar requests and couldn't find anything
• I have read and followed the docs and still think this feature is missing

Description

Thank you for making such an amazing tool.

I have a feature request in regards to aliases. My use case is that I need to use aliases for several of my models to interact with the AWS API. I am representing AWS resources such as:

class Ec2Instance(BaseModel):
  arn: Optional[str] = Field(alias="Arn")
  """Resource ID for the Instance"""
  instance_type: str = Field(alias="InstanceType")
  """The instance type such as t2.micro, t3.xlarge, etc."""
  ...more fields...

  class Config:
    allow_population_by_field_name = True

I need these aliases because this library is used to fetch data via the AWS API, which returns dictionaries with PascalCase keys and the aliases are much more Pythonic than converting each key or using PascalCase for field names.

In addition to fetching data, these models are also used for creating new resources. With the Ec2Instance example above, a user would define all required fields when creating the resource. This library is used by users without expertise of the domain, and the entire point of the library is to make things easier by adding another layer of abstraction where they can use intellisense and inline documentation instead of needing to open the AWS docs in a browser.

Currently, it is almost there, they can hover over parameters when instantiating an object from the model to see the inline docs, but the issue is that intellisense will suggest the PascalCase aliases instead of the field names. Since the Python convention is to use lower_case_with_underscores, I would like to change this behavior.

The workaround the I currently have implemented is ugly and violates the DRY principal:

def aliasing(alias: str) -> str:
    return alias

class Ec2Instance(BaseModel):
  arn: Optional[str] = Field(alias=aliasing("Arn"))
  """Resource ID for the Instance"""
  instance_type: str = Field(alias=aliasing("InstanceType"))
  """The instance type such as t2.micro, t3.xlarge, etc."""
  ...more fields...

  class Config:
    allow_population_by_field_name = True

With this workaround, I get the desired behavior. Is this something that could be added to the model Config? I know you are hesitant to increase the parameters in the model Config, but I would argue that this change will help keep code Pythonic in certain circumstances.

If you are willing to accept a PR then I can make some time to implement this over the next several weeks.

Affected Components

• Compatibility between releases
• Data validation/parsing
• Data serialization - .model_dump() and .model_dump_json()
• JSON Schema
• Dataclasses
• Model Config
• Field Types - adding or changing a particular data type
• Function validation decorator
• Generic Models
• Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
• Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

[dmontagu]

I think you get the same behavior now if you do validation_alias="Arn", serialization_alias="Arn" instead of alias="Arn".

I'm sure you'll say you don't like having to write so much. For what it's worth, it should be essentially trivial to add another argument to Field that is used instead of alias if present that has precisely the same functionality, but just won't get picked up by @dataclass_transform or whatever.

Could use alias_ as the keyword argument even.

I would not be opposed to adding this, precisely because I recognize this is dumb/annoying. But before implementing (whether you or one of the maintainers), it probably makes sense to get consensus from @samuelcolvin and the other pydantic maintainers.

I suspect if we can establish consensus though, this would be a tiny change.

[lig]

I'd say using a function wrapper like this to break the correct alias behavior is a bug by itself. I'm not sure where it originates from, though.

[samuelcolvin]

Could you achieve the same results by either:

• Using an alias generator
• or, defining aliases with AliasPath - presumably intelisense doesn't know how to what to do with AliasPath and might fall back the the field name

?

If neither of those works, I'd be willing to consider an alias for alias.

[lig]

So, with allow_population_by_field_name = True Pydantic allows using both the own name and the alias name to be used for creating a model instance. And using alias attribute following PEP 681 tells all tooling that we should use alias names but with Pydantic it's only one of two possible options.

It seems logical that user could have an intent to use own names as a primary way for instantiating such a model when they explicitly set allow_population_by_field_name flag.

If user would like treating own attribute name as a primary name then the alias becomes some kind of an "alternative alias". I would suggest adding alt_alias parameter for the Field definition that would indicate that this is not the primary but an alternative name we will use to instantiate a model in the code.

[samuelcolvin]

Why not just set validation_alias instead of alias?

[lig]

A model could be instantiated with camel case arguments from the external data, a model could be serialized using camel case arguments, and a model could be instantiated in the code from underscore arguments.

So, it's allow_population_by_field_name in the model config + alias for every field (some fields?). And the intent is to have underscored names used by autocomplete and docs instead of camel cased names.

I think that this particular case could be solved by an alias generator but in general it looks logical to allow an easy way for choosing which of two accepted names to use for autocomplete and docs.

[lig]

As a bonus introducing alt_alias parameter solves the issue on per field basis.

[samuelcolvin]

So does validation_alias, please try that in vscode and pycharm.

[lig]

Does validation_alias implies serialization_alias to be the same? If it does than this is the solution we already support.

[samuelcolvin]

No, you'd need to set serialization_alias as well, but

1. You can.
2. I doubt the OP would want that from their description.

[lig]

@BTripp1986 Could you please clarify, do you need validation_alias and serialization_alias both set for your use case?

[lig]

@samuelcolvin Despite OP's case I really see how this is logical to have such an option.

Additionally, using alt_alias should raise and error if allow_population_by_field_name is not enabled or even imply it. The later is impossible now AFAIU.

[BTripp1986]

Sorry for the late reply. I was not at my laptop over the weekend as it was a holiday in the USA.

@BTripp1986 Could you please clarify, do you need validation_alias and serialization_alias both set for your use case?

I just did some testing and yes, I need both validation_alias and serialization_alias set for the desired behavior.

I was not aware that these params acted this way. I'm still getting used to Pydantic v2 and the docs for those params were confusing to me. It seems that by using both of those parameters I get the exact behavior I am looking for.

I never noticed the alias_generator config param in v2, and it seems like exactly what I am looking for, but I am not getting the expected behavior. Using alias_generator allows me to instantiate a model via

def to_pascal(string: str) -> str:
    return ''.join(word.capitalize() for word in string.split('_'))

class MyModel(BaseModel):
  field_one: str
  field_two: str

  class Config:
    alias_generator = to_pascal

myinstance = MyModel(FieldOne="val1", FieldTwo="val2")

but with that alias generator I would also expect to be able to parse a dict with PascalCase keys, but I cannot.
i.e. MyModel.model_validate({"FieldOne": "val1", "FieldTwo": "val2"}) raises an Exception.

Maybe this is the intended behavior, but it's almost the exact opposite of what I need for this use-case.

Apologies for not understanding validation_alias and serialization_alias. If I provide both with the desired alias as the argument then I get the behavior that I need. Since almost every model that I am using will need this for every field, it seems like either modifying alias_generator to accept dicts with alias keys, or creating a config param as mentioned in the OP would allow a use-case such as mine to avoid a lot of boilerplate, so I'm still happy to make a PR at some point, but this is the behavior that I was looking for so I think closing this issue may also be reasonable if none of the proposed changes seem appropriate.

[BTripp1986]

Some clarification on my use case:

• Users will be receiving data as dicts with keys in PascalCase which I will parse into Pydantic models
• Users will be instantiating models in source code, and then making API calls which expect input dicts with PascalCase keys
• When users instantiate the models in source code, intellisense should show snake_case field names