
On Mon, 2 May 2022 at 18:46, Steven D'Aprano <steve@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").