[Python-ideas] PEP for executing a module in a package containing relative imports (original) (raw)
Brett Cannon brett at python.org
Sun Apr 22 20:44:56 CEST 2007
- Previous message: [Python-ideas] PEP for executing a module in a package containing relative imports
- Next message: [Python-ideas] PEP for executing a module in a package containing relative imports
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 4/22/07, Christian Heimes <lists at cheimes.de> wrote:
Steven Bethard wrote: > I think this PEP now needs to explicitly state that keeping the "am I > the main module?" idiom as simple as possible is not a goal. Because > everything I've seen (except for the original proposals in the PEP) > are substantially more complicated than the current:: > > if name == 'main': >
I'm proposing the following changes: * sys.main is added which contains the dotted name of the main script. This allows code like: if name == sys.main: ... mainmodule = sys.modules[sys.main] * name is never mangled and contains always the dotted name of the current module. It's not set to 'main' any more.
That can't be true. If I am in the directory /spam but I execute the file /bacon/code.py, what is the name of /bacon/code.py supposed to be? It makes absolutely no sense unless sys.path happens to have either / or /bacon. This is why I wondered out loud if setting whatever attribute that is chosen not to main should only be done with '-m' as that keeps it simple and clear instead of having to try to reverse-engineer a file's name attribute.
You can get the current module object with
thismodule = sys.modules[name] * I'm against sys.modules['main] = mainmodule because it may cause ugly side effects with reload.
I assume that key is a string? There is a single quote that is not closed off.
The same functionality is available with sys.modules[sys.main]. The Zen Of Python says that there should be one and only one obvious way.
> I guess I don't understand why we wouldn't be willing to put up with a > new module attribute or builtin to minimize the boilerplate in pretty > much every Python application out there. Why bother with the second price when you can win the first prize? In my opinion a main() function makes live easier than a main module level variable. It's also my opinion that the main code should be in a function and not in the body of the module. I consider it good style because the code is unit testable (is this a word? g) and callable from another module while code in the body is not accessable from unit tests and other scripts.
People can stop wishing for this. I am not going to be writing a PEP supporting this. I don't like it; never have. I like how Python handles things currently in terms of relying on how module are executed linearly.
I am totally fine if people propose a competing PEP or try to resurrect PEP 299, but I am not going to be the person who does that leg work.
-Brett
- Previous message: [Python-ideas] PEP for executing a module in a package containing relative imports
- Next message: [Python-ideas] PEP for executing a module in a package containing relative imports
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]