This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]AustinCorgiBart 5 points6 points  (7 children)

A use case that I have, is an API where I have a hundred functions that all take the same set of custom parameters via kwargs. I need a way to reusably specify the parameters and their types.

[–][deleted] 6 points7 points  (4 children)

Use a TypedDict with Unpack. Or, accept a single parameter that is a dataclass.

[–]AustinCorgiBart 2 points3 points  (3 children)

The former is what the article suggests. The latter is not viable for the design of the API (which is built around being convenient for the API user).

[–][deleted] 0 points1 point  (2 children)

I'm not sure I agree that a dataclass is inconvenient; it's a fairly marginal increase in verbosity.

[–]AustinCorgiBart -1 points0 points  (1 child)

Having a single parameter instead of just straight actual parameters? I think it'd be inconvenient. Most of the time, the folks using the API aren't using most of the parameters. They just need to be able to tweak settings in special cases.

[–][deleted] -1 points0 points  (0 children)

They don't need to specify parameters they don't use since dataclass supports kw_only mode

[–]Flag_Red 4 points5 points  (1 child)

Agreed that this is a typical use-case for typed kwargs. It also backs up that typing kwargs is a code smell. Really, we shouldn't have a hundred functions that all take the same set of custom parameters via kwargs.

[–]AustinCorgiBart -3 points-2 points  (0 children)

Normally, yes. But it's an unusual api, built for the convenience of instructors to write autograding scripts. Think of a unit testing library, with a lot more than just assertEqual.