On Mon, 2 May 2022 at 18:46, Steven D'Aprano <st...@pearwood.info> wrote:
>
> But **not once** when I have read that same method later on have I
> regretted that those assignments are explicitly written out, or wished
> that they were implicit and invisible.
I have classes with 20+ parameters (packaging metadata). You can argue
that a dataclass would be better, or some other form of refactoring,
and you may actually be right. But it is a legitimate design for that
use case. In that sort of case, 20+ lines of assignments in the
constructor *are* actually rather unreadable, not just a pain to
write. Of course the real problem is that you often don't want to
*quite* assign the argument unchanged - `self.provides_extras =
set(provides_extras or [])` or `self.requires_python = requires_python
or specifiers.SpecifierSet()` are variations that break the whole
"just assign the argument unchanged" pattern.
As a variation on the issue, which the @ syntax *wouldn't* solve, in
classmethods for classes like this, I often find myself constructing
dictionaries of arguments, copying multiple values from one dict to
another, sometimes with the same sort of subtle variation as above:
@classmethod
def from_other_args(cls, a, b, c, d):
kw = {}
kw["a"] = a
kw["b"] = b
kw["c"] = c
kw["d"] = d
return cls(**kw)
Again, in "real code", not all of these would be copied, or some would
have defaults, etc. The pattern's the same, though - enough args
arecopied to make the idea of marking them with an @ seem attractive.
Overall, as described I don't think the @arg proposal provides enough
benefit to justify new syntax (and I think trying to extend it would
end badly...). On the other hand, if someone were to come up with a
useful, general way of bulk-copying named values from one "place"[1]
to another, possibly with minor modifications, I think I'd find that
very useful. Call it a DSL for bulk data initialisation, if you like.
I think such a thing could pretty easily be designed as a library. But
I doubt anyone will bother, as adhoc "on the fly" solutions tend to be
sufficient in practice.
Paul
[1] A "place" might be a dictionary - dict["name"] or an object -
getattr(self, "name").
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/Y7KWHYQE7Q7GWEM73RKCT3ITC74LNGPI/
Code of Conduct: http://python.org/psf/codeofconduct/
