Refactor logic to support Pydantic's Field() function in dataclasses

[Viicos]

Change Summary

Fixes #12045.
Part of #11613.

Related issue number

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

[cloudflare-workers-and-pages]

Deploying pydantic-docs with    Cloudflare Pages

Latest commit:	b1e3452
Status:	✅  Deploy successful!
Preview URL:	https://035322ad.pydantic-docs.pages.dev
Branch Preview URL:	https://dataclass-field-fix.pydantic-docs.pages.dev

View logs

[codspeed-hq]

CodSpeed Performance Report

Merging #12051 will not alter performance

_{Comparing dataclass-field-fix (b1e3452) with main (3a7fe26)}

Summary

✅ 46 untouched benchmarks

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
pydantic
dataclasses.py
pydantic/_internal
_dataclasses.py
Project Total

This report was generated by python-coverage-comment-action

[davidhewitt]

Wow, powerful!

If there's no alternative, moving ahead with this seems the most reasonable option to preserve correct semantics.

It would be nice if we could localise the patching just to the under-construction type somehow. I posted an idea but no idea if it actually works.

[davidhewitt]

Agreed, scary. If this became a problem, I think we could do stuff like set the field to be a wrapper object which checks what thread it's on and only exhibits the patched behaviour on this thread, but even that is observable so why bother 😢

[Viicos]

Yeah I think if we ever get issues about this, we could wrap the mutation in a threading lock (similar to what I've initially tried to do in #11851). For this to be an issue, a user would have to dynamically create Pydantic dataclasses in a multi-threaded environment, and have them subclassing a stdlib dataclass with at least one field using the Pydantic's Field() function which is quite unlikely to happen.

[davidhewitt]

I wonder, rather than mutating the fields of the base objects, is there a world where we instead patch the class attributes of the type under construction? That might be significantly less far-reaching in potential conflict?

[Viicos]

The issue is that the dataclasses module is doing roughly:

fields: dict[str, Field] = {}

for b in cls.__mro__[-1:0:-1]:
    base_fields = getattr(b, '__dataclass_fields__', None)
    if base_fields is not None:
        for f_name, f in base_fields.items():
            fields[f_name] = f

# Then fetch the annotations of the class under construction and build fields for it

I thought about patching the whole __dataclass_fields__ attribute directly, without mutating the original dict, but I don't know which one is best. I think we can revisit if we ever get issues.

[Viicos]

FastAPI failures are unrelated, we merged a PR that changed the JSON Schema for decimals.

[davidhewitt]

Discussion makes sense, lgtm 👍