Re: [Python-Dev] Locale-specific formatting
On Sat, Dec 18, 2010 at 06:21:24PM -0500, Terry Reedy wrote: > On 12/18/2010 10:33 AM, Oleg Broytman wrote: > >> This is quite a known problem, not specific to Python. Locale >> settings are global for a process, and this is one of the thousands >> reasons why locale is considered so horrible. >> ICU is perhaps the only way around the problem. > > This is about the third mention of 'ICU' in the last few weeks, so I > looked it up: International Components for Unicode > http://site.icu-project.org/ > Several libraries (C/C++,Java), including prebuilt binaries for Windows > (and some others). > There is already a Python .cpp wrapper (but no Windows binaries, which > limits usefulness) > http://pyicu.osafoundation.org/ > http://pypi.python.org/pypi/PyICU/1.0.1 A month ago there was a long thread that mentioned ICU many times: http://mail.python.org/pipermail/python-dev/2010-November/106068.html Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Sat, 18 Dec 2010 20:23:49 -0800 Guido van Rossum wrote: > I may be unique, but I fear there is no great answer. On the one hand > I almost always code it as e.g. assertEqual(actual, expected), which > matches my preference for e.g. "if x == 5:" rather than "if 5 == x:". > On the other hand in those assert* functions that show a nice diff of > two lists, when reading such a diff my expectation is that "old, new" > corresponds to "expected, actual". Which then freaks me out until I > realize that I coded it as "actual, expected"... And yet "expected, > actual" still looks weird to me. :-( This could be nicely resolved by renaming the arguments "a" and "b", and having the diff display "a, b". It's quite natural (both the diff ordering and the arguments ordering), and they are consistent with each other. Regards Antoine. ___ 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] r87399 - in python/branches/py3k: Doc/library/http.client.rst Doc/library/urllib.request.rst Lib/http/client.py Lib/test/test_httplib.py Lib/test/test_urllib2.py Lib/urllib/request.py
Hello Senthil,
> +raise TypeError("data should be byte-like object\
Should be "bytes-like".
> +request.add_unredirected_header(
> +'Content-length', '%d' % len(mv) * mv.itemsize)
There is an operator precedence problem here:
>>> "%d" % 4 * 5
'4'
> +"""
> +file_obj = io.StringIO()
> +file_obj.write("Something\nSomething\nSomething\n")
> +
Why is this whole thing commented out? If it wasn't, you would have seen
the test failing.
Thanks
Antoine.
___
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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote: > On Sat, 18 Dec 2010 20:23:49 -0800 > Guido van Rossum wrote: >> I may be unique, but I fear there is no great answer. On the one hand >> I almost always code it as e.g. assertEqual(actual, expected), which >> matches my preference for e.g. "if x == 5:" rather than "if 5 == x:". >> On the other hand in those assert* functions that show a nice diff of >> two lists, when reading such a diff my expectation is that "old, new" >> corresponds to "expected, actual". Which then freaks me out until I >> realize that I coded it as "actual, expected"... And yet "expected, >> actual" still looks weird to me. :-( > > This could be nicely resolved by renaming the arguments "a" and "b", > and having the diff display "a, b". It's quite natural (both the diff > ordering and the arguments ordering), and they are consistent with each > other. So 'a' stands for 'after' and 'b' for 'before', right? :-) -- --Guido van Rossum (python.org/~guido) ___ 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
Le dimanche 19 décembre 2010 à 10:41 -0800, Guido van Rossum a écrit : > On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote: > > On Sat, 18 Dec 2010 20:23:49 -0800 > > Guido van Rossum wrote: > >> I may be unique, but I fear there is no great answer. On the one hand > >> I almost always code it as e.g. assertEqual(actual, expected), which > >> matches my preference for e.g. "if x == 5:" rather than "if 5 == x:". > >> On the other hand in those assert* functions that show a nice diff of > >> two lists, when reading such a diff my expectation is that "old, new" > >> corresponds to "expected, actual". Which then freaks me out until I > >> realize that I coded it as "actual, expected"... And yet "expected, > >> actual" still looks weird to me. :-( > > > > This could be nicely resolved by renaming the arguments "a" and "b", > > and having the diff display "a, b". It's quite natural (both the diff > > ordering and the arguments ordering), and they are consistent with each > > other. > > So 'a' stands for 'after' and 'b' for 'before', right? :-) Ouch. I guess I don't natively think in English. ___ 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] Locale-specific formatting
> I suppose there could be some sort of locale database. A downloadable, > up-to-date copy of the database could be maintained on the Python > website. I think you are quite underestimating the implementation effort. So -0 on your original proposal until such a thing actually exists. Regards, Martin ___ 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
>> This is also what I think. Installing a signal handler is a fairly >> drastic action, and I don't think the code has been sufficiently >> reviewed yet. > > How much more review should it receive? There should be at least one reviewer with an established track record of being interested/knowledgable in the POSIX APIs and cross-platform aspects of it. As I said, any of the Twisted guys would qualify. > Well, Python already does (and also apparently messes with other things > such as FPU state), so that's a separate issue altogether. Not at all. Some signal handlers are more likely to interfere with the the rest of the application than others. Regards, Martin ___ 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Le dimanche 19 décembre 2010 à 19:53 +0100, "Martin v. Löwis" a écrit : > >> This is also what I think. Installing a signal handler is a fairly > >> drastic action, and I don't think the code has been sufficiently > >> reviewed yet. > > > > How much more review should it receive? > > There should be at least one reviewer with an established track record > of being interested/knowledgable in the POSIX APIs and cross-platform > aspects of it. > As I said, any of the Twisted guys would qualify. James Knight already posted in this thread. Is this sufficient to you? I don't think it's reasonable to expect "the Twisted guys" (whoever they are...) to come and review our code, while they struggle with their own bug queue. It would certainly be beneficial for the stdlib to get as much review attention as you are asking for this patch, but it is also totally impractical to expect such a level of attention from a community of volunteers. If we aren't knowledgeable enough to maintain signal handling code, then we should simply remove the signal module from the stdlib (with an appropriate deprecation period, that is) and let interested people maintain it as a third-party module. That would also close some lingering issues in the tracker, and free up some of our time. > > Well, Python already does (and also apparently messes with other things > > such as FPU state), so that's a separate issue altogether. > > Not at all. Some signal handlers are more likely to interfere with the > the rest of the application than others. Can you clarify why you think those signal handlers fall into that description? After all, SIGINT, SIGILL and friends only get triggered in catastrophic conditions. Thanks Antoine. ___ 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Dec 19, 2010, at 10:41 AM, Guido van Rossum wrote: > On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote: >> On Sat, 18 Dec 2010 20:23:49 -0800 >> Guido van Rossum wrote: >>> I may be unique, but I fear there is no great answer. On the one hand >>> I almost always code it as e.g. assertEqual(actual, expected), which >>> matches my preference for e.g. "if x == 5:" rather than "if 5 == x:". >>> On the other hand in those assert* functions that show a nice diff of >>> two lists, when reading such a diff my expectation is that "old, new" >>> corresponds to "expected, actual". Which then freaks me out until I >>> realize that I coded it as "actual, expected"... And yet "expected, >>> actual" still looks weird to me. :-( >> >> This could be nicely resolved by renaming the arguments "a" and "b", >> and having the diff display "a, b". It's quite natural (both the diff >> ordering and the arguments ordering), and they are consistent with each >> other. > > So 'a' stands for 'after' and 'b' for 'before', right? :-) If you go down the a / b path instead of actual/expected, the diffs are straight-forward but some of the other output styles needed to be changed also (replace the messages for "unexpected" and "missing" elements to "things in a but not in b" and "things in b but not in a". Raymond ___ 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
On Sun, Dec 19, 2010 at 2:20 PM, Antoine Pitrou wrote: .. >> There should be at least one reviewer with an established track record >> of being interested/knowledgable in the POSIX APIs and cross-platform >> aspects of it. >> As I said, any of the Twisted guys would qualify. > > James Knight already posted in this thread. Is this sufficient to you? > I cannot speak for Martin of course, but I think we should first see if James Knight's recommendations get incorporated into the patch and whether that will be sufficient for James Knight to speak in favor of applying the patch. ___ 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Le dimanche 19 décembre 2010 à 19:53 +0100, "Martin v. Löwis" a écrit : > There should be at least one reviewer with an established track record > of being interested/knowledgable in the POSIX APIs and cross-platform > aspects of it. Functions used by the fault handler: - write() - PyUnicode_Check() - PyFrame_GetLineNumber() - DebugBreak() (Windows, in debug mode, only) - abort() - (macro) PyUnicode_GET_SIZE() and PyUnicode_AS_UNICODE() - PyUnicode_Check(), PyFrame_Check() - PyFrame_GetLineNumber() - _Py_atomic_load_relaxed() - _PyThreadState_GetFrame() I suppose that all *Py*() functions are POSIX compliants. DebugBreak() is specific to Windows. Only write() and abort() have to be POSIX compliant. According to Linux manual pages: - abort() conforms to SVr4, POSIX.1-2001, 4.3BSD, C89, C99. - write() conforms to SVr4, 4.3BSD, POSIX.1-2001 -- Functions used by the other parts of the patch: - signal() or sigaction()+sigemptyset() - (optional) sigaltstack() - PyMem_Malloc(), PyMem_Free() - Py_GETENV() - (optional) getpid(), kill() (used by the tests) signal() conforms to C89, C99, POSIX.1-2001. So I don't see any function incompatible with POSIX. (Don't read old versions of my patch, read the latest version) -- About the cross-platform question: it looks like SIGFPE fault is not catchable on Windows. I only tried Linux and Windows, but there are a unit test for each signal and we have 60+ buildbots with various platforms. Can't we wait for the buildbot results? > > Well, Python already does (and also apparently messes with other things > > such as FPU state), so that's a separate issue altogether. > > Not at all. Some signal handlers are more likely to interfere with the > the rest of the application than others. Python installs its own SIGINT handler. I think that a SIGINT handler is more intrusive than a SIGSEGV or SIGILL handler. 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/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Le samedi 18 décembre 2010 à 17:23 +0100, Georg Brandl a écrit : > Well, without a closer I assume that for some crashes it's just not > possible anymore for the Python interpreter to even print out the > traceback? The worst case occurs if the frame objects are corrupted, eg. if the filename of a frame is an invalid object (eg. pointer to NULL or to a corrupted unicode object). If the file descriptor 2 is not stderr (eg. if there is no file descriptor 2), the backtrace cannot be printed. Except of these two issues, I think that the fault handler is always able to display the backtrace, even on stack overflow or invalid memory write. -- Older versions of my patch were less reliable: - allocate memory on the heap => only use the stack (only few bytes) - call "complex" Python functions (like UTF-8 codec with backslashreplace error handler) => use a very simple ASCII +backslashreplace implementation and avoid complex functions - use not signal-safe functions like printf => use write() and simple functions to format numbers - may go into an unlimited loop if there is a loop in the frame linked list => limit the loop to MAX_DEPTH (100) iterations 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/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Le samedi 18 décembre 2010 à 13:55 -0500, Alexander Belopolsky a écrit : > I am -1 on the feature as written. I would be -0 if it did not > install signal handlers by default and even better was implemented in > a separate module, not in core. I think that the feature is useless if it is disabled by default. How do you know that you application will crash? The idea is to give informations to the user when an application crashs: the user can use the backtrace or send it to the developer. Segmentation faults are usually not (easilly) reproductible :-( So even if you enable the fault handler, you may not be able to replay the crash. Or even worse, the fault may not occurs at all when you enable the fault handler... (Heisenbugs!) > This feature is similar to the one that is implemented by R and with > R, it was always a problem when R was embedded as a library. Which kind of problem? A conflict with an existing fault handler? > It has always been a welcome feature of Python that its core did > not mess with the application global state. What do mess the application global state? > Before this is approved, I would like to see a discussion of the > consequences for embedded Python I suppose that if a fault occurs outside Python, the fault handler displays an irrevelent or empty Python backtrace. The fault handler is installed by Py_InitializeEx(), and uninstalled by Py_Finalize(). If the program has its own fault handler or doesn't want Python fault handler, it can set PYTHONNOFAULTHANDLER environment variable. Should we add a C function to the Python API to configure (disable) the fault handler? I only know *two* applications catching faults: Mplayer and aMule. I don't think that they embed Python. If they do, I think that these *two* applications can do something special. Since there are only two applications having their own fault handler, I don't think that we should disable the fault handler by default. (System wide fault handler, like Apport on Ubuntu, can be configured system wide by setting the PYTHONNOFAULTHANDLER environment variable) > and particularly for the case when there are multiple interpreters > in the same process. What? Is it a myth or does Python really support multiple interpreters in the same process? How is it possible? Who uses this? _Py_DumpBacktrace() function (of my patch) uses _Py_atomic_load_relaxed(&_PyThreadState_Current) to get the current thread state. I picked up this instruction from PyThreadState_Get(). If it doesn't work, PyThreadState_Get() should be fixed too. 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/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
On 12/18/2010 8:50 AM, James Y Knight wrote: > I think instead of calling abort() to kill the process, you should: > - install the signal handler with SA_NODEFER|SA_RESETHAND (or if > sigaction is not present, explicitly reset the action to SIG_DFL and > unblock first thing upon entering the handler), and then, > - at the end of the handler, kill(getpid(), orig_signal) in order to > abort the process. I concur with this being the correct way to right such a handler. > This has two advantages: 1) the process's exit code will actually > show the correct signal, It's more than an advantage: it's the only correct way to handle a termination signal. > 2) it might let the OS fault handlers work properly > as well -- I'm not sure. If it does, you may want to experiment with > whether having or omitting SA_NODEFER gives a better backtrace (from the > OS mechanism) in that case. Even if that doesn't work, things like the grsecurity patches to linux use these signals to detect exploits and log them and do throttling. Calling abort() effectively converts all of these faults into SIGABRT terminations that are considered (more?) innocent terminations. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Le dimanche 19 décembre 2010 à 20:20 +0100, Antoine Pitrou a écrit : > Can you clarify why you think those signal handlers fall into that > description? After all, SIGINT, SIGILL and friends only get triggered in > catastrophic conditions. SIGSEGV, not SIGINT 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/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
On Sun, 19 Dec 2010 23:37:58 +0100 Victor Stinner wrote: > Le dimanche 19 décembre 2010 à 20:20 +0100, Antoine Pitrou a écrit : > > Can you clarify why you think those signal handlers fall into that > > description? After all, SIGINT, SIGILL and friends only get triggered in > > catastrophic conditions. > > SIGSEGV, not SIGINT Oops, sorry for the mistake. I hope this didn't stir any confusion beyond my own ;) cheers Antoine. ___ 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Le samedi 18 décembre 2010 à 08:50 -0500, James Y Knight a écrit : > I think instead of calling abort() to kill the process, you should: > - install the signal handler with SA_NODEFER|SA_RESETHAND (or if sigaction is > not present, explicitly reset the action to SIG_DFL and unblock first thing > upon entering the handler), and then, > - at the end of the handler, kill(getpid(), orig_signal) in order to abort > the process. I don't think that kill() is available on Windows. We may call directly the previous handler in the new handler, but it is more difficult. It looks like the prototype of a signal handler depends on its options. Or is it possible to always pass (signum, siginfo, ucontext) arguments? I don't know if siginfo and ucontect are portable or not... Another possible approach is to restore the previous handler in the fault handler, and don't call abort(). The fault should occur again, and so the previous signal handler will be called. I choosed to not call the previous handler to keep the patch simple. If you consider that we must call the previous handler, I can work on a new patch doing that. > This has two advantages: 1) the process's exit code will actually show the > correct signal Oh, I didn't noticed that the exit code is different. > 2) it might let the OS fault handlers work properly as well -- I'm not sure. > If it does, you may want to experiment with whether having or omitting > SA_NODEFER gives a better backtrace (from the OS mechanism) in that case. For the OS fault handler: we should try, I am not sure that calling another signal handler (my fault handler) keeps the process state unchanged (especially if sigaltstk() is not available). I don't understand the SA_NODEFER option. What does it change for this fault handler? > If #2 actually works, you may not even need the env var, which would be nice. I prefer to keep it optional because we don't know yet how it interacts exactly with existing debug tools, OS tools, embedded Python interpreters, etc. 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/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 12/19/2010 1:41 PM, Guido van Rossum wrote: On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote: This could be nicely resolved by renaming the arguments "a" and "b", and having the diff display "a, b". It's quite natural (both the diff ordering and the arguments ordering), and they are consistent with each other. So 'a' stands for 'after' and 'b' for 'before', right? :-) difflib uses 'a' and 'b' for before and after (orig,new in svn terms, with edits/diffs from a to b) respectively. Not really great. The docs then have to explain what 'a' and 'b' are and the implications for interpreting the output. -- Terry Jan Reedy ___ 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] Locale-specific formatting
Le 18/12/2010 16:33, Oleg Broytman a écrit : >This is quite a known problem, not specific to Python. Locale > settings are global for a process, and this is one of the thousands > reasons why locale is considered so horrible. >ICU is perhaps the only way around the problem. Babel rocks: http://babel.edgewall.org/ Cheers ___ 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Le lundi 20 décembre 2010 à 00:02 +0100, Victor Stinner a écrit : > Another possible approach is to restore the previous handler in the > fault handler, and don't call abort(). The fault should occur again, and > so the previous signal handler will be called. I implemented this simple approach in the version 10 of my patch: the previous signal handler is called. http://bugs.python.org/issue8863#msg124373 On my Debian Sid, the libc fatal error message is written as expected (eg. "Segmentation fault") and the exit code is different for each fault (eg. 132 for SIGILL). So we keep the existing behaviour, the new Python fault handler just write more information if a fault occurs. I suppose that it is compatible with the grsecurity thing and Apport, but I didn't tried. Can someone test it? I prefer to restore the previous signal handler than restoring the *default* signal handler. > I choosed to not call the previous handler to keep the patch simple. It's cool: restoring the signal approach keeps the code simple, and it looks like it works :-) 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/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Sun, 19 Dec 2010 18:54:55 -0500 Terry Reedy wrote: > On 12/19/2010 1:41 PM, Guido van Rossum wrote: > > On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote: > > >> This could be nicely resolved by renaming the arguments "a" and "b", > >> and having the diff display "a, b". It's quite natural (both the diff > >> ordering and the arguments ordering), and they are consistent with each > >> other. > > > > So 'a' stands for 'after' and 'b' for 'before', right? :-) > > difflib uses 'a' and 'b' for before and after (orig,new in svn terms, > with edits/diffs from a to b) respectively. Not really great. For a non-native English speaker, 'a' and 'b' don't evoke 'after' and 'before' but simply the first two letters of the latin alphabet, and their ordering is therefore obvious with respect to function arguments. By the way, hg uses a/b as well, and so does git apparently, so Python's difflib is not exotic in that regard: $ hg diff diff -r 56867877575b README --- a/READMEFri Dec 17 21:43:27 2010 +0100 +++ b/READMEMon Dec 20 01:42:57 2010 +0100 @@ -1,3 +1,4 @@ +some change This is Python version 3.2 beta 1 = Regards Antoine. ___ 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
> Functions used by the fault handler: > - write() > - PyUnicode_Check() > - PyFrame_GetLineNumber() > - DebugBreak() (Windows, in debug mode, only) > - abort() > - (macro) PyUnicode_GET_SIZE() and PyUnicode_AS_UNICODE() > - PyUnicode_Check(), PyFrame_Check() > - PyFrame_GetLineNumber() > - _Py_atomic_load_relaxed() > - _PyThreadState_GetFrame() > > I suppose that all *Py*() functions are POSIX compliants. The problem is that merely being POSIX compliant would not be enough to allow calling a function in a signal handler. Instead, the function *also* needs to be async-signal safe. However, > - abort() conforms to SVr4, POSIX.1-2001, 4.3BSD, C89, C99. > - write() conforms to SVr4, 4.3BSD, POSIX.1-2001 These two functions are indeed async-signal safe. So assuming that none of the functions above indirectly calls a non-async-signal-safe function, this part is fine. Looking at your function list, my other concern is that you are calling Python API without holding the GIL, IIUC. In particular, you are accessing _PyThreadState_Current, which may not point to the current thread if the current thread has released the GIL. Regards, Martin ___ 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
> What? Is it a myth or does Python really support multiple interpreters > in the same process? How is it possible? Who uses this? [Not sure if you are joking] There is certainly some support for multiple interpreters in Python; the most prominent user of this feature is mod_python. Regards, Martin ___ 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
On 19/12/2010 23:02, Victor Stinner wrote: Le samedi 18 décembre 2010 à 08:50 -0500, James Y Knight a écrit : I think instead of calling abort() to kill the process, you should: - install the signal handler with SA_NODEFER|SA_RESETHAND (or if sigaction is not present, explicitly reset the action to SIG_DFL and unblock first thing upon entering the handler), and then, - at the end of the handler, kill(getpid(), orig_signal) in order to abort the process. I don't think that kill() is available on Windows. Thanks to Brian Curtin there is now an os.kill() on Windows, but it doesn't handle the full range of signals. Michael -- 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 ___ 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Le lundi 20 décembre 2010 à 02:05 +0100, "Martin v. Löwis" a écrit : > The problem is that merely being POSIX compliant would not be enough > to allow calling a function in a signal handler. Instead, the function > *also* needs to be async-signal safe. Yes, this issue was fixed in an older version of my patch. Starting at version 9, the signal handler only call signal-safe functions. > Looking at your function list, my other concern is that you are calling > Python API without holding the GIL, IIUC. In particular, you are > accessing _PyThreadState_Current, which may not point to the current > thread if the current thread has released the GIL. Ah? Where does _PyThreadState_Current point to if the GIL is not hold when the fault handler is called? My patch changes also Py_FatalError() to display the Python backtrace. It looks that _PyThreadState_Current can be NULL if the GIL is released. In this case, _Py_DumpBacktrace() just do nothing. There is also a gil_last_holder variable: can it be used to get the thread state (especially if the thread state was deleted)? I don't think that it will possible the acquire the GIL in Py_FatalError() or in the fault handler. 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/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
>> Looking at your function list, my other concern is that you are calling >> Python API without holding the GIL, IIUC. In particular, you are >> accessing _PyThreadState_Current, which may not point to the current >> thread if the current thread has released the GIL. > > Ah? Where does _PyThreadState_Current point to if the GIL is not hold > when the fault handler is called? The GIL is likely held by a different thread, then. _PyThreadState_Current will point to the state of this other thread. > It looks that _PyThreadState_Current can be NULL if the GIL is released. > In this case, _Py_DumpBacktrace() just do nothing. There is also a > gil_last_holder variable: can it be used to get the thread state > (especially if the thread state was deleted)? Of this thread? I don't think so. gil_last_holder might also refer to a different thread. > I don't think that it will possible the acquire the GIL in > Py_FatalError() or in the fault handler. I agree. Regards, Martin ___ 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
