Current status for decorators which use **kwargs?

[acdha]

I believe this is related to #1079 but my use-case is slightly different. I have a decorator which adds support for arbitrary kwargs to an existing method — e.g. custom_logger.info(…, something_else) is the same as logger.info(…, extra={"something_else": …}), with all of the pre-existing keyword arguments' type information left unmodified.

I know that Concatenate doesn't support the concept of adding kwargs. Is there a clean way to express which doesn't require copying the definitions? I'm currently inclined to treat this as an argument that this API design is too clever but was wondering whether I'm missing something given how fast this space has moved.

[Akuli]

Not much has changed recently. You can override a method and keep the type unchanged (my @copy_type decorator). You can add positional arguments with Concatenate, although I don't think it's fully implemented in mypy. But as you say, there isn't anything for adding keyword arguments.

A couple alternatives:

• If you have a lot of code calling your custom logger methods, you can copy/paste the definitions of debug(), info() etc into your custom logger class, maybe with if TYPE_CHECKING.

• Just take **kwargs: Any in your custom methods, e.g.

  def info(self, *args: object, something_else: WhatEver = some_default_value, **kwargs: Any) -> None:
      super().info(*args, **kwargs, extra={"something_else": something_else})

  Not great for autocompletions and type checkers, but it's easy to understand and not much boilerplate.

• Just pass extra={"something_else": foo} everywhere and not bother with overriding for "convenience"?

[acdha]

Thanks! In this case we decided that the convenience wasn't significant enough to be worth the complications here. I'm thinking that might be a general principal to encourage minimizing the number of cases where something adds a keyword argument to an existing signature.