Using attrs for everything in Python

Agreed.

From the post, it seems to me like another (IMO better) alternative to this awkward attr-specific convention and syntax etc would be to create a factory function for dynamic class definition, in a similar vein to namedtuples.

This is functionally similar to the metaclass route, and to be honest I'm not sure what the tradeoffs would be. Either way, I think metaprogramming is a much better approach than attrs if the problem you're trying to solve is "generic container classes take too long to get set up".

I think, were I to write something like this, I would probably do it using a metaclass, and then inject an __init__ on the MRO between the programmer-defined __init__ and the actual super().__init__. That way, you could call super().__init__(arg1, arg2, arg3) for the automatic attribute setting. You could also hook this in to some metaclass-defined storage containers to automate the __repr__ implementation, etc.

Your view of what decorators doesn't seem to reflect the usage I've experienced writing Python professionally over the last 10 years.

Decorators take an object and return a object (by convention a callable, although this isn't enforced in the slightest). Maybe they modify a function or method signature, maybe it produces an unrelated object, or maybe one augments the object by adding side effects like caching or logging.

There is a special syntax (@) legal for classes, functions, and methods that provides a shortcut for the common pattern of:

    def decorator(): ...
    def foo(): ...
    foo = decorator(foo)

such that we can say:

    @decorator
    def foo(): ...

Things I've seen decorators do:

    * add logging
    * add tracing
    * enable type validation
    * register functions/objects for various reasons
    * produce full objects out of functions
    * swap out implementations for global functions/vars
    * change output formats to json/xml/yaml
    * take a class, inspect a database schema and bind various internal attributes to update items in a row for that schema (somewhat common in ORMs)

I don't see this attrs library as any more egregious than other uses. In particular, I don't see why mutating a type via a metaclass is preferable to using a decorator. I can offer that decorators generating objects compose much better than metaclasses do (at least they have in python 2.x, I haven't had a chance to use 3 professionally).

You're probably thinking of jsobject¹:

    from jsobject import Object
    foo = Object()
    foo.x = 1
    foo.a = {}  # foo.a.b will fail without this line
    foo.a.b = 2
    print(foo)  # prints: {'a': {'b': 2}, 'x': 1}

¹ https://pypi.python.org/pypi/jsobject/

Please don't tell the C++ community that! We really don't want to encourage them.

To someone who uses Python every day, the extra cognitive load of `attr` is more than made up for by all the boilerplate it eliminates. But for beginners, behind-the-scenes magic is a real turn off.

I think that making `attr` an optional library is a fair compromise, but perhaps it would be a good idea to add a note to the library reminding the programmer not to use it if the code is likely end up in the hands of novices.