[Python-Dev] avoiding accidental shadowing of top-level libraries by the main module (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Tue Jul 13 12:45:20 CEST 2010

On 13/07/2010 01:30, Steven D'Aprano wrote:

On Tue, 13 Jul 2010 08:05:24 am Nick Coghlan wrote:

On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake<fdrake at acm.org> wrote:

On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord

<fuzzyman at voidspace.org.uk> wrote:

I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as main with a different name it would solve these problems. Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct. And here I've been busily blurring that distinction for years ;) (actually, the whole "name == 'main'" idiom meant the distinction was already pretty blurry long before I got involved) I would hate it if that distinction was un-blurred. Most of my modules include a section "if name == 'main': runtests(), and some of them do significantly more than that. A few of them import themselves so they can pass the module object to another module.

Reimporting yourself (and creating a second version of the module with new versions of all the classes / constants / functions / etc) doesn't seem like a good way of doing that though. If you need the module object you can always do:

module = sys.modules[name]

Michael Foord

I take it the concrete proposal here is if the filename of a new module matches either main.file or main.cached, then that module should be ignored completely for import purposes allowing a module with the same name later on sys.path to be found?

I'm not sure I like that, I'd be more inclined to just return the main module in that case rather than letting the search continue further down sys.path (although I agree the current semantics of getting two copies of the same module under different names in this case are less than ideal). Yes, that's a weird corner case. I don't see any advantage to keeping that behaviour.

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

More information about the Python-Dev mailing list