Skip to content

Are the type stubs for decorator accurate? #14286

Open
@MarcoGorelli

Description

@MarcoGorelli
Contributor

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:

defaults: tuple[Any, ...]

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

Activity

donBarbos

donBarbos commented on Jun 16, 2025

@donBarbos
Contributor

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)

MarcoGorelli

MarcoGorelli commented on Jun 16, 2025

@MarcoGorelli
ContributorAuthor

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 decorator itself, something like
    args = []
    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 missing None? e.g.
    - args: list[str]
    + args: list[str] | tuple[str, ...]
  • modify the stubs to use less strict annotations, like args: Sequence[str]
    ?
donBarbos

donBarbos commented on Jun 16, 2025

@donBarbos
Contributor

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

MarcoGorelli

MarcoGorelli commented on Jun 17, 2025

@MarcoGorelli
ContributorAuthor

Sure, thanks - I've started by opening a PR to them here: micheles/decorator#174

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @MarcoGorelli@donBarbos

        Issue actions

          Are the type stubs for `decorator` accurate? · Issue #14286 · python/typeshed