Re: [Python-Dev] Need to hook Py_FatalError
On Tue, 2005-05-03 at 12:54 -0500, Jeff Epler wrote: > On Tue, May 03, 2005 at 09:15:42AM -0700, Guido van Rossum wrote: > > But tell me, what do you want the process to do instead of > > terminating? Py_FatalError is used in situations where raising an > > exception is impossible or would do more harm than good. > > In an application which embeds Python, I want to show the application's > standard error dialog, which doesn't call any Python APIs (but does do > things like capture the call stack at the time of the error). For this > use, it doesn't matter that no further calls to those APIs are possible. > > Jeff +1 Here. In my case(postgresql), it would probably be wiser to map Py_Fatal's to Postgres' ereport(FATAL,(...)), as it does appear to do some cleaning up on exit, and if there's a remote user, it could actually give the user the message. [http://python.project.postgresql.org] -- Regards, James William Pye ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need to hook Py_FatalError
On Tue, 2005-05-03 at 13:39 -0700, Josiah Carlson wrote: > If I'm wrong, I'd like to hear it, but I'm still waiting for your patch > on sourceforge. Well, if he lost/loses interest for whatever reason, I'd be willing to provide. Although, if m.u.k. is going to write it, please be sure to include a CPP macro/define, so that embedders could recognize the feature without having to run explicit checks or do version based fingerprinting. (I'd be interested to follow the patch if you(muk) put it up!) Hrm, although, I don't think it would be wise to allow extension modules to set this. IMO, there should be some attempt to protect it; ie, once it's initialized, don't allow reinitialization, as if the embedder is handling it, it should be handled through the duration of the process. So, a static function pointer in pythonrun.c initialized to NULL, a protective setter that will only allow setting if the pointer is NULL, and Py_FatalError calling the pointer if pointer != Py_FatalError. Should [Py_FatalError] fall through if the hook didn't terminate the process to provide some level of warranty that the process will indeed die? Sound good? -- Regards, James William Pye ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need to hook Py_FatalError
On Wed, 2005-05-04 at 09:46 +, M.Utku K. wrote: > The reinit. issue: The old way of returning old callback when a new > callback is set sounds OK. Or better way: there may be an array to hold all > the callbacks, Py_FatalError iterates and call each. Why should reinitialization be allowed at all? Seems to me that this feature should be exclusively reserved for an embedding application to handle the fatal in an application specific way; ie ereport(FATAL,()) in PostgreSQL, which quickly exits after some cleanup. Why should an extension module be allowed to set this, or reset it? -- Regards, James William Pye ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need to hook Py_FatalError
On Wed, 2005-05-04 at 15:29 +, M.Utku K. wrote: > Extension developer may discard or call them at his own will. That's the issue, an extension developer shouldn't be able to discard it, as I, the embedder, do not want my hook to be clobbered. The extension developer doesn't set the context of the application, the embedder does. > What if more than one extension needs it ? Firstly, I don't think it is likely an extension module *by itself* would ever have to initialize something that would *require* some form of cleanup if the app were to fatal out. If it did, I imagine that it would be suspect of poor design, any exceptions likely to be few and far between. Now, that doesn't mean its use during the process might not create some state or side effect where cleanup would be nice. Although, chances are that such cleanup should occur during normal operations, and be handled via a Python exception, something that a fatal is not. -- Regards, James William Pye signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
