On Mon, Dec 27, 2010 at 8:57 AM, Victor Stinner
wrote:
> Le dimanche 26 décembre 2010 à 14:10 +, exar...@twistedmatrix.com a
> écrit :
>> On 25 Dec, 10:31 pm, mer...@netwok.org wrote:
>> >>faulthandler is a module: enable the handler is simple as "import
>> >>faulthandler".
>> >
>> >That sound
Le dimanche 26 décembre 2010 à 14:10 +, exar...@twistedmatrix.com a
écrit :
> On 25 Dec, 10:31 pm, mer...@netwok.org wrote:
> >>faulthandler is a module: enable the handler is simple as "import
> >>faulthandler".
> >
> >That sounds like a source of unwanted behavior (aka problems) if the
> >han
On 25 Dec, 10:31 pm, mer...@netwok.org wrote:
faulthandler is a module: enable the handler is simple as "import
faulthandler".
That sounds like a source of unwanted behavior (aka problems) if the
handler is enabled by 1Cpydoc faulthandler 1D or by a pkgutil walk. You
may want to consider usin
> faulthandler is a module: enable the handler is simple as "import
> faulthandler".
That sounds like a source of unwanted behavior (aka problems) if the
handler is enabled by “pydoc faulthandler” or by a pkgutil walk. You
may want to consider using a function to enable the functionality (and
add
Le vendredi 24 décembre 2010 à 12:59 +, Michael Foord a écrit :
> I hope you will include it in 3.3 though; it is great functionality.
I don't know, Python 3.3 is not planned yet. Anyway, faulthandler is
already available and you can use it on Python 2.5 through 3.2.
> I would really like to
Michael Foord writes:
> It seemed from the discussion that the biggest barrier to enabling it by
> default was possible difficulties when embedding Python (multiple
> interpreters, potential conflicts with application signal handling). A
> public C-API to disable the functionality per inter
On 24/12/2010 02:21, Victor Stinner wrote:
Le jeudi 23 décembre 2010 à 21:59 +0100, Georg Brandl a écrit :
this thread showed that it is not at all obvious how the feature should look
like
Ok, I understand. I closed #8863 (rejected) and I created a third party
module on the Python cheese shop:
Am 24.12.2010 03:21, schrieb Victor Stinner:
> Le jeudi 23 décembre 2010 à 21:59 +0100, Georg Brandl a écrit :
>> this thread showed that it is not at all obvious how the feature should look
>> like
>
> Ok, I understand. I closed #8863 (rejected) and I created a third party
> module on the Python
Le jeudi 23 décembre 2010 à 22:58 +, Martin (gzlist) a écrit :
> On 23/12/2010, Victor Stinner wrote:
> >
> > I tested my patch on Windows (XP), Ubuntu (10.4) and FreeBSD (8) and it
> > works correctly: all tests pass and the system fault handler (Windows
> > popup, Apport and core dump) is al
Le jeudi 23 décembre 2010 à 21:59 +0100, Georg Brandl a écrit :
> this thread showed that it is not at all obvious how the feature should look
> like
Ok, I understand. I closed #8863 (rejected) and I created a third party
module on the Python cheese shop:
http://pypi.python.org/pypi/faulthandler/
On 23/12/2010, Victor Stinner wrote:
>
> I tested my patch on Windows (XP), Ubuntu (10.4) and FreeBSD (8) and it
> works correctly: all tests pass and the system fault handler (Windows
> popup, Apport and core dump) is also called.
Doesn't build for me without #ifdef HAVE_UNISTD_H in Python/fault
Am 23.12.2010 19:23, schrieb "Martin v. Löwis":
>> The fault handler is disabled by default and it is clearly separated
>> (eg. it doesn't touch the API of a module). Can't you make an exception
>> for this new feature?
>
> Ultimately, it's for the release manager to decide, so I don't need to
> m
> The fault handler is disabled by default and it is clearly separated
> (eg. it doesn't touch the API of a module). Can't you make an exception
> for this new feature?
Ultimately, it's for the release manager to decide, so I don't need to
make an exception. However, I think that special cases are
Le jeudi 23 décembre 2010 à 03:37 +0100, "Martin v. Löwis" a écrit :
> > So, do you agree with the fault handler? Does someone want to give a
> > last review because I commit it?
>
> It's a new feature, so regardless of whether it's correct or not
> (which I haven't reviewed yet), I don't think it
> So, do you agree with the fault handler? Does someone want to give a
> last review because I commit it?
It's a new feature, so regardless of whether it's correct or not
(which I haven't reviewed yet), I don't think it should go in before
3.2 is released.
Regards,
Martin
Hi,
Thanks to all your useful remarks, I improved my patch twice (version 10
and 11). I think that the last version (11) addresses all reported
issues. The most notable change is that the fault handler is now
disabled by default. It fixes also the function getting the thread
state, it now works in
16 matches
Mail list logo