Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module
On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake <fdrake@acm.org> wrote:
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord <fuzzyman@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 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). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/07/2010 23:05, Nick Coghlan wrote:
On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake<fdrake@acm.org> wrote:
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord <fuzzyman@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 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?
An explicit error being raised instead would be just as good. Michael
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).
Cheers, Nick.
-- 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.
On Tue, Jul 13, 2010 at 8:06 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
An explicit error being raised instead would be just as good.
Ah, refusing the temptation to guess. So the idea would be, when attempting to import __main__ under it's original name: 3.2 issue a DeprecationWarning 3.3 raise ImportError It still strikes me as wrong for the base import implementation, but PEP 302 may provide a mechanism for an interpreter shell to add its own "newbie protection" hooks (and that would have the virtue of being available much earlier and with a much lower chance of breaking anything). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/07/2010 23:23, Nick Coghlan wrote:
On Tue, Jul 13, 2010 at 8:06 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
An explicit error being raised instead would be just as good.
Ah, refusing the temptation to guess.
So the idea would be, when attempting to import __main__ under it's original name: 3.2 issue a DeprecationWarning 3.3 raise ImportError
That's what I was suggesting.
It still strikes me as wrong for the base import implementation, but PEP 302 may provide a mechanism for an interpreter shell to add its own "newbie protection" hooks (and that would have the virtue of being available much earlier and with a much lower chance of breaking anything).
That would be a nice thing to have for earlier versions of Python. Personally I think the confusion the problem it causes would be nicer fixed. All the best, Michael
Cheers, Nick.
-- 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.
On Tue, 13 Jul 2010 08:05:24 am Nick Coghlan wrote:
On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake <fdrake@acm.org> wrote:
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
<fuzzyman@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__': run_tests(), 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.
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. -- Steven D'Aprano
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@acm.org> wrote:
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
<fuzzyman@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__': run_tests(), 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.
participants (3)
-
Michael Foord -
Nick Coghlan -
Steven D'Aprano