Due to the excellent feedback from this discussion, I’ve trimmed this proposal down to focus on the core idea.
This feature proposes an optional mechanism called import auto.
When a file begins with import auto, any reference to a missing top-level module
(for example math, os, random) would be imported automatically on first use.
It applies only to module names — not symbols — and is deterministic and opt-in.
The goal is to simplify scripting, education, and REPL workflows where explicit imports add friction but little value.
Example:
import auto
print(math.sqrt(9)) # auto-imports math
print(os.listdir(‘.’)) # auto-imports os
Key ideas:
Works only if import auto is explicitly written in the file.
By default, affects standard-library modules only.
Can log each import for transparency (Auto-imported module ‘math’).
Doesn’t affect production code or explicit imports
This feature aims to reduce boilerplate in small or interactive scripts while staying consistent with Python’s philosophy of explicitness—since using it is itself an explicit opt-in
I’ve moved this to Ideas. Please don’t spam with a wall of text, especially for an idea that hasn’t been discussed before, but instead only highlight the key salient details of the proposal.
I can see lots of potential issues and confusions that this can cause. Among other things if I have a variable with a name that is similar to a module and I mistype it as the module name it will import the module rather than giving the exception that would help me determine the issue. In other words, there is the serious potential for it to mask bugs.
It is also unclear from the text whether this applies to standard library only or any installed package.
Just because other languages may or may not do something is not a reason for Python to adopt it.
Thanks, Dan - really appreciate the thoughtful critique.
You’re right that “Explicit is better than implicit” is core to Python’s identity, which is why this feature is designed as opt-in and deterministic - nothing changes unless a user explicitly enables it with import auto.
Regarding the bug-masking concern: the PEP proposes limiting automatic imports to known standard library modules only by default. That prevents unintentional imports of arbitrary packages or typos. If mathh doesn’t exist in the stalib, it would still raise a NameError.
For the second point (stdlib vs third-party), yes - the initial intent is stdlib only, with possible extension to installed packages as an explicit option (e.g., via a flag).
As for the “other languages” note — fair point. The intent isn’t to copy external behavior, but to smooth out repetitive friction for scripting and teaching contexts without changing Python’s core philosophy. Think of it as a convenience mode for interactive or educational use, not production code.
Thanks again — I’II tighten the proposal text to clarify these edges.
import auto
class MyRandoms:
def randint(self):
return 7
randoms = MyRandoms()
print(random.randint) # Will print a random number when the desired output is 7
# because of the typo - `random` instead of `randoms`
While this is an extreme example, it is something that can definitely happen with this proposal. I think the potential unintended consequences are serious and likely to cause more issues than they resolve. I agree that in the REPL it would be nice to not have to remember to do an import before running a command (something I run into all the time) but in normal development with an IDE it mostly takes care of that. Even neovim with an LSP is very helpful with handling it.
That’s a great example, Dan — thanks for illustrating it so clearly.
You’re absolutely right that typo-based shadowing like this (random vs randoms) is the main risk of this approach. My thinking is that import auto could mitigate that in a few ways:
Stdlib-only by default — it wouldn’t import anything not in sys.stdlib_module_names, so a typo matching a user class like randoms would still raise a NameError.
Optional strict mode — maybe import auto(strict=True) could require the first reference to match only a known stdlib module and not conflict with any existing local names.
Logging or warning hook — it could log Auto-imported module ‘random’ to stderr, so a developer immediately sees what happened (similar to lazy imports in Mercurial).
The point about IDEs and LSPs handling imports automatically is fair — the intent here is more for REPL use, short scripts, or educational settings where that tooling isn’t in place.
I’ll clarify those guardrails in the next draft — thanks again for pointing out a concrete case where unintended imports could bite.
I see where you’re coming from, but I think restricting it to a REPL flag would undercut most of the usefulness of the idea.
The feature’s value isn’t just for the REPL — it’s also for educational scripts, tutorials, notebooks, and short automation files where typing out several imports adds friction but no clarity.
Making it opt-in per file with import auto keeps safety while still benefiting those workflows. It’s explicit, deterministic, and reversible — if you don’t want it, you just don’t include that line.
The REPL mode could definitely be a good first implementation step, but I’d see that as an early stage, not the end goal. The long-term design target is to make import auto usable wherever light-weight Python code is written, not only in interactive shells.
Ok, it’s nice to see you having made an idea, and putting in the effort to make it into a PEP draft.
Sadly, this timing is quite bad, as PEP 810 is being discussed right now. This would essentially be a change somewhat relying on PEP 810, which is why I think that this is not the right time to post this.
Making a PEP post would also require correct formatting, which seems to have been broken in a few cases.
As others pointed out already, the first PEP render should be short yet exact. This is a text so long, that people might be scared to read it all, and then not participate in the discussion. Having a shorter draft might be better.
Thanks for the feedback — that makes sense. I’ll hold off on a formal PEP submission for now and instead keep this thread focused on the core idea and feedback around feasibility.
The long version I shared was meant to give a clear technical picture, but I agree it’s probably better to have a shorter summary here so people can react more easily.
Once the concept stabilizes, I’ll tighten the draft and re-format it properly if there’s enough community interest to take it further.
Appreciate the pointers about timing and formatting — noted for the next iteration
A PEP is one of the much-later steps in an idea’s development, and not every suggestion needs a PEP. You can’t submit one without a core dev’s say-so anyhow. For the time being, just focus on the idea itself and convincing people of the merits of it.
Tip: A briefer proposal is more likely to be read and considered. Massively lengthy posts like the OP here are often going to be skipped over. Make your point succinctly, and even then, be prepared for a lot of pushback
As to the proposal itself - I’m not really a fan, but there are some alternatives worth considering. For example, if you have a small handful of modules that you frequently use, you could import them and stick 'em into builtins, making them magically available. That’d be fairly convenient for interactive use, though I still wouldn’t do it in a script. (You’re welcome to, but I personally wouldn’t.) Or you could design an editor plugin that automatically inserts import statements for any missing modules. (These almost certainly exist for many editors; I don’t know which one you use.) It would help a lot to know exactly what the problem is that you’re trying to solve.
This is my first time posting an idea at this level, and I can see now that I jumped straight to the PEP stage before doing enough research on how proposals usually develop. I’ll definitely trim it down and focus the discussion on the concept itself rather than the full draft.
The core problem I’m trying to solve is reducing repetitive imports for small or educational scripts, where typing five import lines adds friction but no clarity. The goal isn’t to make everything implicit, but to provide an opt-in, deterministic shortcut for cases where the standard import model feels heavy-handed.
I appreciate the suggestion about editor or REPL tooling — that might be a good intermediate path to explore before considering a language-level feature.
Thanks again for the feedback — I’m learning a lot from this discussion.
Also, please don’t just generate PEPs and responses with ChatGPT. I’ve been reading the thread, and I’m still having a lot of trouble understanding what you’re even proposing – please use your own words!
Hi I don’t mean to be lazy or such, but English is not my first language, and yes I do use ChatGPT to edit my words a little, but the ideas are all mine, as I only told it to make it make more sense.
You are FAR from the first person to do that In fact, I’ve seen a lot of people think that “PEP” is synonymous with “idea for Python”, but it really isn’t. Especially, you shouldn’t feel that you need to write up something as long as existing PEPs (eg PEP 649 – Deferred Evaluation Of Annotations Using Descriptors | peps.python.org) just to propose your idea; the length of those documents reflects the gnarliness of some of the proposals. You can find a ton of good info about the PEP process in PEP 1.
The normal way these sorts of things go is to start with “Hey, here’s a cool idea”, with full expectation that you’ll get a bunch of responses saying “You could do that already, if you do X, Y, or Z”. Sometimes that will be suitable, in which case, awesome! (Sometimes we use a time machine to go back and add features to Python just so that we can give those sorts of responses.) But if not, you’ll then need to say why those aren’t suitable, which is an important step of refinement.
But I will second Peter Bierma’s request to please NOT use ChatGPT for your responses. I’m having to read your post and then try to deduce what you originally input, rather than simply reading the words as posted. Use your own words. Even if your English isn’t perfect, use your own words. Remember, if we want to see it refined by ChatGPT, we can always put it into ChatGPT ourselves.
Thanks for you kind words, I appreciate it a lot, I notice how much of a good idea I think this was before! With all the feedback and critique I am getting, I now see it as less as a “amazing” idea but more of a “ok” idea, and also, next time I will type the words myself, so people can interpret it if they want, as I realize if people want to understand then they will try to as much as possible.
I’d like to just clarify something. When I said that there would be responses saying “you can do this in other ways”, that does NOT mean that we think you shouldn’t have posted the idea. Sometimes, that’s just part of the process of discovery!
