Author pitrou
Recipients Arfrever, eric.araujo, eric.snow, mattheww, ncoghlan, pitrou
Date 2012-05-26.22:27:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1338071090.3332.27.camel@localhost.localdomain>
In-reply-to <>
> > 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 a replacement of PYTHONPATH or " install" or "
develop", I guess.

> 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.

Agreed. I'm not arguing against the principle.

> > (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.

Ah, indeed, I'd missed that.

> 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.

Well, no, errors should not pass silently. The error should be
propagated. Here, it probably means print the error and abort (or
whatever strategy the rest of the function adopts).

> However, wouldn't an error indicate a deeper problem?  If so,
> shouldn't Py_FatalError() be called?

Py_FatalError() is a low-level exit; it dumps core. PyErr_Print()
followed by a proper exit may be better.
Date User Action Args
2012-05-26 22:27:43pitrousetrecipients: + pitrou, ncoghlan, mattheww, eric.araujo, Arfrever, eric.snow
2012-05-26 22:27:42pitroulinkissue13475 messages
2012-05-26 22:27:42pitroucreate