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 aren't special enough to break the rules. I still wish that the beta releases had been deferred until after the Mercurial switchover, but alas, the release manager has decided otherwise - explicitly pointing out that the rationale for releasing beta 1 was to stop accepting new features. The motivation for freezing features before feature releases is not so much that existing applications may be affected by API changes (3.2 will change APIs, anyway, and users fully expect to need some porting), but that the features that are about to be released need some time for testing. This specific feature has seen very little testing. Giving it a full release cycle (i.e. until 3.3) would somewhat reduce the need for a more careful code review. Regards, Martin

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/ The module works on Linux, FreeBSD and Windows with Python 2.6 through 3.2. A third party module can evolve faster outside Python. Victor

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: http://pypi.python.org/pypi/faulthandler/

The module works on Linux, FreeBSD and Windows with Python 2.6 through 3.2.

A third party module can evolve faster outside Python.

I hope you will include it in 3.3 though; it is great functionality. I would really like to see it enabled by default as well. 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 interpreter would be one option for this. Another possibility would be providing a C-API to enable it and have the Python interpreter application call this, so that the functionality remains off by default for embedded interpreters but on for normal uses. All the best, Michael

Victor

_______________________________________________ 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/fuzzyman%40voidspace.org.u...

-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

Le vendredi 24 décembre 2010 à 12:59 +0000, 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 see it enabled by default as well.

For different reasons, it is not a good idea to enable it by default (see the recent discussion on this list).

It seemed from the discussion that the biggest barrier to enabling it by default was possible difficulties when ...

Yes, that's why it was disabled by default in the latest version of my patch.

(multiple interpreters,

I think that my fault handler works with multiple interpreters.

potential conflicts with application signal handling)

Very few programs have an handler for SIGSEGV, SIGFPE, SIGILL or SIGBUS signals (but yes, there are such programs/libraries like RPy or XEmacs).

A public C-API to disable the functionality per interpreter would be one option for this. Another possibility would be providing a C-API to enable it and have the Python interpreter application call this, so that the functionality remains off by default for embedded interpreters but on for normal uses.

I think that it's better to disable it by default, and only enabled by the user or by the developer of a specific application. -- Anyway, you don't have to wait Python 3.3 (or Python 3.2): you can already use faulthandler ;-) I created Windows installer for Python 2.6, 2.7 and 3.1 (I will do it for 2.5 too in the next faulthandler version, faulthandler 1.0 tests don't work with Python 2.5). faulthandler is a module: enable the handler is simple as "import faulthandler". Said differently, it's also disabled by default, and only enabled by the application developer. It's harder to enable it for the user, the site module should maybe be patched to load the module if an environment variable exist or a command line argument. Victor

On 25 Dec, 10:31 pm, merwok@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 using a function to enable the functionality (and add one to disable it).

Enormous +1. Jean-Paul

On Mon, Dec 27, 2010 at 8:57 AM, Victor Stinner wrote:

Le dimanche 26 décembre 2010 à 14:10 +0000, exarkun@twistedmatrix.com a écrit :

...

On 25 Dec, 10:31 pm, merwok@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 using a function to enable the functionality (and add one to disable it).

Enormous +1.

I don't know pkgutil. How does it work? In which case would it load the faulthandler module?

faulthandler is currently only written in C.

pkgutil includes a function that lets you walk the entire module heirarchy, implicitly importing everything, including all the builtin modules. It's one of the reasons doing things as side-effects of import is considered highly undesirable. The pydoc tests do this when they bring the (docstring-based) documentation server up to check its handling of HTTP requests. (we recently picked up an implicit addition of a logging handler by concurrent.futures due to this effect). Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

Le jeudi 23 décembre 2010 à 22:58 +0000, 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 also called.

Doesn't build for me without #ifdef HAVE_UNISTD_H in Python/fault.c

Yes, I wrote a comment about that in the issue. But then I realized that this header is not needed at all.

you missed my comment about raise vs. kill in the other thread which lets the SIGILL test run as well

Oh, I didn't noticed that this change enables sigill() on Windows. Nice :-) I created a third party module from my patch: http://pypi.python.org/pypi/faulthandler/ I commited your patch, thanks. I added you to the authors as a contributor. Victor