[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Jakub Wilk]

Change by Jakub Wilk :


--
nosy: +jwilk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

Nick Coghlan  added the comment:

Over in https://bugs.python.org/issue33053#msg314192, I came up with 
`--basepath ` as another possible spelling (`--no-basepath` would then be 
an option for turning it off.

The main argument *against* that name is that we use "base" to mean something 
different in the `sys` module: "base_prefix" and "base_exec_prefix" refer to 
the info for the parent environment when in a virtual environment.

Another alternative would be "--mainpath", since what we're really overriding 
is the default path entry that's normally derived from the location of 
`__main__`. As an added bonus, we could define "main path" as a glossary entry, 
rather than having to talk about "sys dot path zero" all the time.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

Nick Coghlan  added the comment:

This question recently came up again over in 
https://bugs.python.org/issue33053#msg314040.

With the assorted startup refactorings that were landed for 3.7, it likely 
makes sense to take another run at this for 3.8.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Matthew Woodcraft]

Matthew Woodcraft added the comment:

For the record: the '-I' option (#16499) in Python 3.4 disables sys.path[0] 
initialisation (among other things).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

before or after running site.py?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

Nick Coghlan added the comment:

I'd suggest this would be applied at the same time as when sys.path[0] gets set 
now, but that kind of messy complication is why I decided we really needed to 
step back and start trying to clean up what we already have before we started 
layering yet *more* complications onto the initialisation process.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

Absolutely, Nick.
Perhaps we ought to start gathering a list of real world requirements, i.e. how 
do people run, or want to run, python?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow added the comment:

This proposal only affects the initialization of sys.path[0], and not any of 
the other sys.path entries made by site.py or otherwise.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Kristján Valur Jónsson]

Changes by Kristján Valur Jónsson krist...@ccpgames.com:


--
nosy: +kristjan.jonsson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

Butting in here:
Early on in the startup, a search is made for site.py using automatic 
sys.path settings.  Do the suggestions here propose to override this?  I know 
there is a -s flag, but all these flags start to be confusing.

I have been looking for ways to completely ignore automatic settings for 
sys.path, either from internal heuristics (either build environment or 
installed environment) or PYTHONPATH.
The reason for this is that as a developer in a large project, one that has 
many branches, each with their potentially different version of python compiled 
and with their own libraries, and where a standard python distribution may 
even be installed on the machine as well, we still want to be able to run 
scripts with each branch' own python with relative simplicity with some sort of 
guarantee that we are not inadvertently pulling in modules from other, 
unrelated branches, or god forbid, the installed python.

PEP 405 seemed to go a long way, although it didn't provide a means in the 
pyvenv.cfg to completely override sys.path from the startup.

I wonder if there isn't a synergy here with PEP 405, e.g. would it make sense 
to have a pyvenv.cfg file next to the __main__.py file?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Gregory P. Smith]

Gregory P. Smith added the comment:

I'd also like a command line flag to override PYTHONPATH (which could also be 
used in combination with -E so that you could still set the PYTHONPATH while 
ignoring everything else).  I'll file a separate feature request for that.

--
nosy: +gregory.p.smith

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow ericsnowcurren...@gmail.com added the comment:

Your plan sounds good, Nick.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

Changes by Nick Coghlan ncogh...@gmail.com:


--
assignee: ncoghlan - 

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

Nick Coghlan ncogh...@gmail.com added the comment:

I was tempted to just add this (perhaps as a -X option) but, on reflection, I'm 
going to go with No, not for 3.3.

I want to take a long hard look at the whole sys.path[0] initialisation process 
when I update PEP 395 to account for namespace packages, and it doesn't make 
sense to skip ahead with part of the conclusion. (I may even end up splitting 
that PEP into two pieces)

I'll also look into the embedding API, to see if/how embedding applications can 
fully control sys.path initialisation.

Python has survived without this feature for the last couple of decades, 
there's no need to be hasty in adding it now.

--
assignee:  - ncoghlan
versions: +Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow ericsnowcurren...@gmail.com added the comment:

any chance on this for 3.3?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow ericsnowcurren...@gmail.com added the comment:

here's an updated patch with long options only.  I'm only 95% confident about 
my changes to getopt.c...there's probably a better way to do it.  However, the 
patch stands on its own two feet.

--
Added file: http://bugs.python.org/file25759/issue13475_long_only.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

