PEP 702 (@deprecated): improve the handling of explicit type annotations of assignment statements by tyralla · Pull Request #17899 · python/mypy

tyralla · 2024-10-08T20:27:00Z

Two improvements of the current PEP 702 implementation (deprecated):

Analyse the explicit type annotations of "normal" assignment statements (that have an rvalue).
Dive into nested type annotations of assignment statements.

(I intend to continue working on PEP 702 and would prefer to do so in small steps if this is okay for the maintainers/reviewers.)

* Analyse the explicit type annotations of "normal" assignment statements (that have an rvalue). * Dive into nested type annotations of assignment statements.

for more information, see https://pre-commit.ci

tyralla · 2024-10-08T21:56:41Z

Only a single new note is reported by the primer, but at least it is correct.

@ilevkivskyi: A part of this PR addresses this remark you made.

ilevkivskyi

Thanks! Here are couple comments.

ilevkivskyi · 2024-10-09T10:10:17Z

+ self.check_deprecated(typ.type, s)
+ for arg in typ.args:
+ self.search_deprecated(arg, s, visited)
+ elif isinstance(typ, (UnionType, TupleType)):


This is not a robust way to do it. You should write a simple visitor instead.

I replaced search_deprecated with InstanceDeprecatedVisitor, which additionally considers CallableType and TypeAliasType. Do you see other relevant cases?

ilevkivskyi · 2024-10-09T10:12:17Z

+x5: Tuple[Tuple[D, C], E] # N: class __main__.C is deprecated: use C2 instead
+x6: List[C] # N: class __main__.C is deprecated: use C2 instead
+x7: List[List[C]] # N: class __main__.C is deprecated: use C2 instead
+x8: List[Optional[Tuple[Union[List[C], int]]]] # N: class __main__.C is deprecated: use C2 instead


Maybe add a test case involving type aliases (including generic and/or recursive ones).

…`CallableType` and `TypeAliasType`)

for more information, see https://pre-commit.ci

ilevkivskyi · 2024-10-10T08:27:23Z

 is_local: bool


+class InstanceDeprecatedVisitor(TypeVisitor[None]):


Sorry, this is not what I meant, you should inherit TypeTraverserVisitor instead, and override onlyvisit_instance() and maybe visit_type_alias_type() (the latter is only needed if you want to show an error at each use place, instead of only at the type alias definition r.h.s.)

No problem. TypeTraverserVisitor is the more convenient base class, of course. Now I know it exists.
I also changed the name visited to seen_aliases (in agreement with TypeArgumentAnalyzer).
I was unsure whether emitting deprecation notes due to using type alias definitions is a good idea. I had a slight tendency towards it, so I implemented it this way for now. Maybe @JelleZijlstra has a better thought-out opinion on this?

…d of `TypeVisitor`.

for more information, see https://pre-commit.ci

ilevkivskyi

This is almost ready, I have couple more comments.

I was unsure whether emitting deprecation notes due to using type alias definitions is a good idea.

It looks like PEP is intentionally vague on the details. If you want to know my opinion, I would say we should only warn once on the type alias definition.

JelleZijlstra · 2024-10-11T14:41:03Z

It looks like PEP is intentionally vague on the details. If you want to know my opinion, I would say we should only warn once on the type alias definition.

I tried to make it concrete, but likely missed some cases. In general, I'd want people to only get one deprecation notice per deprecated thing they use. I think what you're talking about here is an alias like Alias: TypeAlias = DeprecatedThing, where DeprecatedThing has the @deprecated decorator. In that case, I'd ideally expect a deprecation notice for the Alias definition, but not for every usage of Alias.

tyralla · 2024-10-11T16:06:14Z

Would you say the same for cases where Alias is imported from another module/library?

importlibx: lib.Alias# no deprecation warning?

Then, the author of lib would have no way to pass the information that Alias has been (indirectly) deprecated.

A highly exceptional case, of course...

JelleZijlstra · 2024-10-11T16:12:51Z

I would. PEP 702 is limited in the kinds of things it lets you mark as deprecated, and type aliases aren't on the list. We'd need a new PEP with new syntax to mark type aliases as deprecated.

tyralla · 2024-10-11T18:45:08Z

Okay, I did as you suggested. Thanks for your sharing your opinion, @JelleZijlstra, and doing the review, @ilevkivskyi!

github-actions · 2024-10-11T18:53:09Z

Diff from mypy_primer, showing the effect of this PR on open source code:

