Tim Peters wrote:
> Package a Python wrapper and see how popular it becomes. Some reasons
> against trying to standardize on fdlibm were explained here:
>
>http://mail.python.org/pipermail/python-list/2005-July/290164.html
Thanks, these are good points. About speed, do you have any good
ben
There are 3 bugs currently listed in PEP 356 as blocking:
http://python.org/sf/1551432 - __unicode__ breaks on exception classes
http://python.org/sf/1550938 - improper exception w/relative import
http://python.org/sf/1541697 - sgmllib regexp bug causes hang
Does anyone wan
Gustavo,
Did you still want this addressed? Anthony and I made some comments
on the bug/patch, but nothing has been updated.
n
--
On 8/15/06, Gustavo Niemeyer <[EMAIL PROTECTED]> wrote:
> > If you have issues, respond ASAP! The release candidate is planned to
> > be cut this Thursday/Friday.
On 8/18/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> I'd like to commit this. It fixes bug 1542051.
>
> Index: Objects/exceptions.c
...
Georg,
Did you still want to fix this? I don't remember anything happening
with it. I don't see where _PyObject_GC_TRACK is called, so I'm not
sure why _Py
On 9/4/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> Now, we've had this API for a long time already (at least 2.5
> years). I'm pretty sure it works well enough on most *nix systems.
> Event if it works 99% of the times, it's way better than *failing*
> *100%* of the times, which is what ha
On 9/4/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> > On Mon, 04 Sep 2006 17:24:56 +0100,
> > David Hopwood <[EMAIL PROTECTED]
> > der.co.uk> wrote:
> > >Jean-Paul Calderone wrote:
> > >> PyGTK would presumably implement its pending call callback b
[Tim Peters]
>> Speaking of which, I saw no feedback on the proposed patch in
>>
>> http://mail.python.org/pipermail/python-dev/2006-August/068502.html
>>
>> so I'll just check that in tomorrow.
[Anthony Baxter]
> This should also be backported to release24-maint and release23-maint. Let me
>
[Andreas Raab]
> I'm curious if there is any interest in the Python community to achieve
> better cross-platform math behavior. A quick test[1] shows a
> non-surprising difference between the platform implementations.
> Question: Is there any interest in changing the behavior to produce
> identical
In GLib we have a child watch notification feature that relies on
the following signal handler:
static void
g_child_watch_signal_handler (int signum)
{
child_watch_count ++;
if (child_watch_init_state == CHILD_WATCH_INITIALIZED_THREADED)
{
write (child_watch_wake_up_pipe[1], "B",
Hi -
I'm curious if there is any interest in the Python community to achieve
better cross-platform math behavior. A quick test[1] shows a
non-surprising difference between the platform implementations.
Question: Is there any interest in changing the behavior to produce
identical results across
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>
> Thanks for expounding. Given that it is basically impossible to do
> anything useful in a signal handler according to the relevant standards
> (does Python's current signal handler even avoid relying on undefined
> behavior?), how would you sugge
On Mon, 04 Sep 2006 18:18:41 +0100, Nick Maclaren <[EMAIL PROTECTED]> wrote:
>Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>> On Mon, 04 Sep 2006 17:24:56 +0100,
>> David Hopwood <[EMAIL PROTECTED]
>> der.co.uk> wrote:
>> >Jean-Paul Calderone wrote:
>> >> PyGTK would presumably implement its pend
Jean-Paul Calderone wrote:
> On Mon, 04 Sep 2006 17:24:56 +0100, David Hopwood <[EMAIL PROTECTED]> wrote:
>
>>Jean-Paul Calderone wrote:
>>
>>>PyGTK would presumably implement its pending call callback by writing a
>>>byte to a pipe which it is also passing to poll().
>>
>>But doing that in a sign
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Mon, 04 Sep 2006 17:24:56 +0100,
> David Hopwood <[EMAIL PROTECTED]
> der.co.uk> wrote:
> >Jean-Paul Calderone wrote:
> >> PyGTK would presumably implement its pending call callback by writing a
> >> byte to a pipe which it is also passing to poll
On Mon, 04 Sep 2006 17:24:56 +0100, David Hopwood <[EMAIL PROTECTED]> wrote:
>Jean-Paul Calderone wrote:
>> PyGTK would presumably implement its pending call callback by writing a
>> byte to a pipe which it is also passing to poll().
>
>But doing that in a signal handler context invokes undefined b
Jean-Paul Calderone wrote:
> PyGTK would presumably implement its pending call callback by writing a
> byte to a pipe which it is also passing to poll().
But doing that in a signal handler context invokes undefined behaviour
according to POSIX.
--
David Hopwood <[EMAIL PROTECTED]>
"Gustavo Carneiro" <[EMAIL PROTECTED]> wrote:
>
> You guys are tough customers to please. I am just trying to solve a
> problem here, not create a new one; you have to believe me.
Oh, I believe you.
Look at it this way. You are trying to resolve the problem that your
farm is littered with clu
Gustavo Carneiro wrote:
> OK, let's review what we know about current python, signals, and threads:
>
> 1. Python launches threads without touching sigprocmask;
> 2. Python installs signal handlers for all signals;
> 3. Signals can be delivered to any thread, let's assume (because
On Mon, 04 Sep 2006 15:05:56 +0100, Nick Maclaren <[EMAIL PROTECTED]> wrote:
>"Gustavo Carneiro" <[EMAIL PROTECTED]> wrote:
>>
>> That's a very good point; I wasn't aware that child processes
>> inherited the signals mask from their parent processes.
>
>That's one of the few places where POSIX does
On Tuesday 05 September 2006 00:52, Gustavo Carneiro wrote:
> 3. Signals can be delivered to any thread, let's assume (because
> of point #1 and not others not mentioned) that we have no control over
> which threads receive which signals, might as well be random for all
> we know;
Note that
On 9/4/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> "Gustavo Carneiro" <[EMAIL PROTECTED]> wrote:
> > I am now thinking of something along these lines:
> > typedef void (*PyPendingCallNotify)(void *user_data);
> > PyAPI_FUNC(void) Py_AddPendingCallNotify(PyPendingCallNotify callback,
> > vo
On Tuesday 05 September 2006 00:05, Nick Maclaren wrote:
> Anthony Baxter isn't exaggerating the problem, despite what you may
> think from his posting.
If the SF bugtracker had a better search interface, you could see why I have
such a bleak view of this area of Python. What's there now *mostly*
Chris McDonough <[EMAIL PROTECTED]> wrote:
>
> Would adding an API for sigprocmask help here?
No. sigprocmask is a large part of the problem.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: [EMAIL PROTECTE
"Gustavo Carneiro" <[EMAIL PROTECTED]> wrote:
>
> That's a very good point; I wasn't aware that child processes
> inherited the signals mask from their parent processes.
That's one of the few places where POSIX does describe what happens.
Well, usually. You really don't want to know what happens
On 9/4/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> "Gustavo Carneiro" <[EMAIL PROTECTED]> writes:
>
> > According to [1], all python needs to do to avoid this problem is
> > block all signals in all but the main thread;
>
> Argh, no: then people who call system() from non-main threads end up
>
"Gustavo Carneiro" <[EMAIL PROTECTED]> writes:
> According to [1], all python needs to do to avoid this problem is
> block all signals in all but the main thread;
Argh, no: then people who call system() from non-main threads end up
running subprocesses with all signals masked, which breaks other
Fredrik Lundh wrote:
>> That error mentioned in that post was in "pythoncore" module.
>> My error is while compiling "pythoncore_pgo" module.
>
> iirc, that's a partially experimental alternative build for playing
> with performance guided optimizations. are you sure you need
> that module ?
O
On Saturday 02 September 2006 22:10, Gustavo Carneiro wrote:
> According to [1], all python needs to do to avoid this problem is
> block all signals in all but the main thread; then we can guarantee
> signal handlers are always called from the main thread, and pygtk
> doesn't need a timeout.
> B
28 matches
Mail list logo
