Hi,
Added the patch to the patch manager on SF.
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.c
"M.Utku K." <[EMAIL PROTECTED]> wrote in news:Xns964CE11B16061token@
80.91.229.5:
> _Callback(PyFatalError_Func func) )
> is in "pyerrors.h" but implemenatiton is
> is in "Pythonrun.c". Is it OK? Im listening for more.
>
Sorry, just checked decl. will be in "pydebug.h"
___
Hi all,
> strip.
> What if more than one extension needs it ?
> Curently Im doing
>
> callback_type SetCallBack(callback_type newfunc)
>
> This will set the callback to newfunc and return the old one. Extension
> developer may discard or call them at his own will. What do you think?
>
> __
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
On Wed, May 04, 2005 at 03:29:33PM +, M.Utku K. wrote:
> James William Pye <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
> > Why should reinitialization be allowed at all? Seems to me that this
> > feature should be exclusively reserved for an embedding application to
> > handle the f
James William Pye <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> 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_
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
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
Hi,
Josiah Carlson <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
>>> strip
>> IMHO this should be left to hooker(apparerently not right word, but you
>> get the point :) ). If he allocates more mem. or does heavy stuff, that
>> will just fail. Anyway abort() is a failure too. Either a
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
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
"m.u.k" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > Offering any hook for Py_FatalError may not even be enough, as some of
> > those errors are caused by insufficient memory. What if a hook were
> > available, but it couldn't be calle
Hi,
Josiah Carlson <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Offering any hook for Py_FatalError may not even be enough, as some of
> those errors are caused by insufficient memory. What if a hook were
> available, but it couldn't be called because there wasn't enough memory?
>
>
"m.u.k" <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Guido van Rossum <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > Your efforts would be better directed towards fixing the causes of the
> > fatal errors.
> >
> > I see no need to hook Py_FatalError, but since it's open source, you
>
Hi,
Josiah Carlson <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> In looking at the use of Py_FatalError in the Python Sources (it's a 10
> meg tarball that is well worth the download), it looks as though its use
> shows a Fatal error (hence the name). Things like "Inconsistant
> intern
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 wan
Hi,
Guido van Rossum <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Your efforts would be better directed towards fixing the causes of the
> fatal errors.
>
> I see no need to hook Py_FatalError, but since it's open source, you
> are of course free to patch your own copy if your urge is
"m.u.k" <[EMAIL PROTECTED]> wrote:
> Currently Py_FatalError only dumps the error to stderr and calls abort().
> When doing quirky things with the interpreter, it's so annoying that process
> just terminates. Are there any reason why we still dont have a simple
> callback to hook Py_FatalError.
> Currently Py_FatalError only dumps the error to stderr and calls abort().
> When doing quirky things with the interpreter, it's so annoying that process
> just terminates. Are there any reason why we still dont have a simple
> callback to hook Py_FatalError.
>
> PS. If the answer is "because no
Greetings,
Currently Py_FatalError only dumps the error to stderr and calls abort().
When doing quirky things with the interpreter, it's so annoying that process
just terminates. Are there any reason why we still dont have a simple
callback to hook Py_FatalError.
PS. If the answer is "because n
20 matches
Mail list logo