anyio (https://github.com/agronholm/anyio)
+ src/anyio/_backends/_asyncio.py:1063: note: class asyncio.unix_events.AbstractChildWatcher is deprecated: Deprecated as of Python 3.12; will be removed in Python 3.14 [deprecated]

ilevkivskyi · 2024-10-11T21:35:19Z

@tyralla After some more thinking it seems to me moving this visitor to earlier stages of analysis (i.e. to typeanal.py) will allow uniformly using it in all positions a type can appear. Otherwise you will chase a lot possible cases, like function annotations, type aliases targets, cast targets, type variable bounds etc.

ilevkivskyi · 2024-10-11T21:35:56Z

Anyway, since I already merged this one, you can do it in a follow-up PR.

tyralla · 2024-10-11T22:10:34Z

Thanks for the tip! I will try it.

This pull request generalises #17899. Initially, it started with extending #17899 to function signatures only, as can be seen from the following initial comments and the subsequent discussions. --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

tyrallaand others added 2 commits October 8, 2024 22:17

Two improvements of the current PEP 702 implementation (@deprecated):
89d5355
* Analyse the explicit type annotations of "normal" assignment statements (that have an rvalue). * Dive into nested type annotations of assignment statements.

[pre-commit.ci] auto fixes from pre-commit.com hooks
e2ccc4e
for more information, see https://pre-commit.ci

This comment has been minimized.
Sign in to view

tyrallaand others added 4 commits October 8, 2024 23:16

some fixes (mainly to avoid recursion errors)
755b479

some fixes (mainly to avoid recursion errors)
cf70747

[pre-commit.ci] auto fixes from pre-commit.com hooks
466ee43
for more information, see https://pre-commit.ci

fix type hint
55b4126

This comment has been minimized.
Sign in to view

hauntsaninja added the upnext label Oct 9, 2024

ilevkivskyi reviewed Oct 9, 2024
View reviewed changes

tyrallaand others added 3 commits October 10, 2024 08:25

search_deprecated -> InstanceDeprecatedVisitor (and additionally …
f8f8d73
…`CallableType` and `TypeAliasType`)

[pre-commit.ci] auto fixes from pre-commit.com hooks
8547b2e
for more information, see https://pre-commit.ci

avoid recursion errors
a484f16

This comment has been minimized.
Sign in to view

tyralla requested a review from ilevkivskyi October 10, 2024 08:14

ilevkivskyi reviewed Oct 10, 2024
View reviewed changes

tyrallaand others added 2 commits October 10, 2024 22:03

Derive InstanceDeprecatedVisitor from TypeTraverserVisitor instea…
6e9d4b4
…d of `TypeVisitor`.

[pre-commit.ci] auto fixes from pre-commit.com hooks
90039d8
for more information, see https://pre-commit.ci

This comment has been minimized.
Sign in to view

tyralla requested a review from ilevkivskyi October 10, 2024 20:26

ilevkivskyi approved these changes Oct 11, 2024
View reviewed changes

Comment threadmypy/checker.py Outdated
Comment threadmypy/checker.py Outdated

Do not report using indirectly deprecated aliases.
98fea8c

ilevkivskyi merged commit 0c10dc3 into python:masterOct 11, 2024

tyralla mentioned this pull request Oct 11, 2024
PEP 702 (@deprecated): consider all possible type positions #17926
Merged

tyralla added the topic-pep-702 PEP 702, @deprecated label Nov 8, 2024

		is_local: bool


		class InstanceDeprecatedVisitor(TypeVisitor[None]):

Uh oh!

Uh oh!

Conversation

tyralla commented Oct 8, 2024

Uh oh!

This comment has been minimized.

This comment has been minimized.

tyralla commented Oct 8, 2024

Uh oh!

ilevkivskyi left a comment

Choose a reason for hiding this comment

Uh oh!

ilevkivskyiOct 9, 2024

Choose a reason for hiding this comment

Uh oh!

tyrallaOct 10, 2024

Choose a reason for hiding this comment

Uh oh!

ilevkivskyiOct 9, 2024

Choose a reason for hiding this comment

Uh oh!

tyrallaOct 10, 2024

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

ilevkivskyiOct 10, 2024

Choose a reason for hiding this comment

Uh oh!

tyrallaOct 10, 2024

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

ilevkivskyi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

JelleZijlstra commented Oct 11, 2024

Uh oh!

tyralla commented Oct 11, 2024

Uh oh!

JelleZijlstra commented Oct 11, 2024

Uh oh!

tyralla commented Oct 11, 2024

Uh oh!

github-actionsBot commented Oct 11, 2024

Uh oh!

ilevkivskyi commented Oct 11, 2024

Uh oh!

ilevkivskyi commented Oct 11, 2024

Uh oh!

tyralla commented Oct 11, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants