I deeply appreciate @brettcannon’s trust, but in case someone has any doubt I want to be crystal clear: I will absolutely quit my employer (current or future) if I were ever asked to push something fishy or detrimental to Python or the community just because it benefits them. No hesitation. This it’s a line I will not cross, period. And frankly, if you look at my track record, I regularly do things that make life harder for my employer or even my own work. For instance, when Mark and I implemented python-to-python inline calls, that was months of extra work to adapt our internal tools. And that’s just one of many examples.
That said, I want also to clarify the corporate involvement concerns directly, because there’s a fundamental misunderstanding here. The implementation in this PEP is fundamentally different from any other implementation, including all implementations made by my co-authors at their respective companies. Meta, Google, HRT, and other major companies already have working lazy import implementations that are fundamentally different from this one. They don’t need this PEP. These implementations are different from what we’re proposing: often more aggressive and tailored specifically to their controlled environments where they can make assumptions that simply don’t hold in the general Python ecosystem. They control their entire stack and have already solved their problems by forking CPython entirely.
This PEP is about bringing a well-designed, community-focused solution to everyone else: application developers who don’t have resources to maintain CPython forks, the Scientific Python community that’s been asking for this, CLI tool developers dealing with startup time issues, and anyone who wants to opt into lazy imports without rolling their own solution. You can check all the enthusiastic comments from users in this thread from all sort of backgrounds. In just two weeks this is already the most commented PEP thread in discuss.python.org ever and the sentiment is (in my own view) extremely positive. We designed this with the many similar use cases across the community in mind, not for any single corporation’s benefit.
And frankly, if you look at this thread and other forums, many people have been consistently asking for more aggressive versions where lazy imports would be the default behavior. Since making this the default isn’t possible as we know from the previous PEP and the compatibility issues, the global mode and the filter function are specifically designed to give application developers the tools to achieve similar results in their own codebases when they need it. We deeply believe this addresses a real use case that some subset of the user base have been asking for, not just something companies wanted. And that’s why is there. You can disagree and say here that you dislike these features of course and that’s completely fine (as reasonable people can disagree on design decisions). You can be sure the Steering Council will take these ideas into consideration when evaluating the PEP.
Do we expect companies with existing forks might eventually adopt this? Yes, because we designed something better for everyone, not something that exclusively serves them. And I think that mostly everyone would agree that having everyone working on the same Python instead of maintaining fragmented forks is better for the entire ecosystem it means improvements benefit everyone, bugs get fixed once, and the community stays unified. Also as a minor note, as @brettcannon mentions, companies with large codebases are legitimate Python users too, and bringing their use cases back into mainline Python strengthens the language for all of us. The alternative to this PEP isn’t “corporations don’t get lazy imports”: it’s that they continue maintaining fragmented forks while the rest of the community lacks this capability. That serves no one. And just to be also clear: avoiding this forks isn’t by far the major point fo the PEP.
I hope this clarifies things. Continuing to debate corporate motivations isn’t productive for evaluating the technical merits of this proposal, and I’d much rather focus the discussion on whether this feature serves the Python community’s needs and how to make it the best proposal possible.