https://docs.python.org/3/using/cmdline.html#cmdoption-c should be updated.

Thanks for this! This is a long-awaited and very useful change.

I was going to suggest fixes to some grammar errors and phrasing issues in the docs that were added, as well as an issue with the description in theman page sounding pretty cryptic for the average user, but I noticed this PR was still in a draft state. Is that just due to

https://docs.python.org/3/using/cmdline.html#cmdoption-c should be updated.

and it is otherwise ready for review? I'd be happy to help with that too, but it looks like a pretty small change, just updating it to reflect that an empty string rather than the working dir is added tosys.path[0].

FTR I considerDon't addsys.path[0] a bit confusing, as there will always besomesys.path[0]. What aboutDon'tprependsys.path with anything?

FTR I considerDon't addsys.path[0] a bit confusing, as there will always besomesys.path[0]. What aboutDon'tprependsys.path with anything?

Yep, I noticed that as well above. I can't claim either of your expertise, but I'm not a beginner either and have actively been following the progress of and looking forward to this feature, and yet I had to carefully re-read the linked issue to be sure that it was actually doing what I thought it was. As both a developer and a documentarian, it can be easy for me to write documentation (or PEPs, etc) that makes perfect sense to me but is confusing to others without deep implicit knowledge of the code—I've seen both sides of that a lot lately, as well as the value of having someone else look over it.

Awesome! Is there an associated environment variable?

Awesome! Is there an associated environment variable?

It would appear there isn't, as of yet.

I rebased my PR and marked it as ready for review ;-)

Can we add an associated environment variable?

Since different people asked for an environment variable, I changed my mind and I addedPYTHONDONTADDPATH0 environment variable. Example:

$ ./python -c 'import sys, pprint; pprint.pprint(sys.path)'['', '/usr/local/lib/python311.zip', '/home/vstinner/python/main/Lib', '/home/vstinner/python/main/build/lib.linux-x86_64-3.11-pydebug', '/home/vstinner/.local/lib/python3.11/site-packages']$ PYTHONDONTADDPATH0=1 ./python -c 'import sys, pprint; pprint.pprint(sys.path)'['/usr/local/lib/python311.zip', '/home/vstinner/python/main/Lib', '/home/vstinner/python/main/build/lib.linux-x86_64-3.11-pydebug', '/home/vstinner/.local/lib/python3.11/site-packages']

Proposed names so far (on python-dev and this PR), I add spaces for readability:

• PYTHON DONT ADD PATH0
• PYTHON DONT ADD PWD
• PYTHON DONT ADD MAIN DIR
• PYTHON DONT ADD IMPLICT DIRS
• PYTHON DONT ADD SCRIPT DIR
• PYTHON USE SAFE PATH

Proposed long option names (in the issue):

• "main path":--mainpath and--nomainpath
• "base path":--basepath <dir> and--no-basepath:https://bugs.python.org/issue33053#msg314192
• "path 0":--nopath0 with short option-p

Perl 5.26 no longer includes the current working directly by default in@INC to fixCVE-2016-1238 security vulnerability:https://metacpan.org/pod/perl5260delta#Removal-of-the-current-directory-(%22.%22)-from-@INC

PERL_USE_UNSAFE_INC env var can be used to opt-in for "unsafe"@INC (add current working directory).

Perl also has a "taint mode" enabled by the Perl-T command line option.

I updated my PR: it now uses thePYTHONSAFEPATH environment variable name.

• Replacebpo-13475 withgh-57684
• Renameadd_path0 tosafe_path (opposite meaning)
• Renamesys.flags.dont_add_path0 tosys.flags.safe_path
• RenamePYTHONDONTADDPATH0 env var toPYTHONSAFEPATH (shorter, easier to write)
• PR rebased, I fixed conflicts.

I love PYTHONSAFEPATH!

I'm not a fan of the "safe path" wording. Things can be "safe" or "unsafe" in many ways and the word doesn't give a clear indication of what the precise behavior is.

Would something like "skip_cwd_in_path" work?

It wouldn’t, because as detailed before it’s not always the working dir that’s added.

provide an opt-in way "to be safe".

That's the bit that makes me squirm, though :). It makes things less potentially unsafe, but I can well imagine someone coming along in 5 years with some new contrivance that shows that no, in fact, the path is not completely safe withPYTHONSAFEPATH set.

