On 7/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > PEP 299 recently got added to the list of ideas to be reconsidered for Py3k. > The motivation seemed to be that the current idiom is both ugly and > unintuitive if you haven't drunk enough of the relevant Koolaid. > > I can't really argue with that assessment, but I think PEP 299 proposes more > radical changes to the idiom than are really necessary. > > My preferred solution would look like this: > > 1. Determining if the current module is the main module: > > The boolean value __main__ would be defined in all modules. It would be set to > True in the main module, and False everywhere else. > > The existing "if __name__ == '__main__' idiom would be replaced by a simple > "if __main__:" > > A boolean flag that's true in the main module and false everywhere else should > be straightforward to both teach and remember (even simpler than trying to > explain a magic function that gets called only when the module is the main > module). > > This part of the proposal is all that most users would ever care about.
Two comments: - I'm not convinced that it's worth changing this. - *If* we're going to change this, we should reconsider whether it's really necessary to spell this with __underscores__. > 2. Accessing the main module from another module: > > A new attribute in the sys module "main" would always reference the main > module of the application. The main module would also be stored in sys.modules > under the name "sys.main", so that "import sys.main" and "from sys import > main" would correctly retrieve the main module. > > Usages of the form "import __main__" would be replaced by "import sys.main", > and "__main__.<attr>" would be replaced by "sys.main.<attr>". > > This part of the proposal is to avoid the name conflict between "import > __main__" and the proposed boolean flag. An alternative would be to use a > different name for the boolean flag (e.g. invert the sense of it, and call it > "__imported__"). Please consider what the use case is for accessing the main module, and whether we should consider providing a different solution for that use case rather than a different way to access the main module. > 3. Relative imports from the main module: > > Files that are executed directly would have their __name__ attribute set to > "<main>". Modules executed using -m would have their __name__ attribute set to > their real module name as provided on the command line. > > The main module would actually be referenced from sys.modules twice (once > under the name "sys.main" and once under the value of sys.main.__name__) > > Relative imports from directly executed modules would continue to behave as > for the 2.x series (since the import machinery only cares about the number of > dots preceding the module name, "<main>" will behave the same as "__main__"). > > Relative imports from modules executed with -m, however, would now be able to > use the normal relative import mechanism and the __module_name__ workaround > proposed for the 2.x series could disappear. Frankly, I am beginning to regret ever having endorsed the -m option. It seems leads to an ever increasing series of discussions about mundane details that aren't worth the intellectual power devoted to them. I still think that relative import from a main module is a solution in search of a problem, and I am beginning to feel the same about the other issues that you are addressing above. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
