Find better name for attr.dataclass

[hynek]

So attr.dataclass was meant more or less as a joke, but I just caught myself using it too but the name is bad, because it’s confusing. It implies some kind of symmetry or compatibility to DCs which it doesn’t.

So here’s a nice bike shed, please help me finding a short, memorable, and meaningful color for it!

[euresti]

attr.auto?

[hynek]

attr.auto?

That’s kinda my favorite too. It’s just sad that it doesn’t work with the attr prefix but that ship has somewhat sailed. I think I’ll have to re-visit the introduction of an attrs namespace.

[hynek]

Which opens the question: if the namespace becomes attrs and you can do from attrs import X, what would be the best name for it? auto seems too short…OTOH @attrs.auto looks perfect. I wonder if in a perfect world, we could come up with something nice and symmetric to it – like @attrs.explicit?

The world around attrs has changed considerably since the invention of it's original names. It outgrew it’s scope more than I could ever predict when I was scheming with @glyph on IRC and the introduction of static types opened it up to new interesting use cases.

While I realize that introducing new APIs brings some confusion, there’s always the cautionary tale of why Makefiles use tab characters.

---

After using it a bit, I believe that if Python has a future, static typing is unequivocally part of it and I want attrs to embrace it fully and not to feel like we’re dragging our heels. Obviously I do not intend to break backward compatibility but unless someone can talk me out of it, I’m very close to add a new, more forward-looking API and make it the primary one.

I for one, am very annoyed whenever I use the attr package name with names that don’t make any sense (like attr.validators) and the last time I got annoyed on each import, I abandoned the project in favor of attrs. ;)

[hynek]

So I’ve been playing and I’m absolutely in love with this being the future canonical API for attrs:

>>> import attrs
>>> import typing

>>> @attrs.auto
... class SomeClass:
...     a_number: int = 42
...     list_of_numbers: typing.List[int] = attrs.Factory(list)
...     a_number = attrs.attrib(converter=int)

>>> attrs.fields(SomeClass).a_number.type
<class 'int'>

---

Which kind of means that the question is reversed – should there be another name for attr.s? We will have a conflict with the serious business crowd anyways since they tend to write from attr import attrs, attrib.

That’s the only thing that annoys me but I don’t think we can fix it: it’s impossible to both from attrs import attrs and import attrs. However it’s not solvable and naming the main function after the project name is not that special…so…attrs.attrs/attr.s it is I guess? (or import everything).

Which gives us:

>>> from attrs import attrs, attrib, Factory

>>> @attrs
... class SomeClass(object):
...     a_number = attrib(default=42)
...     list_of_numbers = attrib(default=Factory(list))

>>> sc = SomeClass(1, [1, 2, 3])

>>> attrs.asdict(sc)
{'a_number': 1, 'list_of_numbers': [1, 2, 3]}

>>> C = attrs.make_class("C", ["a", "b"])
>>> C("foo", "bar")
C(a='foo', b='bar')

Which I think I can live with? At least I don’t have a better idea.

---

One thing that’s notable tho and that makes me feel quite good about attr.s/attr.ib is how much easier they’re to distinguish. So there’s definitely gonna be a from attrs import attr and I’m gonna use it.

[glyph]

I think it would be helpful to begin by enumerating the problems that this renaming is attempting to solve.

• PyPI name ≠ import name
  This is certainly a pet peeve of many people and perhaps rightly so.

• We a more "forward-looking" API.
  My interpretation of this vague sentiment is that in the past, @attr.s was the only way to do things, and as a result @attr.s is now the default way to do things, whereas the lengthier attr.dataclass and attr.s(auto_attribs=True) feel like tack-ons. So, to be specific: being "forward-looking" means organizing the library around type annotations rather than attrib objects.

• Maybe it's time for srs bsns.
  The popularity of the project has perhaps expanded to a scale where attr.ib and attr.s look too cutesy. I don't really buy this, but, ok, fine.

• The attr name is insufficiently mellifluous.
  I am not quite sure I understand why from attrs import validators is so much better than from attr import validators. Can you say more about why you feel this is the case?

• If we're going to do this, we should do it all at once so we have only one transition to manage rather than N.
  While normally conflating issues is a bad thing, I do agree that this sort of reorganization should be done either zero or one times, not 2+ :).

Am I missing anything?

[glyph]

My own feeling on attr.auto is that it may be a manifestation of a local maximum, and if @hynek is talking about a Grand Reorganizing here then it might not be a good name.

attr.auto is better than attr.dataclass because it articulates the salient difference between it and attr.s more succinctly: auto_attribs is a big distinction and worthy of being reflected in the name.

But, it's worse as the new default thing that attrs does. My feeling is that if we want the API to be centered around type annotations, then attrs.attrs should simply have auto_attribs default to True, and that's one of the differences between the old and the new API.

[glyph]

Alternately, thinking from the perspective of someone approaching attrs for the first time, why does one use this decorator? Because one is defining a type. So perhaps something like this would make more sense:

• @attrs.type
• @attrs.cls
• @attrs.Class

Or, resurrecting one of my own personal bugaboos from long ago:

• @attrs.mutable
• @attrs.immutable
• @attrs.value
• @attrs.const

Or, for ultimate style points:

• @attrib.utes
• @attrib.uted

[glyph]

OK, last thought for the moment: please don't land this without having a typeshed / mypy update ready and waiting :)

[wsanchez]

Which kind of means that the question is reversed – should there be another name for attr.s? We will have a conflict with the serious business crowd anyways since they tend to write from attr import attrs, attrib.

I'm in the serious business camp (can't help myself, sorry) and I don't have a problem with the above. If I port a file, I'll have clean that up. This doesn't sound like a big deal to me.

[wsanchez]

Mmmm… @attrs.mutable and… I'd say @attrs.frozen, just based on following typing's lead, eg: typing.MutableSet and typing.FrozenSet.

[hynek]

@attrs.mutable & @attrs.frozen are definitely hot contenders right now.

[euresti]

Another suggestion if we're pushing type annotations. typed=True as the default? or type_annotated=True

[hynek]

typed=True as the default?

What would that mean?

[euresti]

Oh I'm sorry. I meant the typed=True -> foo: int, vs typed=False -> foo = attrs.attrib()

Unless you're really partial to auto_attrib