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

Jim Baker jim.baker at zyasoft.com
Tue Jun 10 06:41:19 CEST 2014

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+ (Release251, Aug 4 2010, 07🔞19) [OpenJDK Server VM (Sun Microsystems Inc.)] on java1.6.027 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.

More information about the Python-Dev mailing list