Nick Coghlan ncogh...@gmail.com added the comment:

FWIW, I now think this should *only* be a long option. Short options are 
precious, and this is an unusual enough use case that I'm not yet sure it 
deserves one.

In particular, we may decide to use -p later for adding directories to 
sys.path, rather than specifically overriding sys.path[0]

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

Nick Coghlan ncogh...@gmail.com added the comment:

FWIW, I now think this should *only* be a long option. Short options are 
precious, and this is an unusual enough use case that I'm not yet sure it 
deserves one.

In particular, we may decide to use -p later for adding directories to 
sys.path, rather than specifically overriding sys.path[0]

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow ericsnowcurren...@gmail.com added the comment:

Long options only would be fine with me.  So --path0 and --nopath0?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow ericsnowcurren...@gmail.com added the comment:

Here's a stab at implementing -p/-P.  There are a couple warnings that I'm not 
sure about and I've undoubtedly missed some detail, but it should be pretty 
close.

--
keywords: +patch
Added file: http://bugs.python.org/file25721/issue13475_1.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Changes by Eric Snow ericsnowcurren...@gmail.com:


Removed file: http://bugs.python.org/file25721/issue13475_1.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Changes by Eric Snow ericsnowcurren...@gmail.com:


Added file: http://bugs.python.org/file25722/issue13475_1.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Changes by Eric Snow ericsnowcurren...@gmail.com:


Removed file: http://bugs.python.org/file25722/issue13475_1.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Changes by Eric Snow ericsnowcurren...@gmail.com:


Added file: http://bugs.python.org/file25723/issue13475_1.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr added the comment:

Before this is assigned a short option form, I would like to ask whether 
anybody but experts will be able to make a proper use of this option. 
(I also don't understand what it adds over PYTHONPATH)

As for the patch, it lacks error checking when calling C API functions.

--
nosy: +pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow ericsnowcurren...@gmail.com added the comment:

 Before this is assigned a short option form, I would like to ask
 whether anybody but experts will be able to make a proper use of this
 option.

Do you mean relative to a long form?  And what would constitute improper use 
for the option?

As Nick noted earlier in this issue, the implicit setting of sys.path[0] is a 
convenience for some cases, and I can appreciate that.  My complaint is that it 
is not an obvious behavior.  Furthermore, in an import system that has 
eliminated implicit relative imports it can lead to confusing behavior.  I 
consider Nick's proposal the best solution given the constraints we have.

If people do not use it, the status quo is unaffected.  If they do use it, they 
will be explicitly affecting sys.path[0].  If they use it without knowing what 
it's for, it will at worst cause imports to happen from unexpected sources (or 
not happen at all).  To me this doesn't seem that different from the way things 
are now when someone doesn't understand about sys.path[0] initialization.

 (I also don't understand what it adds over PYTHONPATH)

It provides an explicit alternative to the default implicit insertion to 
sys.path[0].  If the default behavior were no implicit initialization, then I'd 
agree that PYTHONPATH is sufficient.

 As for the patch, it lacks error checking when calling C API
 functions.

Ah, yes.  Spaced it.  Patch updated (and warnings fixed).

This brings me to ask what the behavior should be when we have errors come back 
from those C API functions?  In the patch I just have it fall back to the 
default sys.path[0] behavior.  However, wouldn't an error indicate a deeper 
problem?  If so, shouldn't Py_FatalError() be called?

--
Added file: http://bugs.python.org/file25730/issue13475_2.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Antoine Pitrou]

Changes by Antoine Pitrou pit...@free.fr:


--
title: Add '-p'/'--path0' command line option to override sys.path - Add 
'-p'/'--path0' command line option to override sys.path[0] initialisation

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

Nick Coghlan ncogh...@gmail.com added the comment:

I realised -P is available for use as the short form of the suppress 
sys.path[0] initialisation option.

So -p would override the calculation of sys.path[0], while -P would switch 
it off completely (similar to the way -S and -E switch off other aspects of 
the normal initialisation process).

Whether or not to provide --path0 and --nopath0 as long form alternatives 
would then be a separate question.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Matthew Woodcraft]

Matthew Woodcraft matt...@woodcraft.me.uk added the comment:

The proposed --nopath0 option is something I've wished I had in the past.

