The last time this idea came up (#743),@dbanty felt that there wasn't a compelling reason to switch fromattrs. I decided anyway to see how much of a lift it would be— in the generated code, that is, not in the generator. A few reasons:

1. In my main use case, which is creating a library to be used by all sorts of third-party applications, there's an incentive to minimize external dependencies if possible.
2. Even thoughattrs is very popular, I think it's likely to become somewhat less of a standard as Python's dataclasses module keeps on copying features from it.
3. It's true thatattrs has some features thatdataclasses doesn't, but we're not really using those features anyway in the generated code (with one exception that I'll mention below). Mostly we're just using the simplest possible attribute declaration pattern in model classes.

As I expected, implementing this for the model classes was pretty simple. The only other place we were usingattrs in the generated code was in theClient andAuthenticatedClient classes, and there things got trickier.

In those classes, we were taking advantage ofattrs'salias option in order to define underscored attributes that the app isn't meant to access directly, but that can still be set by name without the underscore in the initializer. You can't do that with dataclasses. However, since the app isn't meant to access them directly, I felt freer to change things there... and attrs/dataclass-type behavior is not really inherent to what the client classes are for, from the app's point of view, it's just an implementation detail.

So, inuse_dataclasses mode, I changed the clients to plain Python classes with no attrs/dataclass decorators—and moved those Httpx-related attributes into a separate dataclass, so we could still take advantage of copy-and-set behavior for builder methods. That is a fairly different implementation and code structure, which makes the Jinja template a bit hairy, but you can see what it ends up looking likehere. However, when you'renot inuse_dataclasses mode, the implementation does not change at all (you can see there are no changes to existing code ingolden_record), so I believe this is not a breaking change.

(Wecould decide to unify those implementations by backporting those changes to the not-using-dataclasses mode, so the only differences between the two would be the decorator names. I do think that'd be a little bit cleaner— the Httpx options do all go together, and I don't think there's a compelling reason to have them be separate attributes on the client class. And, again, apps were never meant to access those directly... but in Python, we couldn't prevent that, so thatcould be considered a breaking change depending on your standards for what is a public/supported interface.)