CodSpeed Performance Report

Merging #8519 will not alter performance

_{Comparing conradogarciaberrotaran:add-secret-date-field (253a5a2) with main (b2aa36a)}

Summary

✅ 10 untouched benchmarks

@conradogarciaberrotaran,

Thanks for your work on this! Looking great thus far. Just curious - are there any other types that you'd like to see SecretX versions of?

The tests look great 🚀.

Now that we have more than just 2 SecretX types (used to just be SecretStr and SecretBytes), I think it makes sense to change the _SecretField class to more cleanly support a variety of secret types. I need to think a bit more about what the best pattern for this is.

Would it be ok if I pull your branch down and try a few variations on the code that you've added thus far?

Sure! This was a quick implementation I've tried. I'm not yet fully familiar with V2 way of defining new types.
I was thinking that we could make it a kwarg of Field, as in

foo: str = Field(secret=True)
SecretStr = Annotate[str, Field(secret=True]

what do you think?

@conradogarciaberrotaran,

Great, I'll pull it down soon :).

I can see the argument for that, though I think it spirals in that we'd have to support secret behavior for all types in that case. I think for now we'll probably want to stick with explicitly defined secret types.

Makes sense, let me know how can I assist, I'd really like to contribute with Pydantic :)

@conradogarciaberrotaran,

Sure thing! Alright, I've pushed some changes in regards to how we inherit from _SecretField.

Currently, we don't support the validation of SecretX types on their own. For example:

from pydantic import SecretStr, TypeAdapter, ValidationError

s_invalid = SecretStr(123)
print(f"type: {type(s_invalid.get_secret_value())}, value: {s_invalid.get_secret_value()}")
#> type: <class 'int'>, value: 123

try:
    ta = TypeAdapter(SecretStr)
    s_validated = ta.validate_python(123)
except ValidationError as e:
    print(f"ValidationError: {e}")
    """
    ValidationError: 1 validation error for json-or-python[json=function-after[SecretStr(), str],python=union[is-instance[SecretStr],function-after[SecretStr(), str]]]
    Input should be a valid string [type=string_type, input_value=123, input_type=int]
        For further information visit https://errors.pydantic.dev/2.6/v/string_type
    """

I've removed the support for this for SecretDate. I've also modified a few of the tests that are failing as a consequence of this removed support.

I think for now, we should stick to not supporting that behavior, as implementation would require some complex changes (I don't think we'd want to import the SchemaValidator directly).

As a side note, this issue is related to the above discussion: This issue is related: #7353.

@conradogarciaberrotaran,

I'll make sure everything is working in terms of linting / testing, then hand this back to you :).

@conradogarciaberrotaran,

Makes sense, let me know how can I assist, I'd really like to contribute with Pydantic :)

Could you please update this example with SecretDate functionality? https://docs.pydantic.dev/latest/examples/secrets/#serialize-secretstr-and-secretbytes-as-plain-text

Other than that, I think this PR is ready for review, so I'll mark it as such. I've labeled many of our other issues as help wanted if you're interested in tackling another task!

Thanks a bunch for your help with this - we're super excited to adopt this feature :).

Please review

Thanks! I'll take a look at the docs and will probably try to make a secret Enum!

Thanks! I'll take a look at the docs and will probably try to make a secret Enum!

Sounds great! Ping me for a review when you're done :).

idea looks good, I wonder if we're be better to implement this via

SecretDate = Annotated[date, Secret(repr=lambda value: '****/**/**')]

So we can easily add more types, even if we can't use the Secret type for SecretStr and SecretBytes until V3 for compatibility reasons.

Agreed. @conradogarciaberrotaran, are you interested in adding this type, or would you like me to? I can also help you get a start if you need 👍.

Also, thanks for making the changes that @samuelcolvin requested. Your changes look good.

Just pushed missing tests and doc updates!
let me know if we're missing something else

please review

Update, I don't think this is required for this PR:

 Figure out how to support Strict() specification on Secret types directly, now that we're not using the clunky Union schema

It'd be a nice feature down the line, but you can currently apply Strict on the inner type, which is a good enough start!

I believe all relevant concerns have been addressed here and this is ready for review :).

@conradogarciaberrotaran,

Nice work on helping implement this new feature! It'll be one of the highlights of our 2.7 release :).

Thanks for your help! I hope I can contribute more in the future.