On 28 April 2017 at 22:26, Paul Moore <p.f.mo...@gmail.com> wrote: > On 28 April 2017 at 12:55, Tin Tvrtković <tinches...@gmail.com> wrote: >> I'm putting forward three examples. These examples are based on attrs since >> that's what I consider to be the best way of having declarative classes in >> Python today. > > Your comments and examples are interesting, but don't they just come > down to "attrs is a really good library"? I certainly intend to look > at it based on what's been said in this thread. But I don't see > anything much that suggests that anything *beyond* attrs is needed > (except maybe bringing attrs into the stdlib, if its release cycle > would make that reasonable and the author was interested, and honestly > "put it in the stdlib" could be said about any good library - in > practice though publishing on PyPI and accessing via pip is 99% of the > time the more reasonable option). > > Am I missing some point?
Yes, the point I attempted to raise earlier: at the language design level, "How do we make __init__ methods easier to write?" is the *wrong question* to be asking. It's treating the symptom (writing an imperative initialiser is repetitive when it comes to field names) rather than the root cause (writing imperative initialisers is still part of the baseline recommendation for writing classes, and we don't offer any supporting infrastructure for avoiding that directly in the standard library) Accordingly, a potentially better question to ask is "How do we make it so that writing a custom __init__ method for each class definition seems as strange and esoteric in 2025 as writing a custom metaclass seems now?". For a *lot* of classes, what we want to be able to define is: - a set of data fields - a basic initialiser to set those fields by name - a repr based on those fields (or a subset) - equality comparisons based on those fields (or a subset) - ordering comparisons based on those fields (or a subset) - conversion to a JSON-friendly dict - pickling support - copying support Given the initial set of data fields, reasonable default behaviours for all of the rest can be derived automatically, but we don't provide the tools to do that derivation by default. This leaves teachers of Python in a quandary: they can either teach "native Python classes" (which are boilerplate heavy and error prone), or else they can pick a third party library like attrs, and teach "Python-with-attrs", in the same way that it's recommended to teach "Python-with-requests" rather than the native urllib APIs when it comes to accessing resources over HTTPS. The difference between this case and requests is that HTTPS and related protocols experience a high level of churn independently of Python language updates, so there are real logistical benefits to maintaining it as a third party module. By contrast, if we add an "autoclass" module to the standard library that adds more tools like functools.total_ordering to handle injecting boilerplate functionality into class definitions at runtime, then that's a pure win - folks can either delegate the details of their instance behaviour to the standard library maintainers (in the same way that most folks already delegate the behaviour of their metaclasses), or else they can continue to write out all those supported methods by hand if they really want or need the fine-grained control. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
