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