If this is added, it would be good if it could be given a single-letter form 
too, because it's an option that would be useful in #! lines (they don't 
reliably support using more than one command-line argument, and single-letter 
switches can be combined while long-form ones can't).

--
nosy: +mattheww

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

Eric: Actually I posted my comments after reading only Nick’s message, not 
yours, so no worry :)

Nick:
 the just do the right thing aspect is covered by PEP 395.
This is great.  Thanks for clarifying.

 This is an orthogonal proposal that allows power users the ability to 
 override the
 automatic initialisation to handle those cases where it goes wrong.
If I’m understanding correctly, #12934 is one of those issues.  I agree that an 
option would be better than nothing, but 1) it would not help with older 
Pythons 2) it would not help naïve users 3) it would complicate the 
command-line interface of Python.  (Not saying I’m against the idea, just 
listing cons.)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:


--
nosy: +Arfrever

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

Nick Coghlan ncogh...@gmail.com added the comment:

Zbigniew posted a nice summary of some of the issues sys.path[0] 
autoinitialisation can cause to python-dev: 
http://mail.python.org/pipermail/python-dev/2011-November/114668.html

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow ericsnowcurren...@gmail.com added the comment:

The current behavior is an implicit -p ., which causes all sorts of 
hard-to-figure-out problems, most of which PEP 395 is rightly trying to fix.  
I'm suggesting that the next step would be to make --nopath0 the default 
(rendering the flag unnecessary).  Since this changes the status quo, I'll try 
to make the case here that it's worth it.

---

First of all, the current implicit sys.path[0] initialization for scripts has 
been around since forever.  Why would we change it now?  The inspiration is 
three-fold: we _said_ we got rid of implicit relative imports already, PEP 395 
already has made a case for changing the status quo (though not to this 
degree), and a -p flag provides a simple mechanism to get the current 
behavior explicitly.

Like Nick says in PEP 395, PEP 328 eliminated implicit relative imports from 
imported modules. This PEP proposes that the de facto implicit relative imports 
from main modules that are provided by the current initialisation behaviour for 
sys.path[0] also be eliminated.

I'm just saying we should go all the way, and that the -p flag would allow 
that.  As far as I can tell, there are two meaningful use cases for the 
currently implicit sys.path[0]:  When you are first _learning_ Python (not 
actually using it)...  When you are working on a new project...  Let's look at 
both, first relative to the currently implicit -p ., then to the explicit 
site.

1. (current behavior) implicit sys.path[0] initialization

When a beginner is first learning Python, they learn at the interactive prompt 
or by running a single script.  Pretty quickly they learn about writing their 
own modules and using import to load them.

Where do the modules live?  In the CWD from which they are calling the Python 
executable.  The current implicit -p . means they can import their modules 
right there, and not have to learn yet about sys.path.  That's nice since they 
can concentrate their focus.

But later they _will_ run into hard-to-figure-out problems when they start 
relying on what are effectively implicit relative imports.  Or they will run 
into one of the problems that PEP 395 explains, which are likewise 
head-scratchers.  All of this can be pretty frustrating when you still don't 
know about things like the import machinery.

Consider how that beginner uses the implicit sys.path[0] behavior on a project, 
once they have some experience (hopefully I don't misrepresent something Nick 
explained to me).  The src/ directory of the project won't be under sys.path 
yet.  So to quickly test out their script, they change to src/ and run their 
script from there (something PEP 395 rightfully proposes fine-tuning).  They 
conveniently don't have to manually fiddle with sys.path.  That's a pretty neat 
trick.

The problem I have with this is that there's no difference between the sys.path 
workaround for the script and it's expected normal usage.  If you aren't aware 
of what's going on behind-the-scenes, you may end up with some confusing import 
exceptions later on.

2. explicit sys.path[0] initialization

With a -p flag, it's really easy to say -p . and get the previous implicit 
behavior.  Consider the impact on our beginner.  The try to run their script 
that imports modules in their CWD, but end up with an ImportError because we no 
longer have an implicit -p ..

How is this an improvement?  No more mysterious default behavior.  There's only 
one way it will fail and it will fail the same way every time.  They'll learn 
pretty quickly (if not taught already) you have to use the -p flag if you want 
to import modules that aren't in the standard places.  The ImportError 
message, special-cased for imports in __main__, could help in that regard.

