dataclasses

See my comment and the linked email at https://github.com/ericvsmith/dataclasses?tab=readme-ov-file... for dataclasses and 3.6. I think it's still true.

dataclasses was explicitly inspired by attrs. https://github.com/ericvsmith/dataclasses/issues/1

I have a decorator to add support for slots: https://github.com/ericvsmith/dataclasses/blob/master/datacl... (although I'll admit I haven't tested it in a while). The reason it's not an option by default is because it would be the one case where the decorator would have to return a new class, and I didn't want to do that on the first version. As it is, @dataclass just modifies an existing class. I might bite the bullet add a slots option, and we've had discussions on adding a language feature to automatically add slots to a class, based on annotations and maybe some other magic. If we did that, we wouldn't need to return a new class. But it's not a front-burner task for me.

> Especially with `slots=True`, dataclasses can take less resources. `slots=True` doesn't exist, though there's an experimental implementation at https://github.com/ericvsmith/dataclasses/blob/master/datacl... . The main issue is that slots have to exist at class definition, and @dataclass takes an already defined class, so you'd have to create a clone of the class, which is nasty. On top of that you can't always add __slots__ manually, because it conflicts with default field values (and field()s). __slots__ wants to add a descriptor as a class attribute but it can't do that if the default value is already an attribute.

In case anyone is stuck on older versions of Python for any reason, here are some backports of some of the listed features: * f-strings: https://github.com/asottile/future-fstrings (this is a pretty crazy hack, all the way to Python 2) * pathlib: https://pypi.org/project/pathlib2/ * typing: https://pypi.org/project/typing/ * enum: https://pypi.org/project/enum34/ (doesn't include any additions in 3.5+) * functools.lru_cache: https://github.com/jaraco/backports.functools_lru_cache * dataclasses: https://github.com/ericvsmith/dataclasses (3.6 only, requires ordered class __annotations__) I'm half-expecting someone to come along with a hacked-up Python 2 backport for implicit namespace packages :)

I'm a big fan of @mhashemi's work in Python in general, even if I don't use Boltons personally. The discussion regarding inclusion in the stdlib is sensible, and I fully agree with @mhashemi's comments. See similar discussions, for instance, regarding dataclasses vs. attrs (https://github.com/ericvsmith/dataclasses/issues/19). Sometimes, however, it's a bit annoying when something that you think should be widely available isn't included in the stdlib. The cons of course are: - Fragmentation (several project pursuing similar objectives) - Not being able to use a powerful construct to simplify code in the stdlib itself (the stdlib can only depend on the stdlib). Regarding, for instance, functional programming, I maintain a list of interesting projects in this domain in Python: https://github.com/sfermigier/awesome-functional-python/blob...

The article doesn't discuss slots and default values. Here's the actual reference implementation for dataclasses where it's discussed: https://github.com/ericvsmith/dataclasses/issues/28 Your second solution works fine (and is what I'd referenced). For your first solution, I'd again redirect you to my statement "they don’t support __slots__ and default values" and the above link.

I love using attrs, like the idea of bringing something similar to the standard library, but strongly disagree with the dataclasses API. It treats untyped Python as a second class citizen. This is what I'd prefer from dataclasses import dataclass, field @dataclass class MyClass: x = field() but it produces an error because fields need to be declared with a type annotation. This is the GvR recommended way to get around it: @dataclass class MyClass: x: object You could use the typing.Any type instead of object, but then you need to import a whole typing library to use untyped dataclasses. I highly prefer the former code block. There's a big thread discussing the issue on python-dev somewhere. Also some discussion in https://github.com/ericvsmith/dataclasses/issues/2#issuecomm... Anyway, it's not a huge issue—attrs is gr

While 3.7 is not here, back-port: https://github.com/ericvsmith/dataclasses

Close! ericvsmith, gvr, et al were inspired by attrs and have since been implementing a stdlib version of it, calling it "dataclass" see: https://github.com/ericvsmith/dataclasses and this comment thread is revealing: https://github.com/ericvsmith/dataclasses/issues/19

The problem with python class definition is the need to write instance vars 3x: def __init__(self, foo) self.foo = foo There is an attrs package and new proposal (https://github.com/ericvsmith/dataclasses/blob/master/pep-xx...) to remedy that.