Rebecca Turner 72f4057d81 Signal handler callables take int, not Signals (#5622)
The documentation for [`signal.signal`][1] points out that the current
annotation for signal handlers might be wrong (emphasis my own):

> The handler is called with two arguments: the signal **number** and the
> current stack frame (**`None` or** a frame object; for a description of frame
> objects, see the description in the type hierarchy or see the attribute
> descriptions in the `inspect` module).

And when we use them, we can see that the signal number is passed as an `int`,
not a `signal.Signals` member:

import signal

    def handler(signal_number, frame):
        print("In signal handler!")
        print("Signal number:", signal_number, type(signal_number))
        print("Stack frame:  ", frame, type(frame))

    # Set signal handler:
    signal.signal(signal.SIGHUP, handler)

    # Use it:
    signal.raise_signal(signal.SIGHUP)

Which prints:

    In signal handler!
    Signal number: 1 <class 'int'>
    Stack frame:   <frame at 0x7f804402abe0, file '<stdin>', line 12, code <module>> <class 'frame'>

[1]: https://docs.python.org/3/library/signal.html#signal.signal
2021-06-11 20:28:20 +03:00
2015-10-01 08:43:06 -07:00
2021-05-12 17:16:09 -07:00
2021-05-19 22:15:21 +03:00

typeshed

Build status Chat at https://gitter.im/python/typing Pull Requests Welcome

About

Typeshed contains external type annotations for the Python standard library and Python builtins, as well as third party packages as contributed by people external to those projects.

This data can e.g. be used for static analysis, type checking or type inference.

For information on how to use typeshed, read below. Information for contributors can be found in CONTRIBUTING.md. Please read it before submitting pull requests; do not report issues with annotations to the project the stubs are for, but instead report them here to typeshed.

Typeshed supports Python versions 2.7 and 3.6 and up.

Using

If you're just using mypy (or pytype or PyCharm), as opposed to developing it, you don't need to interact with the typeshed repo at all: a copy of standard library part of typeshed is bundled with mypy. And type stubs for third party packages and modules you are using can be installed from PyPI. For example, if you are using six and requests, you can install the type stubs using

$ pip install types-six types-requests

These PyPI packages follow PEP 561 and are automatically generated by typeshed internal machinery. Also starting from version 0.900 mypy will provide an option to automatically install missing type stub packages (if found on PyPI).

PyCharm, pytype etc. work in a similar way, for more details see documentation for the type-checking tool you are using.

The _typeshed package

typeshed includes a package _typeshed as part of the standard library. This package and its submodules contains utility types, but is not available at runtime. For more information about how to use this package, see the stdlib/_typeshed directory.

Discussion

If you've run into behavior in the type checker that suggests the type stubs for a given library are incorrect or incomplete, we want to hear from you!

Our main forum for discussion is the project's GitHub issue tracker. This is the right place to start a discussion of any of the above or most any other topic concerning the project.

For less formal discussion, try the typing chat room on gitter.im. Some typeshed maintainers are almost always present; feel free to find us there and we're happy to chat. Substantive technical discussion will be directed to the issue tracker.

Description
Collection of library stubs for Python, with static types
Readme Multiple Licenses 29 MiB
Languages
Python 99.8%
Shell 0.2%