How to avoid repeating a long list of keyword options throughout a package?

[jagerber48]

@CAM-Gerlach

—what’s done in _replace() shouldn’t affect static introspection for user-facing functions, assuming it’s actually using the static type hints to retrieve the parameter types rather than trying to infer things from the code flow, and it should work with type checkers (though in practice it might not be properly implemented with all of them).

Right, I think autocompletion for user facing functions is fine. It’s just autocompletion with in _replace because of the type(base)(...) construction

@CAM-Gerlach

Ah, so it seems the issue is specifically in the type(base)(...) call? That’s a pretty advanced case, but do be advised that the issue is not just dataclass support there; in the actual function Pycharm cannot statically know whether base will be a FormatOptions or a RenderedFormatOptions, which at least as far as the type system is concerned are two disjoint types, and it cannot know which’s parameters to show, dataclass or not.

Yeah right… the dataclass issue exists but is sort of independent. So yeah, even if the dataclass issue was solved it would not be possible for autocomplete to work.

@CAM-Gerlach

You could try making FormatOptions a subtype of RenderedFormatOptions, which would be valid from a Liskov perspective (even if it seems like the opposite conceptually), but that might be tricky and I don’t know ifit would help Pycharm in this case, though it might also provide an additional validation of type correctness—you’d have to experiment since it will depend on the tooling.

Yeah this is an interesting idea. I did some quick tests and I think on pycharm this will reduce the issue to the dataclass problem above. And I’ll have to figure out how to do dataclass inheritance right, something I’ve struggled with a lot in the past. I can look into this more.

@CAM-Gerlach

As a hacky workaround, you could write FormatOptions( and fill in the params, and then change it to type(base)( after you’re done.

meh

So yeah, with all of this I’m leaning towards the asdict approach which leverages the knowledge that FormatOptions and RenderedFormatOptions have the same signature. It seems to me that any strategy to optionally construct either a FormatOptions or RenderedFormatOptions that doesn’t include FormatOptions(exp=..., exp_mode=...) and RenderedFormatOptions(exp=..., exp_mode=...) is going to have to somehow implicitly take advantage of this fact. The asdict strategy shamelessly leverages this, and I can just explain that in the docstring. Even if one is a subclass of another, I don’t think LSP enforces constructor signature are exactly the same (or even compatible based on some things I’ve read which says LSP only applies to instantiated objects) and I don’t think it would help me catch signature mismatches between the two classes anyways. Those would always need to come up at run time.

So going in circles a little bit here: one way would be to have RenderedFormatOptions and FormatOptions be the same class. But the problem here is that the “rendered” form should have values for all options, and it should type check as such. But to support the unrendered form the options would all have to be annotated as optional so that None (or some other sentinel) value is accepted.

It feels kind of like a puzzle that should have a solution… but I think the constraint of “I don’t want to explicitly type out the options because there are just so many of them” is kind of outside the scope of static type checking or something… so it can only be accomodated so well while also satisfying static type checking constraints. E.g. your approach with the shared _replace implementation currently adds one occurrence of the options list. But if we were ok with two more occurrences then there are a number of ways that could be worked out pretty easily I think while satisfying explicitness/type checking etc.

Thanks for the info on linters and autoformatters. I’ll have to look into these options.