aside
As an aside, implicit or explicit --nopath0, the path to the file for the 
failed import can really help in related situations.  Including it as an 
attribute on the ImportError, and especially in the error message, would rock.  
See issue1559549.
/aside

For the src/ use-case, the developer won't be able to rely on the implicit 
behavior anymore.  A simple, explicit -p . fills the gap and makes it clear 
that they are doing something unusual.  On top of that, they can use -p with 
the path to the src/ directory from anywhere and not have to change their 
directory.  All the better if -p takes advantage of the proposals in PEP 395.


In the end, this boils down to opt-in vs. opt-out.  Either you opt-in to the 
sys.path[0] initialization by using -p, or you opt-out of the default implicit 
-p . by passing --nopath0.  It's a case of explicit is better than 
implicit without a clear reason, to me, that the status quo is worth the 
exception anymore in the face of the alternative.

My only concern would be backwards compatibility.  How much do scripts out 
there rely on the implicit sys.path[0] initialization that aren't already 
broken by the removal of implicit relative imports?  I simply 

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

I don’t understand all the issues and it’s too late for me to read all the 
thread, but I hope these comments are helpful:

- If our goal is to help naïve users, then one or two new options wouldn’t help 
(people want to run “python path/to/thing.py” and want it to Just Work™)

- Getting a very helpful error message is second-best to Just Working™

- This probably needs a wider audience, python-ideas or python-dev, and maybe a 
PEP to explain all the issues and all the considered solutions.

--
nosy: +eric.araujo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow ericsnowcurren...@gmail.com added the comment:

First of all, I don't want Nick's proposal in this issue (the -p and --nopath0 
flags) to be misunderstood because of me.  His is a great idea that will make a 
really useful shortcut available and will _not_ change any current behavior.

My (overly) long message is an attempt to justify going with a more drastic 
variation, to which your response applies exclusively.  I stand by what I said, 
but I would be quite happy with the original proposal, to which your response 
does not apply.  :)

Just wanted to make all that clear so I don't get in the way of a good thing.  
:)

Your comments are spot on.  Your concerns are exactly the ones I would need to 
assuage before my alternative would be acceptable.  When I get a chance I'll 
take this to python-ideas.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

Nick Coghlan ncogh...@gmail.com added the comment:

Yeah, sorry Eric (Snow), you're trying to bite off *way* more than is 
reasonable by proposing to removing sys.path[0] auto-initialisation. While it 
has its problems, it's also far too entrenched in people's expections of 
Python's behaviour to consider removing at this late date. The earliest such a 
radical change could likely be considered is Python 4.

Éric (Araujo): the just do the right thing aspect is covered by PEP 395. This 
is an orthogonal proposal that allows power users the ability to override the 
automatic initialisation to handle those cases where it goes wrong.

That said, I may still make this suggestion part of PEP 395 rather than a 
distinct proposal, even though there's no direct dependency (in either 
direction) between this suggestion and the other ideas in that PEP.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow ericsnowcurren...@gmail.com added the comment:

Yeah, the more I think about it, the more I agree it's Python 4 fodder.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

New submission from Nick Coghlan ncogh...@gmail.com:

PEP 395 spends a lot of time discussing ways that the current automatic 
initialisation of sys.path[0] can go wrong, and even the proposed improvements 
in that PEP don't claim to fix the default behaviour for every possible 
scenario (just many of the most common ones).

The unittest module gets around similar problems with test autodiscovery by 
providing an explicit -t (for 'toplevel') command line option.

While '-t' is not available for the main interpreter executable (and nor is 
'-d' for directory), '-p' for path0 is a possibility.

Directory execution (for example) would then be equivalent to:

  python -p dirname dirname/__main__.py

A separate '--nopath0' option could also be provided to explicitly disable path 
initialisation based on the script being executed (see 
http://lists.debian.org/debian-python/2011/11/msg00058.html)

--
messages: 148295
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add '-p'/'--path0' command line option to override sys.path[0] 
initialisation

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Changes by Eric Snow ericsnowcurren...@gmail.com:


--
nosy: +eric.snow

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow ericsnowcurren...@gmail.com added the comment:

+1  Both the -p and --nopath0 would be great additions and a good match for PEP 
395.

So -p . would be equivalent to the current implicit sys.path[0] 
initialization, right?  Would any other effects happen with -p than 
sys.path[0] initialization?  I'll follow up with my one concern (the implicit 
-p .) in a follow-up message.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com