Message12118
The environment variable JYTHONPATH determines the search path for Python code outside the standard library, in the way PYTHONPATH does for CPython. Incorrectly, it is not ignored when the -E option is given to the jython command. I propose to move its initialisation to org.python.util.jython at the same stage other variables are handled coverted to registry entries.
This will have the side effect that JYTHONPATH will no longer affect Java applications that create their own interpreter (only the property python.path does that). I think this is good, but may also be an unexpected change.
Rationale:
TL;DR: consistency; original design intent.
It its original design, Jython took configuration only from the Java Properties (read from the registry files and java -D options), not from environment variables. Published books tell us this is how it works, and Java discourages reliance on environment variables (https://docs.oracle.com/javase/tutorial/essential/environment/env.html). And it is mostly still true, except that JYTHONPATH is sampled in the middle of initialisation, in all circumstances, and overrides any -Dpython.path=value given to Java. For a pure Java application to rid itself of an inappropriate external JYTHONPATH it has to set python.path in the "post-properties" during initialisation.
It seems ok that jython.main() should pay attention to (certain) environment variables: it's a command used from the shell, and users can turn it off with the -E option. The similarity to CPython is good. There is a well-defined place for environment variables in the "pecking order" with other sources which JYTHONPATH slightly diverges from. |
|
Date |
User |
Action |
Args |
2018-09-23 13:41:06 | jeff.allen | set | recipients:
+ jeff.allen, zyasoft |
2018-09-23 13:41:06 | jeff.allen | set | messageid: <1537710066.16.0.956365154283.issue2706@psf.upfronthosting.co.za> |
2018-09-23 13:41:05 | jeff.allen | link | issue2706 messages |
2018-09-23 13:41:04 | jeff.allen | create | |
|