Functools is no longer imported by enum in 3.14
1 Like
enum is a very expensive import, unfortunately. I’ve patched it out of some apps (replacing it with fairly basic pass-through functionality), mainly because it gets used by re, which ~doubles the total import time for that module for no benefit (in an app, that is - there’s for sure benefit for interactive use).
Yes, thankfully the enum import is less expensive in 3.14 - down from ~8ms in 3.13 to ~3ms locally due to the import deferrals but most of the rest of the import time is in the actual body of the module.
Removing the functools and ast imports may still be worth doing in annotationlib.
With deferral of both and converting annotationlib to a package:
import time: self [us] | cumulative | imported package
...
import time: 426 | 426 | types
import time: 1856 | 2281 | enum
import time: 187 | 187 | keyword
import time: 1289 | 3757 | annotationlib
Without:
import time: self [us] | cumulative | imported package
...
import time: 1672 | 1672 | _ast
import time: 640 | 2312 | ast
import time: 335 | 335 | types
import time: 2424 | 2759 | enum
import time: 231 | 231 | itertools
import time: 359 | 359 | keyword
import time: 214 | 214 | _operator
import time: 933 | 1147 | operator
import time: 1889 | 1889 | reprlib
import time: 571 | 571 | _collections
import time: 2832 | 7026 | collections
import time: 528 | 528 | _functools
import time: 2401 | 9954 | functools
import time: 2522 | 17545 | annotationlib
Should I make a PR? Would it need a specific open issue first, or just against Improve import time of various stdlib modules · Issue #118761 · python/cpython · GitHub
3 Likes
Please do open, though we can’t guarantee it will be approved. You can reference GH-118761.
A
1 Like
I do expect there will probably be some changes.
The Steering Council officially accepts PEP 749 - Implementing PEP 649 and wishes to extend our gratitude to PEP author @Jelle, the Typing Council, @larry (PEP 649’s author), @ambv (PEP 563’s author) and everyone who has worked so hard on and for so long on making deferred annotations work well in Python. We’re very happy and excited to see this effort reach fruition in Python 3.14.
We did ask for some minor clarifications to the documentation and PEP, but nothing that substantially changes the PEP or the feature for beta 1. I won’t repeat everything here, so keep an eye on the PEP repo for follow up PRs.
Congratulations!
28 Likes
Thanks Barry!
PEP changes are in PEP 749: Mark as Accepted by JelleZijlstra · Pull Request #4406 · python/peps · GitHub.
The implementation of the PEP in main is done, and will go out in 3.14 beta 1 tomorrow. If you’re reading this, please try it out and share your feedback!
There is some docs work left to be done, tracked in GitHub · Where software is built.
9 Likes
Do I understand it correctly that it’s not possible to write a module such that it uses deferred evaluation of annotations[1] on all Python versions supporting it (>= 3.7, or >= 3.9 when ignoring EOL versions) while having PEP 649/749 behavior on Python versions supporting it (>= 3.14)?
EDIT: with “deferred evaluation of annotations” I mean any form of deferred evaluation, regardless of whether using stringified annotations or descriptors ↩︎
1 Like
If by “deferred evaluation of annotations” you mean PEP 563-style stringified annotations, then yes you’re correct.
You can either not have from __future__ import annotations, and have eager evaluation on 3.13 and earlier and deferred evaluation on 3.14+, or you can have the __future__ import, which means stringified annotations on all versions.