homepage

> > 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?
Yes.
> And what would constitute improper use for the option?
As a replacement of PYTHONPATH or "setup.py install" or "setup.py
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.