gh-98886: Fix issues with dataclass fields with special underscore names

[hauntsaninja]

This commit prefixes __dataclass to several things in the locals dict:

• Names like _dflt_ (which cause trouble, see first test)
• Names like _type_ (not known to be able to cause trouble)
• _return_type (not known to able to cause trouble)
• _HAS_DEFAULT_FACTORY (which causes trouble, see second test)

In addition, this removes MISSING from the locals dict. As far as I can tell, this wasn't needed even in the initial implementation of dataclasses.py (and tests on that version passed with it removed). This makes me wary :-)

This is basically a continuation of #96151, where fixing this was welcomed in #98143 (comment)

• Issue: Fields with single underscore names can mess up dataclasses #98886

[carljm]

The name you eventually settled on for builtins.object in #98143 is __dataclass_builtins_object__. This name uses both initial and trailing double-underscore. That seems ideal to me, since such names are explicitly reserved for Python's use, whereas names that are only prefixed with a double underscore are merely private (and mangled), but not reserved. And in fact today it is possible to make a dataclass with a double-underscore-prefixed attribute, and the basics at least seem to work fine (the field name is mangled, as expected.)

What do you think about changing all the names in this PR to have both leading and trailing underscores?

[hauntsaninja]

Thanks, fixed!

[carljm]

LGTM. I agree the MISSING thing is a bit odd, but I examined the code for _init_fn and the functions it calls (_init_param and _field_init) and I can't see any way for MISSING to show up in the text of the init function to create. And clearly the tests pass without it.