Conversation
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
ilevkivskyi
left a comment
ilevkivskyi
left a comment
There was a problem hiding this comment.
Nice. I am thinking however, is it possible to refactor the plugins to avoid the nested imports altogether? I mean there will be still penalty for people who do use functools, dataclasses, ctypes etc. I remember I did something similar for checkmember refactor by introducing some "interface classes".
Probably? I didn't look into the root cause of the import cycle (I'm not even sure if I even checked if there is an import cycle -- I just assumed because of the imports within functions.) |
Use precalculated set objects in more places. This is similar to #19385. Some cases were still unoptimized. I used trace logging (#19457) to identify functions where we were creating many set objects, and I noticed that these were unncessary. This is a part of a set of micro-optimizations that improve self check performance by ~5.5%.
Use precalculated set objects in more places. This is similar to #19385. Some cases were still unoptimized. I used trace logging (#19457) to identify functions where we were creating many set objects, and I noticed that these were unnecessary. This is a part of a set of micro-optimizations that improve self check performance by ~5.5%.
3 participants
Fix two kinds of inefficiency in the default plugin:
I also had to refactor things a little in order to optimize the nested imports.
This speeds up self check by about 2.2%. The default plugin is called a lot.