iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

markup fixes

This commit is contained in:
David Goodger 2007-08-03 19:19:44 +00:00
parent 280b1f6494
commit daec32d317
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
pep-0366.txt
View File

@ -20,7 +20,7 @@ packages. Such imports currently fail due to an awkward interaction
between PEP 328 and PEP 338.
By adding a new module level attribute, this PEP allows relative imports
to work automatically if the module is executed using the ``-m``switch.
to work automatically if the module is executed using the ``-m`` switch.
A small amount of boilerplate in the module itself will allow the relative
imports to work when the file is executed by name.
@ -48,7 +48,7 @@ When the main module is specified by its filename, then the
``__package__`` attribute will be set to the empty string. To allow
relative imports when the module is executed directly, boilerplate
similar to the following would be needed before the first relative
import statement:
import statement::
if __name__ == "__main__" and not __package_name__:
__package_name__ = "<expected_pacakage_name>"
@ -68,9 +68,9 @@ Rationale for Change
====================
The current inability to use explicit relative imports from the main
module is the subject of at least one open SF bug report (#1510172)[1],
module is the subject of at least one open SF bug report (#1510172) [1]_,
and has most likely been a factor in at least a few queries on
comp.lang.python (such as Alan Isaac's question in [2]).
comp.lang.python (such as Alan Isaac's question in [2]_).
This PEP is intended to provide a solution which permits explicit
relative imports from main modules, without incurring any significant
@ -85,7 +85,7 @@ Reference Implementation
Rev 47142 in SVN implemented an early variant of this proposal
which stored the main module's real module name in the
'__module_name__' attribute. It was reverted due to the fact
``__module_name__`` attribute. It was reverted due to the fact
that 2.5 was already in beta by that time.
A new patch will be developed for 2.6, and forward ported to
@ -98,7 +98,7 @@ Alternative Proposals
PEP 3122 proposed addressing this problem by changing the way
the main module is identified. That's a significant compatibility cost
to incur to fix something that is a pretty minor bug in the overall
scheme of things, and the PEP was rejected [3].
scheme of things, and the PEP was rejected [3]_.
The advantage of the proposal in this PEP is that its only impact on
normal code is the small amount of time needed to set the extra