Hi Michel, > Now OPP is already hard to teach to my students, but if I have to add > this to the mix, I will just have to tell them to copy / paste it > blindly for a long time before I can get to the point they can > understand what it does.
About the teachability, some remarks: 1. You can still just skip it. I presume you don't teach all the advanced metaclass stuff right away either, even though it is part of core Python. 2. Is it really that complicated? attr.s is just a normal Python function, which adds some members to a class. You don't even have to use the decorator @ syntax, that is just a convenience. To me this seems easier to teach than yet another dedicated syntax. Stephan 2017-05-17 10:15 GMT+02:00 Michel Desmoulin <desmoulinmic...@gmail.com>: > > > Le 17/05/2017 à 07:22, Guido van Rossum a écrit : >> On Tue, May 16, 2017 at 8:14 PM, Juancarlo Añez <apal...@gmail.com >> <mailto:apal...@gmail.com>> wrote: >> >> What I like about attrs is: >> >> * The class level declaration of instance attributes >> * That the reasonable *init*, *repr*, and *eq* are generated >> >> OK, the former should be doable using PEP 526 (the type is stored in >> __annotations__ and the default in the class dict given to the >> metaclass), while the latter should be doable using a standard metaclass >> -- assuming we can agree on what the "reasonable" __init__, __repr__ and >> __eq__ should do. >> >> >> I don’t like the excessive wordiness in attrs, >> >> Really? @attr.s is wordy? :-) I think it's deadly cute. (The only >> library I've ever seen that did something worse was "monocle" which used >> @_o.) > >>>> import attr >>>> @attr.s > ... class Point: > ... x = attr.ib(default=42) > ... y = attr.ib(default=attr.Factory(list)) > > > Is pretty wordy compared to something like another language would do > such as: > > class Point: > int x = 42 > list y = [] > > Now I get that: > > - Python already has a similar syntax creating class attributes. > - You can't put mutable objects here. > - attr does more since it generates dunder methods. > > But having an import, a decorator and verbose calls to attr.ib does not > feel like idiomatic Python at all. Python is an elegant and expressive > language. This is none of the above. Also Python is beginner friendly. > Now OPP is already hard to teach to my students, but if I have to add > this to the mix, I will just have to tell them to copy / paste it > blindly for a long time before I can get to the point they can > understand what it does. > > We should be able to find a middle ground. > > First, if we have something LIKE attr, should it need an import? Basic > data structures may not require an import to work. async/await are way > better than import @asyncio.coroutine. > > Secondly, while I really, really, really want this feature, I think we > should not rush it. > > Some ideas have to be explored. > > E.G: > > Adding keywords for it ? I know adding a keyword is the worst thing one > can suggest on this list ever. But it has to be mentioned because most > other languages do it this way. > > class Point: > instancevar x = 42 > instancevar y = lazy [] # we add a debate about this a few months ago > > > Adding a special syntax for it ? ruby has something similar. > > class Point: > @x = 42 > @@y = list > > Upgrading the class constructor? It does not address the mutablility > issue though. > > class Point(x=42, y=[]) > > Mixing concepts? > > > class Point(metaclass=autoclass(x=42, y=lazy [])): > pass > > @args(x=42) > @factory_args(y=list) > @autodunder() > class Point: > pass > > @autoclass( > x=42 > y=autoclass.lazy(list) > ) > class Point: > pass > > > Just adding attrs, which is a workaround to a missing feature in Python, > as a boiler plate and calling it a day seems unwise. > > Don't get me wrong, I like attrs, I like asyncio and I like the whole > battery included concept. But we lived without it until now, so let's > not go too fast on this. > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