Maybe make itPYTHONSAFERPATH? That wording is harder to argue against, but also hard to tell apart fromPYTHONSAFEPATH.

I fully recognize that this is just bikeshedding, though. Don't hold this up on quibbles about future maybes :)

Maybe we should consider adding-p option which is the opposite of-P: add the unsafe path.

For example,PYTHONSAFEPATH=1 python -p script.py [...] would ensure that Python still adds the current directory tosys.path to runscript.py. The problem is that when you run a script, you don't know in advance inPYTHONSAFEPATH=1 env var is set or not: it's inherited in the parent process environment or can be set system-wide.

Otherwise,script.py fails onimport foo to loadfoo.py which is in the same directory thanscript.py.

Maybe we should consider adding -p option which is the opposite of -P: add the unsafe path.

For example,PYTHONSAFEPATH=1 python Tools/freeze/freeze.py fails onimport checkextensions withImportError: it is supposed to loadTools/freeze/checkextensions.py. Thefreeze.py script is incompatible with "safe path".

These tools are exceptions; they could add their parent directory to sys.path explicitly.

Maybe we should consider adding-p option which is the opposite of-P: add the unsafe path.

I think that should be left for the future. Lets see if anyone actuallywants it first. If we do go the route of aiming for a default flip in the future it might make sense.

I'm still thinking about changing the default to be safe by default, but "later" and it might require a PEP.

I'd be very much in favor of such a change 🙂

That's the bit that makes me squirm, though :). It makes things less potentially unsafe, but I can well imagine someone coming along in 5 years with some new contrivance that shows that no, in fact, the path is not completely safe with PYTHONSAFEPATH set.

PYTHONSAFEPATH=1 is not safe at all :-) It does exactly one thing: not preprend a path to sys.path[0] which is "potentially" unsafe. It's just that it's really hard to select a short environment name which either summarizes well what the variable does, or explains in length what it does. For example, thePYTHONDONTADDIMPLICTDIRS name was proposed, but ... it's quite long to type :-(

@gpshead:

I think that should be left for the future. Lets see if anyone actually wants it first. If we do go the route of aiming for a default flip in the future it might make sense.

Flipping the default can now be done by settingPYTHONSAFEPATH=1 system wide (or in the current shell).

The problem is that right now, ifPYTHONSAFEPATH=1 is set, it's no longer possible to run programs which rely on the Python 3.10 behavior to load modules in the current directory (as Pythonfreeze.py tool), without having to modify the source code of these programs.

IMO command line options must have the priority over environment variables. Python does not provide command line options to disable the effect of all Python environment variables. For example,PYTHONUNBUFFERED=1 cannot be "undone" by a command line option. But the effect of this variable is limited: I'm not aware of any program broken by it.

The Python UTF-8 Mode is way more likely to cause compatibility issues and so-X utf8=0 can disable iton the command line: ignorePYTHONUTF8=1 env var.

We don't have to add-p, but it makesPYTHONSAFEPATH=1 harder to use. The current workaround is to use-E to ignore environment variables, or-I (isolated mode) but this option has more effects (like not adding user site directories).

I merged my PR, thanks@gpshead for the review.

I'm not fully comfortable of merging this PR in a rush (before the Python 3.11 feature freeze), but IMO the scope of the feature is limited and well defined. It's different than other options discussed previously, especially the idea of changing thedefault behavior to "safe" (not prepend a path to sys.path).

The idea of putting the feature is beta1 is to give users the ability to play with it before Python 3.11 final release, to get feedback, adjust issues, and maybe consider reverting the change if it causes too many issues.

@ofek:

I'd be very much in favor of such a change slightly_smiling_face

As written previously, you can now simply set PYTHONSAFEPATH=1 env var system wide, and Python 3.11 sys.path will be "safer" by default ;-) On Linux, just put it in/etc/environment.

Follow-up change:329afe7 "Fix tests failing with the PYTHONSAFEPATH=1 env var".

I created#92361 to add a new-p option which can be used to opt-in for Python 3.10 sys.path behavior whenPYTHONSAFEPATH=1 is set globally. It can also be used with the-I isolated mode to prepend the unsafe path tosys.path.