[Python-checkins] peps: Discuss alternative terminology in PEP 395 and show an 'after' example of what
nick.coghlan
python-checkins at python.org
Sun Nov 20 12:46:23 CET 2011
http://hg.python.org/peps/rev/ab37bff186aa
changeset: 3999:ab37bff186aa
user: Nick Coghlan <ncoghlan at gmail.com>
date: Sun Nov 20 21:46:12 2011 +1000
summary:
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
files:
pep-0395.txt | 67 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/pep-0395.txt b/pep-0395.txt
--- a/pep-0395.txt
+++ b/pep-0395.txt
@@ -275,6 +275,36 @@
``__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 @@
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
~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list