Bump imaplib to 3.14
#14022
Bump imaplib to 3.14
#14022
Conversation
This comment has been minimized.
This comment has been minimized.
stdlib/imaplib.pyi
Outdated
| @@ -42,11 +42,17 @@ class IMAP4: | |||
| PROTOCOL_VERSION: str | |||
| def __init__(self, host: str = "", port: int = 143, timeout: float | None = None) -> None: ... | |||
| def open(self, host: str = "", port: int = 143, timeout: float | None = None) -> None: ... | |||
| if sys.version_info >= (3, 14): | |||
| @property | |||
| @deprecated("Deprecated in Python 3.14; IMAP4.file is unsupported, can cause errors, and may be removed.") | |||
There was a problem hiding this comment.
| @deprecated("Deprecated in Python 3.14; IMAP4.file is unsupported, can cause errors, and may be removed.") | |
| @deprecated("IMAP4.file is unsupported, can cause errors, and may be removed.") |
Type checkers will already emit that it's deprecated, no need to repeat it.
Also I think we should mark this as @deprecated unconditionally, even on old versions, to put people on notice faster that they're using something unsupported.
There was a problem hiding this comment.
I added this as a prefix because we use this pattern in other places, but I agree with you
About @deprecated for old versions: I wouldn't mind if, but in older versions, file is implemented as an attribute, and the decorator is only suitable for a function like in new versions. and it seems wrong to do it through property if it is an attribute
There was a problem hiding this comment.
We could pretend it's a property on all versions but it's fine not to.
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
No description provided.