New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document the possible values for __main__.__spec__ #63896
Comments
So that e.g. __main__.__spec__.name is the actual name of the module being executed. |
I've already started on this somewhat. However, I'm going to close out more of the other PEP-451 issues before going any further. Nick: when do you think things will settle down that you could field a question or two and some reviews relative to the __main__ changes. I keep wondering if I'll have inadvertently implemented good chunks of PEP-395 by the time I'm done here. <wink> |
Here's an outline of how I see __main__.__spec__ playing out relative to the various cmdline interfaces. == == == === ==== ======== ======== ======== ======== ============
Note: __main__.__spec__ in the -m case is addressed in issue bpo-19700. Thoughts? See: [1] http://docs.python.org/3.4/using/cmdline.html |
For the record, normal start-up happens like this (simplified):
Note: exec of the site module does not impact the spec. In the case where -i/PYTHONINSPECT is issued (or implied):
Note: the -i case does not impact the spec, nor does the exec of any PYTHONSTARTUP script. See: [1] http://docs.python.org/3.4/using/cmdline.html |
Food for thought: We could (for 3.5) add an importer just for __main__ that gives us the appropriate spec and loads __main__ accordingly. Such a loader could even incorporate exec of the site module (and any PYTHONSTARTUP script). |
You'd also need to update the new multiprocessing code - it currently expects "__main__.__spec__ == None" for all the run-from-a-path-or-stdin cases. The -m switch and running __main__ from a supplied sys.path entry (the "dir" entry in your table) are both already handled by the runpy changes in bpo-19700. The remaining cases where __main__.__spec__ is currently None:
To be honest, I'm not sure it actually makes sense to try to manufacture a pseudo-spec for those cases. A main script may not be importable as a module (e.g. a hyphen in its name, or no .py suffix), and you *definitely* can't import a file that doesn't exist on disk (REPL, stdin, -c). |
I'm fine with leaving __spec__ as None for those remaining cases. It definitely simplifies this ticket. :) Do you see any reason to not close this one at this point? |
I think we need to document this somewhere. Not exactly sure where though - a new subsection in the import reference, perhaps? |
Here's a basic patch. It introduces __main__ in import.rst and then identifies the cases where __spec__ is set to None or otherwise. There are a few :ref: links to labels on other pages that I had trouble with. I'll address those when I put up a new draft after feedback. Any suggestions on making them work would be helpful. :) |
Looks like a reasonable general structure to me. For label references, you don't want to include the leading underscore - that's part of the label syntax, not the label itself. |
That did the trick, Nick. I swear there's always something I forget about ReST. :) Otherwise do you have any objections to the patch? I imagine there's more we could put in the section (for language spec purposes), but I figure what I have there is good enough for the moment. |
"is some cases" is a typo, but otherwise, yeah, may as well commit this so the website gets updated while we decide what else (if anything) we want to cover. |
New changeset 21d8222b667f by Eric Snow in branch 'default': |
New changeset 4972475ae2e7 by Eric Snow in branch '3.4': |
Wish I had done that in the opposite direction. Anyway, thanks Nick. |
New changeset 0427c2ff653d by Nick Coghlan in branch '3.4': New changeset a90254be2da2 by Nick Coghlan in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: