[Python-Dev] Criticism of execfile() removal in Python3

[Jim Baker]

On Mon, Jun 9, 2014 at 9:03 PM, Steven D'Aprano <steve at pearwood.info> wrote:

> ...
> There's nothing stopping alternative implementations having their own
> implementation-specific standard library modules.
>
> steve at orac:/home/s$ jython
> Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19)
> [OpenJDK Server VM (Sun Microsystems Inc.)] on java1.6.0_27
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import java
> >>>
>
>
Small nit: Jython does implement a number of implementation-specific
modules in its version of the standard library; jarray comes to mind, which
is mostly but not completely superseded by the standard array module.
However, the java package namespace is not part of the standard library,
it's part of the standard Java ecosystem and it's due to a builtin import
hook:

Jython 2.7b3+ (default:6cee6fef06f0, Jun 9 2014, 22:29:14)
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_60
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/home/jbaker/jythondev/jython27/dist/Lib', '__classpath__',
'__pyclasspath__/', '/home/jbaker/.local/lib/jython2.7/site-packages',
'/home/jbaker/jythondev/jython27/dist/Lib/site-packages']

The entry __classpath__ means search CLASSPATH for Java packages; this
includes the Java runtime, rt.jar, from which you get package namespaces as
java.*, javax.*, sun.*, etc.

Another behavior that you get for free in Jython is being able to also
import the org.python.* namespace, which is Jython's own runtime. Some of
the implementations of standard library modules, such as threading, take
advantage of this support.

- Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140609/4362eeab/attachment.html>