[Patches] getpath patch (repost)

[M.-A. Lemburg]

"Fred L. Drake" wrote:
> 
> On Tue, 23 May 2000, M.-A. Lemburg wrote:
>  > The fatal error produces the core dump... so its not all
>  > that bad ;-)
> 
>   Sigh.  Perhaps we need a non-coring Py_FatalErrorXXX()? 

Hmm, the core dump is caused by abort() -- I don't think
we can change that behaviour since it is defined by the
C lib and using exit() is not an option since that would
cause atexit() hooks to be called.

> I don't think a
> core dump is justifiable or desirable for something better explained on
> stderr.  This is *not* a condition that occurs after user code begins
> execution, and should be treated differently.  If I pass a bad command
> line parameter, I get a useful message, no core file, and a meaningful
> result code.  I don't see a reason not to do differently here; the error
> comes from a different source (bad installation rather than a user error),
> but the user needs to be able to scream and shout to the sysadmin, *not*
> clean up core dumps.

True, but see above...
 
>  > It could be solved by adding an exceptions.py fall-back builtin
>  > solution to the interpreter. Fredrik had a pointer for something
>  > like this... perhaps the two patches should go in together ?!
> 
>   Perhaps; but in that case, why use the external module?  Unless this is
> the "partially frozen" interpreter we've talked about here a few times?

URL: http://w1.132.telia.com/~u13208596/exceptions.htm

This is not a frozen module -- it's a reimplementation of
exceptions.py in C (and one which is pretty easy to maintain,
IMHO).

Python could use this small builtin module as fall-back
solution in case exceptions.py is not found (instead of
causing a fatal error).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/