PEP 810: Explicit lazy imports

PEPs
242

Hi everyone,

We (the authors of PEP 810) wanted to take a moment to say thank you all for the level of engagement in this discussion. Seeing so many of you care this deeply about making this feature better or to raise concerns about it is very important for us, and we are deeply humbled by the participation.

We need to ask for your understanding on something though. The volume of feedback has been absolutely massive. Between this thread private emails, and other channels, we’re getting hundreds of comments and suggestions. I’m personally spending over 3 hours every single day just trying to keep up and make sure we’re capturing the important stuff and we keep the PEP up to date and making the web demo. We’re constantly updating the PEP based on what we’re hearing, but please know that if we don’t respond to your specific comment, it doesn’t mean we didn’t read it or that it wasn’t valuable. We’re reading everything. We just physically can’t reply to every single point.

So please understand if we try to focus the discussion towards convergence. If we try to solve every possible use case and address every extension idea right now, this discussion will never converge. The PEP will become unwieldy, harder to review, and honestly, harder to implement well. We already have an embarrassingly long list of “rejected ideas”, “deferred ideas” and “alternative ideas” :sweat_smile: So we’re taking the approach of nailing the core feature set first and then allowing people to build on top of it later.

With that in mind, we’re closing the discussion on a few categories of suggestions:

  • New syntax in any form. We consider that the syntax is settled. We’ve thought about it extensively, we’ve considered the alternatives, and we’re confident in what we have.

  • New semantics on top of the core proposal. Things like lazy attributes, alternative semantics for lazy imports inside try/except blocks, special fallback clauses, and similar extensions. These are interesting ideas, but they belong in future work, not this PEP.

  • Lazy imports in try/except blocks. We’ve decided to forbid them. The semantics would be too complex and surprising (exception handlers executing at a distance from where they’re defined), and there are reasonable workarounds for the common use cases. Additionally, we don’t want to deviate from the global activation where we need to make it eager for compatibility.

  • Anything else that can be built on top later. If it’s not essential to making the basic lazy import mechanism work, we’re leaving it for follow-up work.

We know some of you have suggestions you’re really excited about. We get it, and we genuinely appreciate the creativity and effort behind them. But if we try to be everything to everyone right now, we’ll end up with nothing. Let’s ship something solid that solves the real problems people are facing, and then we can iterate and extend based on actual usage patterns.

Please understand we can’t put every single permutation of ideas into the “rejected” section. If we tried to document why we rejected every variation and combination that’s been proposed, the PEP would be unreadable. We’re focusing on the major alternatives we seriously considered.

That said, we do need your input on some genuinely open questions where we haven’t made a final decision yet:

  • Should lazy imports be forbidden in with blocks? (see PEP 810: Explicit lazy imports - #225 by cekopic).
  • Should there be a way to access module __dict__ without reification from outside the module* Something like __raw_dict__ has been suggested for introspection use cases. Any other options
  • Should we include something like a free function to force reification on objects (or the entire module) instead?

Thanks again for being part of this. Your energy and input make a difference!

The PEP 810 team

31 Likes