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

pep-0395.txt

@@ -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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~