Hi, James William Pye <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
> 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? I haven't lost interest, I expect to publish at most in a couple of days at SourceForge. 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. M. Utku Karatas Best regards. _______________________________________________ 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
