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.
On Sat, 18 Dec 2010 20:23:49 -0800
Guido van Rossum gu...@python.org 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
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 *
On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 18 Dec 2010 20:23:49 -0800
Guido van Rossum gu...@python.org 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
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 solip...@pitrou.net wrote:
On Sat, 18 Dec 2010 20:23:49 -0800
Guido van Rossum gu...@python.org wrote:
I may be unique, but I fear there is no great answer. On the one hand
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,
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
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
On Dec 19, 2010, at 10:41 AM, Guido van Rossum wrote:
On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 18 Dec 2010 20:23:49 -0800
Guido van Rossum gu...@python.org wrote:
I may be unique, but I fear there is no great answer. On the one hand
I almost always
On Sun, Dec 19, 2010 at 2:20 PM, Antoine Pitrou solip...@pitrou.net 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
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()
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
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
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),
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
On Sun, 19 Dec 2010 23:37:58 +0100
Victor Stinner victor.stin...@haypocalc.com 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
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
On 12/19/2010 1:41 PM, Guido van Rossum wrote:
On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrousolip...@pitrou.net 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),
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:
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
On Sun, 19 Dec 2010 18:54:55 -0500
Terry Reedy tjre...@udel.edu wrote:
On 12/19/2010 1:41 PM, Guido van Rossum wrote:
On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrousolip...@pitrou.net wrote:
This could be nicely resolved by renaming the arguments a and b,
and having the diff display a,
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()
-
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,
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
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
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
26 matches
Mail list logo
