I'm not crazy about the name dataclass_factory. What do you think about dataclass_decorator?

Other suggestions at the core sprint are prepare and decorator.

I'm not crazy about the name dataclass_factory. What do you think about dataclass_decorator?

I think dataclass_decorator makes more sense if @dataclass() is only meant (or at least documented) to be used as a decorator, and not as a "factory" (i.e. MyClass = dataclass(...)).

But anyway, I'm happy to make the change to use dataclass_decorator. Let me know if you want me to push the necessary changes.

@larryhastings : Any thoughts on the parameter name? I'm leaning towards just decorator. I think everyone knows dataclass() as a decorator. dataclass_decorator seems redundant: decorator=dataclass looks reasonable to me: The decorator you'd call if you were statically defining a class.

I think decorator is an excellent name here. Here's some snippets from the definition of decorator from the official Python glossary:

A function returning another function, usually applied as a function transformation using the @wrapper syntax.
Common examples for decorators are classmethod() and staticmethod().

The decorator syntax is merely syntactic sugar, [...] The same concept exists for classes, but is less commonly used there. [...]

That strikes me as an excellent fit. make_dataclass is calling this function to transform a class into another class, and decorators are transformers returning a different object of the same type. I worried the term decorator might specifically refer to "the application of the @-sign syntax", but the glossary makes it clear that's not the focus.

Also, I prefer decorator to factory here because I think of a factory as making a new and different thing out of raw materials. In my mind, a "car factory" ingests sheet metal and bolts and aluminum and paint and fabric and produces a car; it doesn't transform an existing car into a different kind of car. But this callable is transforming one class into another class. So the word decorator is a better fit. (Also factory sounds really Java-y, and who wants that association in the Python world!) I concede this might be a personal taste thing, and other folks wouldn't have these associations... but you did ask my opinion.

I think I'm the dude who suggested preparer at the sprint. It was a straight-off-the-dome suggestion made with little context or consideration. I thought of preparer because of the __prepare__ magic method on metaclasses used during class creation, which I suggest is vaguely analogous. So I think preparer is okay--but decorator is much better!

(Also factory sounds really Java-y, and who wants that association in the Python world!)

Convinced! Just pushed a commit fixing this.

Thanks, @larryhastings for the excellent analysis (I expected nothing less!). I'll review the patch when I have some free time.