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

Discuss alternative terminology in PEP 395 and show an 'after' example of what the PEP allows when it comes to command line invocation inside packages

This commit is contained in:
Nick Coghlan 2011-11-20 21:46:12 +10:00
parent ec5d9254c7
commit 145cc8d557
1 changed files with 67 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
pep-0395.txt
View File

@ -275,6 +275,36 @@ import system will add it automatically (setting it to the same value as
``__name__``).
Alternative Names
-----------------
Two alternative names were also considered for the new attribute: "full name"
(``__fullname__``) and "implementation name" (``__implname__``).
Either of those would actually be valid for the use case in this PEP.
However, as a meta-issue, it seemed needlessly inconsistent to add *two*
terms that were essentially "like ``__name__``, but different in some cases
where ``__name__`` is missing necessary information" and those terms aren't
accurate for the PEP 3155 function and class use case.
PEP 3155 deliberately omits the module information, so the term "full name"
is simply untrue, and "implementation name" implies that it may specify an
object other than that specified by ``__name__``, and that is never the
case for PEP 3155 (in that PEP, ``__name__`` and ``__qualname__`` always
refer to the same function or class, it's just that ``__name__`` is
insufficient to accurately identify nested functions and classes).
If the relative inscrutability of "qualified name" and ``__qualname__``
encourages interested developers to look them up at least once rather than
assuming they know what they mean just from the name and guessing wrong,
that's not necessarily a bad outcome.
Besides, 99% of Python developers should never need to even care these extra
attributes exist - they're really an implementation detail to let us fix a
few problematic behaviours exhibited by imports, pickling and introspection,
not something people are going to be dealing with on a regular basis.
Eliminating the Traps
=====================
@ -390,6 +420,43 @@ would have the following semantics::
This PEP also proposes that the ``split_path_module()`` functionality be
exposed directly to Python users via the ``runpy`` module.
With this fix in place, and the same simple package layout described earlier,
*all* of the following commands would invoke the test suite correctly::
# working directory: project/package/tests
./test_foo.py
python test_foo.py
python -m test_foo
python -m tests.test_foo
python -m package.tests.test_foo
python -c "from .test_foo import main; main()"
python -c "from ..tests.test_foo import main; main()"
python -c "from package.tests.test_foo import main; main()"
# working directory: project/package
tests/test_foo.py
python tests/test_foo.py
python -m tests.test_foo
python -m package.tests.test_foo
python -c "from .tests.test_foo import main; main()"
python -c "from package.tests.test_foo import main; main()"
# working directory: project
package/tests/test_foo.py
python package/tests/test_foo.py
python -m package.tests.test_foo
python -c "from package.tests.test_foo import main; main()"
# working directory: project/..
project/package/tests/test_foo.py
python project/package/tests/test_foo.py
# The -m and -c approaches still don't work from here, but the failure
# to find 'package' correctly is pretty easy to explain in this case
Depending on the details of how it invokes the script, Idle would likely also
be able to run ``test_foo.py`` correctly with F5, without needing any Idle
specific fixes.
Compatibility with PEP 382
~~~~~~~~~~~~~~~~~~~~~~~~~~