Description
I would like to discuss reverting the changes that introduced the lazy-loader
package. I have been unhappy with this change basically almost from the start (although I made a positive comment in the initial discussion, but this was before I fully understood how lazy loading was implemented), and I think it is not good for the project's health in the long run for the following reasons:
- Lazy loading is essentially a sophisticated workaround rather than a supported Python feature. The relevant PEP 690 was rejected, and the related discussion suggests it's unlikely to be officially adopted in the future. As a result, the mechanism is not guaranteed to work in all cases and has already shown instances of breaking.
- The package relies on
.pyi
files for runtime behavior, which contradicts their intended purpose. Official references, such as PEP 561 and PEP 484, explicitly state that stub files are strictly meant for static type checking and not execution. - Lazy loading can be useful for CLI tools or packages with many submodules, where startup time is a major concern. However, I think the advantages for MNE-Python are questionable:
- The import time wasn't particularly long to begin with.
- While a 50% reduction in relative terms sounds significant, the absolute gain is just 175 milliseconds, which is negligible.
- We already used nested imports for optional dependencies, and nested imports can also be used to import packages on demand without the need for the non-standard
lazy-loader
mechanism. - Delaying imports until first use might be more disruptive than a slightly longer initial import time.
- The
lazy-loader
package does not appear to be very actively maintained beyond some tooling updates, and there are several unresolved issues such as all packages being loaded at once (issue #131) and eager imports not working as expected (issue #128).
Given these concerns, I strongly suggest that we at least reconsider our decision to adopt the lazy-loader
package. Since this will be a rather large change involving many files and probably a lot of manual work, I'm happy to submit a PR if there is general agreement that this is the right direction. It is also not super urgent, but I think the sooner we address this, the easier it will be to revert the changes.