Michael,
In Python/pystate.c, you made this checkin:
"""
r39044 | mwh | 2005-06-20 12:52:57 -0400 (Mon, 20 Jun 2005) | 8 lines
Fix bug: [ 1163563 ] Sub threads execute in restricted mode
basically by fixing bug 1010677 in a non-broken way.
"""
_PyGILState_NoteThreadState is declared as static
On 11 Sep 2006, at 09:34, Neal Norwitz wrote:
> Michael,
>
> In Python/pystate.c, you made this checkin:
>
> """
> r39044 | mwh | 2005-06-20 12:52:57 -0400 (Mon, 20 Jun 2005) | 8 lines
>
> Fix bug: [ 1163563 ] Sub threads execute in restricted mode
> basically by fixing bug 1010677 in a non-brok
Ok, I haven't heard back from Martin, but I'm going to hope he's OK with
tomorrow as a release date for 2.5rc2. If he's not, we'll try for the day
after. In any case, I'm going to declare the release25-maint branch FROZEN as
at 00:00 UTC on the 12th. That's about 12 hours from now.
This is for
On 9/11/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> Now on to my new proposal. I do still use write(). If you can't
> accept that I think we should rip signals out entirely, just let them
> kill the process. Not a reliable feature of any OS.
>
> We create a single pipe and use it for all signals
[I hope this belongs on python-dev, since it's about the design of
something. But if not, let me know and I'll post to c.l.py.]
I'm willing to file a bug report and patch on this, but I'd like to know
if it's by design or not.
In datetimemodule.c, the function wrap_strftime() insists that the
[Eric V. Smith]
> [I hope this belongs on python-dev, since it's about the design of
> something. But if not, let me know and I'll post to c.l.py.]
>
> I'm willing to file a bug report and patch on this, but I'd like to know
> if it's by design or not.
>
> In datetimemodule.c, the function wrap_st
Please log a bug - this is probably something suitable for fixing in 2.5.1. At
the very least, if it's going to be limited to 127 characters, it should
check that and raise a more suitable exception.
___
Python-Dev mailing list
Python-Dev@python.org
h
On Sun, Sep 10, 2006 at 07:35:59PM +1200, Greg Ewing wrote:
> Barry Warsaw wrote:
> > I just want to point out that the C API documentation is pretty
> > silent about the refcounting side-effects in error conditions (and
> > often in success conditions too) of most Python functions. For
> >
On 9/11/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 9/11/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > This much would allow a GUI's poll loop to wake up when there is a
> > signal, and give control back to the python main loop, which could
> > then read off the signals and queue up their
Mihai Ibanescu wrote:
> Given that it doesn't seem to be the case, and my quick look at the code
> indicates that even internally python is inconsistent, should I file a
> low-severity bug so we don't lose track of this?
I'd say so, yes. A function whose refcount behaviour
differs when it fails i
On 9/11/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Gustavo Carneiro wrote:
> > The only potential problem left is that, by changing the pipe file
> > descriptor to non-blocking mode we can only write as many bytes to it
> > without reading from the other side as the pipe buffer allows. If a
> >
Gustavo Carneiro wrote:
> The only potential problem left is that, by changing the pipe file
> descriptor to non-blocking mode we can only write as many bytes to it
> without reading from the other side as the pipe buffer allows. If a
> large number of signals arrive very quickly, that buffer ma
Adam Olsen wrote:
> That brings you back to how you access the flags variable.
The existing signal handler sets a flag, doesn't it?
So it couldn't be any more broken than the current
implementation.
If we get too paranoid about this, we'll just end
up deciding that signals can't be used for anyt
13 matches
Mail list logo
