I'm not crazy about the namedataclass_factory. What do you think aboutdataclass_decorator?

Other suggestions at the core sprint areprepare anddecorator.

I'm not crazy about the namedataclass_factory. What do you think aboutdataclass_decorator?

I thinkdataclass_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 usedataclass_decorator. Let me know if you want me to push the necessary changes.

@larryhastings : Any thoughts on the parameter name? I'm leaning towards justdecorator. I think everyone knowsdataclass() 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 thinkdecorator is an excellent name here. Here's some snippets fromthe definition ofdecorator from the official Python glossary:

A function returning another function, usually applied as a function transformation using the@wrapper syntax.
Common examples for decorators areclassmethod() andstaticmethod().

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 preferdecorator tofactory 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 worddecorator is a better fit. (Alsofactory sounds really Java-y, and who wantsthat association in the Python world!) I concede this might be a personal taste thing, and other folks wouldn't have these associations... but youdid askmy opinion.

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

(Alsofactory sounds really Java-y, and who wantsthat 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.