Replace attrs in generated models?

[michaeloliverx]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
TypedDict might be a good option for models:

• Drop dependency on attrs
• Great editor support:
  
• No need for to_dict or from_dict on models
• Can use python keywords as keys class etc

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context

• https://www.python.org/dev/peps/pep-0526/
• https://www.python.org/dev/peps/pep-0655/

[dbanty]

I converted this into a discussion because there are a few alternatives to attrs that could be considered for the future. The original proposal was to use TypedDict, so responses to that could be in this thread, but I can foresee alternate future threads for @dataclass or pydantic.Model.

[dbanty]

Alright now for my actual response to the TypedDict alternative 😁. To be clear, to_dict and from_dict would still be necessary as concepts, though they may be named differently. More than just convert the class to or from a dict (which could be done with attrs.asdict and MyClass(**stuff) those methods are converting values to/from their JSON representations. They are poorly named right now and will probably be changed whenever we add support for more styles for forms.

We also would not be able to necessarily use arbitrary Python keywords as parameters. Them existing as attributes on a class is not actually the problem right now, it's the fact that we may have to use them as variable names in the functions which transform them to/from their encoded forms (e.g. converting to JSON or multipart/form). So basically, the existinance of to_dict (which would still need to exist) means that we still can't use keywords or names that otherwise shadow other values (e.g., datetime).

So the benefits I see over attrs are:

1. The version of attrs we require will not force consumers to upgrade their version of attrs if they are using it elsewhere in the same project as the generated SDK. This doesn't seem like much of a benefit since attrs promises "strict backwards compatibility".
2. Installing a generated SDK would not require downloading attrs which would save ~60KB. That seems relatively small considering the other dependencies we rely on. httpx and its dependencies require ~580KB and python-dateutil is ~256KB. Also, typing_extensions is ~28KB so it's even less savings on Python 3.7 which will be supported until mid-2023.
3. Not using a third party package may make it easier for folks to understand how the code works? Although the attrs syntax is very similar to dataclasses which it is based on, and dataclasses has been built into Python for longer than TypedDict so I'm not sure we could prove any tangible familiarity improvements.
4. Instances of TypedDict should consume less memory than attrs at runtime, though this has to be benchmarked to prove. Based on some numbers I'm seeing online, we're looking at ~100 nanoseconds at best which is a tiny amount compared to the I/O of using the SDK.

What are the cons to switching?

1. It's a breaking change. Folks using generated models in SDKs today would likely have to adjust their usage to the new class type.
2. TypedDict doesn't have a clear way to set default values. It's not clear from the OpenAPI spec whether a default should actually be set in the client or not, but I think it aids in clarity to the consumer what they'll get if they don't set.
3. TypedDict can't be used with runtime type checking (isinstance) which will make consuming them more difficult. Endpoints can return different types for different status codes, and there's not a super obvious way to indicate which type is returned from a function based on that status. So the consumer would have to do some manual checking.
4. We can't take advantage of validators that attrs provides. We aren't using them yet today, but I intend to at some point to make sure that attributes properly conform to their schemas (e.g., using maxLength on a string).

Overall I don't think the benefits outweigh the downsides to this one, but I really appreciate that you put thought into potential improvements!