> On Apr 15, 2020, at 10:48, Ricky Teachey <ri...@teachey.org> wrote: > >>> It becomes more painful the more parameters the parent has- parameters >>> which the dataclass may not even care about. It not only makes the class >>> definition long, it adds so these additional parameters to the init >>> signature, which is icky for introspection and discoverability. Lots of >>> "What the heck is this parameter doing here?" head scratching for future me >>> (because I forget everything). >> >> I think that’s backward. The signature is there for the user of the >> dataclass, not the implementer. And the user had better care about that x >> argument, because it’s a mandatory parameter of the X class, so if they >> don’t pass one, they’re going to get an exception from inside some class >> they never heard of. So having x show up in the signature would be helpful >> for introspection and discovery, not harmful. It makes your users ask “What >> the heck is the x parameter doing here?” but that’s a question that they’d >> better have an answer to or they can’t construct a Y instance. (And notice >> that the X doesn’t take or pass along *args, so if the Y claims to take >> *args as well as **kwargs, that’s even more misleading, because passing any >> extra positional args to the constructor will also raise.) And that’s as >> true for tools as for human readers—an IDE auto-completing the parameters of >> Y(…) should be prompting you for an x; a static analyzer should be catching >> that you forgot to pass as x; etc. > > This is a good critique of what I said! Just want to clarify, though, that I > was thinking the entire time of OPTIONAL arguments-- like, for example, of > the kind heavily used in pandas. There tons of optional arguments in that > library I do not care about, ever. But you are correct about non-optional > arguments.
Well, the OP’s example doesn’t have an optional argument, only a non-optional one. But for optional parameters that you really do not care about, ever, you’re never going to pass them to Y, so why do you care that Y won’t pass them along to X? And for optional parameters that are meaningful and useful to Y’s users, surely having them visible in the help, etc. would make things more discoverable, not less? I think ultimately the argument you want to make really is the “enlightened laziness” one: there are lots of optional Pandas-y parameters in your superclass(es), and most of them you will definitely never care about, but a few of them you actually might occasionally care about. What then? Well, if your Y class is part of mission-critical interface code that lives depend on, you probably do need to work out which those are and get them nicely documented and statically checkable, but in a lot of cases it isn’t nearly worth that much effort—just make Y pass everything through, and the couple places you end up needing to pass down one of those Pandas-y arguments you just do so, and it works, and that’s fine.
_______________________________________________ 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/RPCINUUZB375RC5VIGDZ3LTKWTEVOW4D/ Code of Conduct: http://python.org/psf/codeofconduct/
