[Python-ideas] Augmented assignment syntax for objects.

Nick Coghlan ncoghlan at gmail.com
Fri Apr 28 09:07:51 EDT 2017


On 28 April 2017 at 22:26, Paul Moore <p.f.moore at gmail.com> wrote:
> On 28 April 2017 at 12:55, Tin Tvrtković <tinchester at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list