On Wed, 26 Sep 2018 at 00:33, Barry Warsaw wrote:
>
> On Sep 25, 2018, at 10:18, Antoine Pitrou wrote:
> >
> > Not really. Many are just like "static" (i.e. module-private)
> > functions, except that they need to be shared by two or three different
> > C modules. It's definitely the case for
Barry Warsaw writes:
> I like the idea of an “internals” C API documentation, separate
> from the public API.
FWIW, this worked well for XEmacs ("came for flamewars, stayed for the
internals manual").
Much of the stuff we inherited from GNU only got documented when there
was massive bugginess
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
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, 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.
13 matches
Mail list logo
