Are the type stubs for `decorator` accurate?
If I write:
from decorator import FunctionMaker
fm = FunctionMaker(lambda x: x)
print(f'{fm.defaults=}')
then I see
fm.defaults=None
However, the stubs show:
https://github.com/python/typeshed/blob/ecd5141cc036366cc9e3ca371096d6a14b0ccd13/stubs/decorator/decorator.pyi#L23
and None can't be assigned to tuple[Any, ...]
@donBarbos sorry for the ping, I just saw that you worked on these stubs a few months ago. Can you tell if it's accurate that defaults should be tuple[Any, ...] | None?
The inspect docs also note:
defaults is an n-tuple of default argument values corresponding to the last n positional parameters, or None if there are no such defaults defined
sorry, my bad. judging by source code I decided that the fields are set only if they are not None: https://github.com/micheles/decorator/blob/143887ed562e83007271df94527eb8f4c269ed4c/src/decorator.py#L100-L111
if name:
self.name = name
if signature is not None:
self.signature = signature
if defaults:
self.defaults = defaults
if doc:
self.doc = doc
if module:
self.module = module
if funcdict:
self.dict = funcdict
so maybe for other arguments (which become fields) this also applies. would you like to send PR? (or I can also send PR)
thanks!
i find the logic a bit surprising - these fields are initialised to an empty tuple, which then may get overwritten. so technically they can also be tuples
In [1]: from decorator import FunctionMaker
In [2]: type(FunctionMaker.args)
Out[2]: tuple
do you think a fix should be to
- change the defaults in
decoratoritself, something likeargs = [] vargs = None varkw = None defaults = None kwonlyargs = [] kwonlydefaults = {} - modify the stubs to also include
tuple[Any, ...]in the type stubs for each of these variables, as possibly some missingNone? e.g.- args: list[str] + args: list[str] | tuple[str, ...] - modify the stubs to use less strict annotations, like
args: Sequence[str]?
I would prefer to list all the possible types for each of the fields, firstly because there are not so many of them, and secondly, each of them has its own possible types.
but before, yea, it's better to get rid of the default tuple in source code
Sure, thanks - I've started by opening a PR to them here: https://github.com/micheles/decorator/pull/174