Skip to content

Introduce types (replace stubs in typeshed) #953

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

Closed
darxriggs opened this issue Jan 23, 2021 · 4 comments
Closed

Introduce types (replace stubs in typeshed) #953

darxriggs opened this issue Jan 23, 2021 · 4 comments

Comments

@darxriggs
Copy link
Contributor

Now that Python 3.6 is the minimum required Python version, it would be a good idea to maintain the types that are currently maintained in typeshed (see #524) directly in this library. Otherwise they easily get out of sync which is already the current state unfortunately.

@darxriggs darxriggs changed the title Introduce types Introduce types (replace stubs in typeshed) Jan 23, 2021
@methane
Copy link
Member

methane commented Jan 24, 2021

I still don't like it. I am waiting to minimum supported version become Python 3.10. See python/cpython#23316

Or at least Python 3.7; we can use from __future__ import annotations.

Otherwise they easily get out of sync which is already the current state unfortunately.

Why it's easy? DB-API is very stable. And other APIs are not important for end-users.
I suppose you typed so much.

@Akuli
Copy link

Akuli commented Jul 8, 2021

You can have type hints without from __future__ import annotations; they just have to be written so that the interpreter understands them. For example, you write from typing import Optional, List and then annotate things with Optional[str] or List[int], instead of using the newer str | None or list[int] syntax, available with from __future__ import annotations. But that said, if you want to do type hints once and not have to change them much afterwards, it can be better to wait for 3.7.

Also, I don't see what that pull request has to do with type hints in pymysql. It appears to change something much lower-level than a Python library needs to care about.

@methane
Copy link
Member

methane commented Jul 9, 2021

It increase memory usage and time for import.

@Akuli
Copy link

Akuli commented Jul 9, 2021

Python caches modules, so if pymysql uses import typing anywhere at all, it doesn't matter much whether it's used in many files or just one. Even with from __future__ import annotations, you will occasionally need something from typing, such as Any, Generic, TypeVar, overload or NoReturn, all of which are currently used in the typeshed PyMySQL stubs. You can generally put stuff like that under if TYPE_CHECKING:, but TYPE_CHECKING must be imported from typing, so you will need to load typing anyway.

We are talking about approximately 5% more time, assuming no other libraries used than PyMySQL, or about 2% if you use PyMySQL and requests, for example. On my system:

  • python3 -c "import pymysql" takes 55ms
  • python3 -c "import pymysql, typing" takes 58ms
  • python3 -c "import pymysql, requests" takes 145ms

I don't know of a good way to measure memory usage, so I didn't check that.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants