gh-148406: Fix annotations of _colorize.FancyCompleter#148408
gh-148406: Fix annotations of _colorize.FancyCompleter#148408danielhollas wants to merge 1 commit intopython:mainfrom
Conversation
|
This is a change in a private module that should not be user facing so I don't think blurb is needed? |
| @@ -1,3 +1,4 @@ | |||
| import builtins | |||
There was a problem hiding this comment.
Can we just do from builtins import str as _str? it may be a bit easier to read then.
There was a problem hiding this comment.
we could, but I kind of like the explicitness of the current solution. But if others agree I am happy to change it
There was a problem hiding this comment.
I'm also good with that. I just know that in other modules we also have _str = builtins.str or _int = builtins.int. I'll let Hugo decide (I just find the repetition of builtins.str a bit less readable but that's my opinion)
There was a problem hiding this comment.
Ah, if it is already a pattern elsewhere then I am more okay with that. Will wait for others to chime in before changing.
sobolevn
left a comment
There was a problem hiding this comment.
One more idea: there's a special section for type imports in if False: right below. Maybe you should utilize it?
Fixes #148406, using an approach suggested in the issue.
Test plan
Before
After
Also added a regression tests to ensure that
remodule is not imported during_colorizeimport.We've just made
reimport lazy indataclasses(#148379), but because of the bug resolved here, it ended up being imported (because the annotations were strings, which was triggering the path that uses theremodule)._colorize.FancyCompleterdataclass are funky #148406