Add attr.define/mutable/frozen

[hynek]

Prepare for import attrs y'all!

This is basically what we kinda agreed on in #408 and #487.

I'm open to comments and suggestions.

Also suggestions how to supply type stubs without a major copy/paste operation. 😳

[lig]

My wishes:

• kw_only by default
• auto_attribs by default
• attrs.Field() for attributes
• attrs.Class() for class decorators
• allow to inherit something like attrs.BaseClass to be able to use isinstance(obj, attrs.BaseClass) later (basically allow to detect that we have attrs class)
• recursive attrs.from_dict()
• transparent builder API to simplify third party tools integration like converters between ORM models and attrs, serializer, etc
• regarding defaults, maybe allow building your own factory which provides required defaults to reuse it later.

[hynek]

To be clear, I'm only looking for stuff that we might paint ourselves into the corner. Most of what you listed can be fixed at any time.

• kw_only=True is not happening, because I had it in characteristic and people (including myself) hated it.
• ✔︎
• not sure what you mean? Just a different name? I'm indeed thinking to go for attrs.field or attrs.Field in the next APIs.
• you mean @attrs.Class\nclass Foo? After long deliberation on Find better name for attr.dataclass #408 it's gonna be attrs.define. Class class is repetitive.
• uh, attr.has?
• that's too complex, so we've delegated that to other packages like cattrs and try to help them get better at it in Improve (de)serialization and validation capabilities #653
• that's interesting but out of scope for this issue
• you can do that with functools.partial. You just have to trick mypy into recognizing it but we've just merged some docs on that in Document how to write aliases that are recognized by mypy #650

[lig]

• kw_only=True is not happening, because I had it in characteristic and people (including myself) hated it.

:( it is how it is then. anyway, everybody needs different defaults

• not sure what you mean? Just a different name? I'm indeed thinking to go for attrs.field or attrs.Field in the next APIs.

well, kinda. if it will be import attrs then attrs.ib doesn't work anymore. So, if import attr works as before then new API with import attrs needs something new and explicit.

• you mean @attrs.Class\nclass Foo? After long deliberation on Find better name for attr.dataclass #408 it's gonna be attrs.define. Class class is repetitive.

Doesn't matter much, define works as well. attrs.s looks kinda "meh"

• uh, attr.has?

Nice. Never noticed it. Maybe, missed in the docs and then didn't recognize it with autocomplete. The name feels a bot misleading to guess what it does straight away. Thanks for educating me on this:)

• that's too complex, so we've delegated that to other packages like cattrs and try to help them get better at it in Improve (de)serialization and validation capabilities #653

Well, maybe the next point will help with it. However, it feels like it's not that complex and it would fully complement asdict. It's your call, no pressure here. cattrs worked for me.

• that's interesting but out of scope for this issue

Fair enough. Shall I describe the idea in a separate issue?

• you can do that with functools.partial. You just have to trick mypy into recognizing it but we've just merged some docs on that in Document how to write aliases that are recognized by mypy #650

Making this work with fewer tricks would help. Docs are good, though:)

Thanks and keep up the good work!

[hynek]

• not sure what you mean? Just a different name? I'm indeed thinking to go for attrs.field or attrs.Field in the next APIs.

well, kinda. if it will be import attrs then attrs.ib doesn't work anymore. So, if import attr works as before then new API with import attrs needs something new and explicit.

Yeah, it's prob gonna be attrs.field.

• that's interesting but out of scope for this issue

Fair enough. Shall I describe the idea in a separate issue?

Sure!

Thanks and keep up the good work!

💛

[euresti]

This is neat. I will have to spend some time fixing the mypy plugin to get these to work.

[hynek]

This is neat.

Not sure if sarcasm. ;)

I will have to spend some time fixing the mypy plugin to get these to work.

Do the annotations look OK so far? I don't think I can do anymore than release and wait for mypy, correct?

[euresti]

Not sarcasm, I'm excited to not have to confuse people in my team with @dataclass (no, not that kind of dataclass)

[hynek]

I guess there's no point in procrastinating on this any further…merging and if nobody yells at me, I'll release 20.1 tomorrow.