This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Jurko.Gospodnetić, brian.curtin, lemburg, pitrou, tim.golden, tim.peters, vstinner
Date 2013-12-16.09:32:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <52AEC8AB.3070908@egenix.com>
In-reply-to <CAMpsgwas3_KqnPQ+XB3U=w7vw3CZ59r0GDHqEmv=bVNPN=+xTg@mail.gmail.com>
Content
On 16.12.2013 10:30, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
> 2013/12/16 Marc-Andre Lemburg <report@bugs.python.org>:
>> I don't think changing Py_FatalError() is a good idea. However,
>> its use in this particular case (streams not initializing) appears
>> wrong.
>>
>> Python should simply exit with an error code in such a case; which then
>> also allows the calling script or application to react to the error.
> 
> Before exiting, you need a message. If there is also an exception, you
> may want to display it. If there is no exception, you may want to
> display the Python traceback. All these tasks are already implemented
> in Py_FatalError.
> 
> If the defaullt behaviour of Py_FatalError() cannot be modified, a new
> function should be be added, a function sharing its code with
> Py_FatalError().
> 
> Example: a new private function "void initerror(const char *message)"
> only used during Py_Initialize().

Sounds reasonable.

BTW: Why can't we make this an official API function, e.g.
Py_Terminate() ?
History
Date User Action Args
2013-12-16 09:32:30lemburgsetrecipients: + lemburg, tim.peters, pitrou, vstinner, tim.golden, brian.curtin, Jurko.Gospodnetić
2013-12-16 09:32:30lemburglinkissue19983 messages
2013-12-16 09:32:30lemburgcreate