pythonpath and optimize def. before init

[1d332e54-3b86-44a9-8fc6-e0c6e60d2a36]

BPO	429614
Nosy	@gvanrossum, @loewis, @freddrake
Files	pyinit-functions.diffc: cvs diff -c against sourceforge mainline

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = created_at = labels = ['interpreter-core'] title = 'pythonpath and optimize def. before init' updated_at = user = 'https://bugs.python.org/giacometti' ``` bugs.python.org fields: ```python activity = actor = 'gvanrossum' assignee = 'none' closed = True closed_date = None closer = None components = ['Interpreter Core'] creation = creator = 'giacometti' dependencies = [] files = ['3347'] hgrepos = [] issue_num = 429614 keywords = ['patch'] message_count = 12.0 messages = ['36713', '36714', '36715', '36716', '36717', '36718', '36719', '36720', '36721', '36722', '36723', '36724'] nosy_count = 4.0 nosy_names = ['gvanrossum', 'loewis', 'fdrake', 'giacometti'] pr_nums = [] priority = 'normal' resolution = 'rejected' stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue429614' versions = [] ```

[1d332e54-3b86-44a9-8fc6-e0c6e60d2a36]

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

[61337411-43fc-4a9c-b8d5-4060aede66d0]

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.

[1d332e54-3b86-44a9-8fc6-e0c6e60d2a36]

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

[61337411-43fc-4a9c-b8d5-4060aede66d0]

Logged In: YES user_id=21627

You can find the PEP guidelines in PEP-1: http://python.sourceforge.net/peps/pep-0001.html

[freddrake]

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.

[1d332e54-3b86-44a9-8fc6-e0c6e60d2a36]

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

[1d332e54-3b86-44a9-8fc6-e0c6e60d2a36]

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

[1d332e54-3b86-44a9-8fc6-e0c6e60d2a36]

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

[1d332e54-3b86-44a9-8fc6-e0c6e60d2a36]

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

[gvanrossum]

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.

[1d332e54-3b86-44a9-8fc6-e0c6e60d2a36]

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.

[gvanrossum]

Logged In: YES user_id=6380

It may be easy to implement, but it's still code bloat.

It may be easy to use, but it seems only useful in uncommon situations, where another way of accomplishing the same thing is already possible.

I'm rejecting this now.