Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python Typing Support #9530

Open
burgholzer opened this issue Feb 3, 2023 · 3 comments
Open

Python Typing Support #9530

burgholzer opened this issue Feb 3, 2023 · 3 comments
Labels
type: feature request New feature or request

Comments

@burgholzer
Copy link
Contributor

What should we add?

Are there any plans to enable typing support for the qiskit-terra project (or, more broadly, qiskit as a whole) in line with https://peps.python.org/pep-0561/?
At the moment, a package that uses qiskit and corresponding type annotations will trip up type checkers such as mypy, with a warning of the sort

error: Skipping analyzing "qiskit": module is installed, but missing library stubs or py.typed marker [import]
from qiskit import QuantumCircuit

As a result, packages building on top of qiskit cannot be type checked properly/completely.
According to PEP 561, the solution could be as easy as adding a py.typed marker (file) to the package directory.

@burgholzer burgholzer added the type: feature request New feature or request label Feb 3, 2023
@mert-kurttutan
Copy link

To get the all the benefits of type annotation (e.g. auto complete, mypy checking), I think one should also need to add type annotation for python API. I can see manyl .py files that are not type annotated

@kdk
Copy link
Member

kdk commented Feb 6, 2023

This was discussed at the team meeting this week (in the context of a handful of open PRs that add annotations to various modules of the code, https://github.com/Qiskit/qiskit-terra/pulls?q=is%3Apr+mypy+author%3ARandl+ ).

The outcome was that the team is generally in favor of PRs adding or improving type annotations, especially where they help to clarify existing code structure. For now, there are no plans to make these mandatory for new changes or say as part of a CI check, at least until our annotations and tooling are in a place where they wouldn't be a barrier to new contributors.

@HuangJunye
Copy link
Collaborator

Related old discussions can also be found in this issue #6905

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature request New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants