Add support for field alias in dataclass signature

[NeevCohen]

Add support for field alias in dataclass signature

Change Summary

Added support for field alias in dataclass signature.

When creating a dataclass

from dataclasses import field
from pydantic.dataclasses import dataclass, Field

@dataclass
class A:
    a: int = field(metadata={"ge": 1, "alias": "aa"}

The signature of A seems to ignore the alias of a

# In [3]: A.__signature__
# Out[3]: <Signature (a: int) -> None>  # This should be "<Signature (aa: int) -> None>"

# The "ge" validation is supported
# In [4]: A(aa=0)
# ValidationError: 1 validation error for A
# aa
#  Input should be greater than or equal to 1 [type=greater_than_equal, input_value=0, input_type=int]
#    For further information visit https://errors.pydantic.dev/2.5/v/greater_than_equal

Related issue number

Fixing #8367

Checklist

• The pull request title is a good summary of the changes - it will be used in the changelog
• Unit tests for the changes exist
• Tests pass on CI
• Documentation reflects the changes where applicable
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @samuelcolvin

[codspeed-hq]

CodSpeed Performance Report

Merging #8387 will not alter performance

_{Comparing NeevCohen:dataclass-signature-field-alias (f5de0da) with main (a8f3f7a)}

Summary

✅ 10 untouched benchmarks

[NeevCohen]

Please review

[sydney-runkle]

Hi @NeevCohen,

Great start on this. I'm wondering if we can refactor the signature generation to be less redundant in terms of the various attempts we make to extract an alias for a signature.

I've left a few comments on the PR. Let me know if you need more clarification 👍

I'd also be happy to accept your changes and I can do a refactor separately, if you'd prefer 👍

[sydney-runkle]

I don't love mutating the param object here. I think we could find a better solution that's less redundant...

[sydney-runkle]

I'll note, the parameter_post_processor function for the dataclass signature generation also has alias extraction logic, but that only applies when we have a dataclass field using pydantic's Field as a default.

[sydney-runkle]

Ahh, I see why you've modified the param.name here... perhaps that is fine for now then.

[NeevCohen]

I don't love mutating the param object here. I think we could find a better solution that's less redundant...

Yeah it seemed iffy to me too, but the that's what the existing code did so I preferred to stick it. Do you think I should save it in a different variable?

[NeevCohen]

I'll note, the parameter_post_processor function for the dataclass signature generation also has alias extraction logic, but that only applies when we have a dataclass field using pydantic's Field as a default.

Yeah I just looked at process_param_defaults() which gets passed as parameter_post_processor. I thought perhaps I should just add the logic there and avoid the duplication of the alias extraction logic.

Perhaps adding another parameter to it like so

def process_param(param: Parameter, field: Optional[FieldInfo] = None) -> Parameter:
    """Modify the signature for a parameter in a dataclass. If a parameter has a Model field associated with it, use it for modifying the parameter.

    Args:
        param (Parameter): The parameter
        field: An optional Model field associated with the parameter

    Returns:
        Parameter: The custom processed parameter
    """
    # Logic that uses the field if it exists or the parameter default
    ....

Do you think this is good solution?

[sydney-runkle]

Hmm, I like the thought, though overall I'm tempted to not increase the complexity of that function.

Why don't we stick with something similar to your original solution, then do a more significant refactoring to fix #7978 in a separate PR? Could you make the helper function that you've designed private, for now?

As a side note, looks like we changed up the logic for the signature pattern in this PR, which did represent a major reduction in redundancy across signature generation logic: https://github.com/pydantic/pydantic/pull/7925/files.

[sydney-runkle]

I like that you've consolidated shared logic, but let's come up with a more descriptive name for this function, specifically relating to the fact that we're selecting either the alias or field name for the signature's param name.

[sydney-runkle]

Let's also make this private.

[NeevCohen]

After considering your previous comments, I don't think that I should duplicate the logic for extracting the alias since it is implemented in the process_param_defaults() function. Perhaps I should use that function or somehow extract the shared logic between that function and this one. Check out my comment on your other comments.

[NeevCohen]

@sydney-runkle I renamed the function and added better documentation. I couldn't come up with a better solution for the multiple attempts we make to extract an alias for a signature. Since we first have to get the using the param name and the field info, and then the field name and the field info incase a var keyword is provided. Do you have an idea for a better way?

[sydney-runkle]

@NeevCohen,

Looks good for now. I'm ok with merging this into main, knowing that we're going to be doing more work on this function to fix #7978.

I'll be on holiday for a bit over the next few weeks, but will find some time to think about this pattern more 🚀.

Thanks for your help! We're excited to have you as a contributor 😄.