[Patches] [ python-Patches-429614 ] pythonpath and optimize def. before init
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 12 Sep 2001 10:32:40 -0700
Patches item #429614, was opened at 2001-06-02 08:56
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470
Category: Core (C code)
Group: None
Status: Open
Resolution: Postponed
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: pythonpath and optimize def. before init
Initial Comment:
A) Addition of four functions
=====================
Py_{Set, Get}{PythonPath, OptimizeLevel}()
with the same semantics as Py_{Set, Get}ProgramName()
(Note: the C ANSI type 'char const*' is used to describe non-modifiable strings)
These four functions are needed in the next JPE runtime (Python 2.1 patch included in the
distribution); this allows setting the PYTHONPATH and optimize level from Java property values.
B) Option '-P pythonpath' on the Python command line:
========================================
This option defines 'pythonpath' from the command line (and override the PYTHONPATH
environment variable if necessary).
Usefullness: Sometimes, one does not want to rely on the environment variables, or modify them.
Sample application: Running build and test scripts in full control of the environment, and with
different PYTHONPATH values.
This option is needed by the build and test scripts of the next JPE source distribution (Python 2.1
patch included in the distribution.
Frederic Giacometti
fred@arakne.com
----------------------------------------------------------------------
>Comment By: Frederic Giacometti (giacometti)
Date: 2001-09-12 10:32
Message:
Logged In: YES
user_id=93657
The motivation seems fairly clear to me:
python -p is easy to understand, to use, and to implement.
The present syntax (PYTHONPATH= python ...) depends upon
the shell being used (won't work in C shell), has side
effects (redefine locally the shell variable...).
It's a convenience feature, for use especially when
integrating python with other script-based tools (Make, ksh,
csh, bash), especially in non-regression and build scripts.
As to what you propose (small script directly setting
sys.path), this is not feasible in the context above; a
context in which the 'python -c' command would be used,
typically.
On can live without it, but there will be no revolution
adding it either; not does it really cost anything.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-07 18:57
Message:
Logged In: YES
user_id=6380
(A) You will hear from Barry soon.
(B) I don't see the advantage of using -p or -P. I don't
understand the motivation you are giving; can you explain it
better? If you want control over the path without setting
PYTHONPATH, you can write a small script that sets sys.path
directly.
----------------------------------------------------------------------
Comment By: Frederic Giacometti (giacometti)
Date: 2001-09-07 15:25
Message:
Logged In: YES
user_id=93657
Since I'm still battling in Python's configure and
Makefile.pre.in files, here are some more occurences:
WIth the patch:
PYTHONPATH=$(LIBDEST) \
./$(PYTHON) -tt $(LIBDEST)/compileall.py $(LIBDEST)
PYTHONPATH=$(LIBDEST) \
./$(PYTHON) -O $(LIBDEST)/compileall.py $(LIBDEST)
would be replaced by:
./$(PYTHON) -p $(LIBDEST) -tt $(LIBDEST)/compileall.py
$(LIBDEST)
./$(PYTHON) -p $(LIBDEST) -O $(LIBDEST)/compileall.py
$(LIBDEST)
Some more can be found...
FG
----------------------------------------------------------------------
Comment By: Frederic Giacometti (giacometti)
Date: 2001-09-07 15:18
Message:
Logged In: YES
user_id=93657
I'm getting back on the issue - Three months after
submitting the patch, and one month after writing the PEP
proposal, Barry W. still hasn't assigned a PEP number -.
I have been working on the Python 2.1.1 build lately, and I
stumble into this in the Makefile:
There are 8 occurences of Make shell commands of the kind
PYTHONPATH= $(PYTHON) ...
This is the kind of thing that could be replaced a lot more
clearly (and portably) with:
$(PYTHON) -p "" ...
if the patch were applied.
If still think a PEP discussion is not necessary for this;
especially since the PEP process seems frozen in this
regard.
In any event, it is desirable that the feature be included
before the final 2.2 release.
Thanks,
Frederic Giacometti
----------------------------------------------------------------------
Comment By: Frederic Giacometti (giacometti)
Date: 2001-09-07 13:59
Message:
Logged In: YES
user_id=93657
I'm getting back on the issue - Three months after
submitting the patch, and one month after writing the PEP
proposal, Barry W. still hasn't assigned a PEP number -.
I have been working on the Python 2.1.1 build lately, and I
stumble into this in the Makefile:
There are 8 occurences of Make shell commands of the kind
PYTHONPATH= $(PYTHON) ...
This is the kind of thing that could be replaced a lot more
clearly (and portably) with:
$(PYTHON) -p "" ...
if the patch were applied.
If still think a PEP discussion is not necessary for this;
especially since the PEP process seems frozen in this
regard.
In any event, it is desirable that the feature be included
before the final 2.2 release.
Thanks,
Frederic Giacometti
----------------------------------------------------------------------
Comment By: Frederic Giacometti (giacometti)
Date: 2001-08-05 20:37
Message:
Logged In: YES
user_id=93657
I apologize for the delay, but I have been travelling a lot for the last 2 months, and I could not have
followed up a PEP.
I'm now stabilized, so here is the PEP proposal I just mailed to Barry.
Regards,
Frederic Giacometti
--------------------------------------
PEP XXX: Addition of an option for completing sys.path from the commandline
fred@arakne.com (Frederic Giacometti)
Abstract
At present, the PYTHONPATH environment variable is the only method
for defining additional Python module directories.
This PEP introduce the '-P' valued option to the python command as
an alternative to PYTHONPATH.
Copyright: This document is published under the Open Publication License.
Specification:
On Unix:
python -P $SOMEVALUE
will be equivalent to
env PYTHONPATH=$SOMEVALUE python
On Windows 2K:
python -P $SOMEVALUE
will (almost, humm) be equivalent to
set __PYTHONPATH=%PYTHONPATH% && set PYTHONPATH=%SOMEVALUE% && python && set
PYTHONPATH=__%PYTHONPATH%
Reference Implementation and PEP pre-history:
See patch http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-03 22:29
Message:
Logged In: YES
user_id=3066
Flagged this patch as postponed pending the availability of
a suitable or at least a publically archived discussion that
indicates this is a useful and non-controversial change.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-06-10 22:53
Message:
Logged In: YES
user_id=21627
You can find the PEP guidelines in PEP 1:
http://python.sourceforge.net/peps/pep-0001.html
----------------------------------------------------------------------
Comment By: Frederic Giacometti (giacometti)
Date: 2001-06-08 14:37
Message:
Logged In: YES
user_id=93657
1) PEP: I am not in python-dev. What is the procedure for opening the PEP?
2) Override: I though about the question. My response was:
If you wnat concatenation, use:
python -P "something:$PYTHONPATH"
or
python -P "$PYTHONPATH:something"
That's for all the better...
3) I renamed Py_{Set,Get}OptimizeFlag to Py_{Set,Get}OtimizeLevel after I wrote the documentation. Glad
you caught the typo :)), sorry :((
I changed 'Flag' to 'Level' because 'Flag' normally designates a binary variable (2 states) whereas what we
are doing is actually defining a debuging level (3 levels as of now, but who knows that some more levels
might be addes).
'OptimizeLevel' is more accurate and less ambiguous than 'OptimizeFlag'.
Frederic Giacometti
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-06-07 12:58
Message:
Logged In: YES
user_id=21627
I think a PEP describing the exact rationale and nature of
the change is required here. For example, why is it good
that -P overrides PYTHONPATH, instead of combining both
somehow?
Also, the documentation talks about Py_GetOptimizeLevel,
whereas the header declares Py_GetOptimizeFlag.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470