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 😢

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'sField() function which is quite unlikely to happen.

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?

The issue is that the dataclasses module is doing roughly:

fields:dict[str,Field]= {}forbincls.__mro__[-1:0:-1]:base_fields=getattr(b,'__dataclass_fields__',None)ifbase_fieldsisnotNone:forf_name,finbase_fields.items():fields[f_name]=f# Then fetch the annotations of the class under construction and build fields for it