Sorry for mailing about a bug instead of putting in a bug tracker
ticket. The bug tracker's login system just sits there for a minute
then says "an error has occurred".
This line of code is broken in Windows:
https://github.com/python/cpython/blob/v2.7.15/Objects/fileobject.c#L721
_lseeki64
On Tue, Sep 25, 2018 at 3:27 PM Barry Warsaw wrote:
>
> On Sep 25, 2018, at 12:09, Yury Selivanov wrote:
> >
> > My main concern with maintaining a *separate* documentation of
> > internals is that it would make it harder to keep it in sync with the
> > actual implementation. We often struggle
On Sep 25, 2018, at 12:09, Yury Selivanov wrote:
>
> My main concern with maintaining a *separate* documentation of
> internals is that it would make it harder to keep it in sync with the
> actual implementation. We often struggle to keep the comments in the
> code in sync with that code.
On Tue, Sep 25, 2018 at 11:55 AM Barry Warsaw wrote:
>
> On Sep 25, 2018, at 11:28, Victor Stinner wrote:
> >
> > But if we have a separated documented for CPython internals, why not
> > documenting private functions. At least, I would prefer to not put it
> > at the same place an the *public* C
On Tue, Sep 25, 2018 at 8:55 AM Barry Warsaw wrote:
> On Sep 25, 2018, at 11:28, Victor Stinner wrote:
> >
> > But if we have a separated documented for CPython internals, why not
> > documenting private functions. At least, I would prefer to not put it
> > at the same place an the *public* C
On Sep 25, 2018, at 11:28, Victor Stinner wrote:
>
> But if we have a separated documented for CPython internals, why not
> documenting private functions. At least, I would prefer to not put it
> at the same place an the *public* C API. (At least, a different
> directory.)
I like the idea of an
On Tue, Sep 25, 2018 at 9:30 AM Gregory P. Smith wrote:
> We can't change the API of the main thread being where signal handlers are
> executed by default.
>
> If a signal handler raised an exception in a daemon thread, the process would
> not die when it goes uncaught (ie: why KeyboardInterrupt
On Mon, Sep 24, 2018 at 1:20 PM Eric Snow
wrote:
> On Mon, Sep 24, 2018 at 11:14 AM Yury Selivanov
> wrote:
> > On Fri, Sep 21, 2018 at 7:04 PM Eric Snow
> wrote:
> > > 1. Why do we restrict calls to signal.signal() to the main thread?
> > > 2. Why must signal handlers run in the main thread?
Nobody should use _PyEval_SignalReceived(). It should only be used the
the C signal handler.
But if we have a separated documented for CPython internals, why not
documenting private functions. At least, I would prefer to not put it
at the same place an the *public* C API. (At least, a different
On Tue, Sep 25, 2018 at 9:16 AM Yury Selivanov wrote:
> We already have a mechanism for private header files: the
> "Include/internal/" directory. I think it should be mandatory to
> always put private C API-like functions/structs there.
+1
This is the main reason I created that directory.
On Tue, 25 Sep 2018 09:09:26 -0600
Eric Snow wrote:
> On Tue, Sep 25, 2018 at 1:45 AM Victor Stinner wrote:
> > Please don't rely on this ugly API. *By design*, Py_AddPendingCall()
> > tries 100 times to acquire the lock: if it fails to acquire the lock,
> > it does notthing... your callback is
On Tue, Sep 25, 2018 at 8:30 AM Barry Warsaw wrote:
> On Sep 25, 2018, at 10:18, Antoine Pitrou wrote:
> > Putting them in the C API documentation risks making the docs harder to
> > browse through for third-party users. I think it's enough if there's a
> > comment in the .h file explaining the
On Tue, 25 Sep 2018 10:01:56 -0400
Barry Warsaw wrote:
> On Sep 25, 2018, at 03:44, Victor Stinner wrote:
>
> > By the way, recently, we had to fix yet another bug in signal
> > handling. A new function has been added:
> >
> > void
> > _PyEval_SignalReceived(void)
> > {
> >/* bpo-30703:
On 2018-09-25 16:01, Barry Warsaw wrote:
Maybe this is better off discussed in doc-sig but I think we need to consider
documenting the private C API.
Even the *public* C API is not fully documented. For example, none of
the PyCFunction_... functions appears in the documentation.
On Sep 25, 2018, at 03:44, Victor Stinner wrote:
> By the way, recently, we had to fix yet another bug in signal
> handling. A new function has been added:
>
> void
> _PyEval_SignalReceived(void)
> {
>/* bpo-30703: Function called when the C signal handler of Python gets a
> signal.
Please don't rely on this ugly API. *By design*, Py_AddPendingCall()
tries 100 times to acquire the lock: if it fails to acquire the lock,
it does notthing... your callback is ignored...
By the way, recently, we had to fix yet another bug in signal
handling. A new function has been added:
void
16 matches
Mail list logo
