[Python-Dev] Changing Clinic's output

Larry Hastings larry at hastings.org
Wed Jan 8 01:07:50 CET 2014



On 01/07/2014 03:38 PM, Brett Cannon wrote:
> On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings <larry at hastings.org 
> <mailto:larry at hastings.org>> wrote:
>
>     For what it's worth, if we use the "accumulator" approach I
>     propose that the generated code doesn't go at the very end of the
>     file.  Instead, I suggest they should go *near* the end, below the
>     implementations of the module / class methods, but above the
>     methoddef/type structures and the module init function.
>
>
> If it is accumulated in a single location should it just be a single 
> block for everything towards the end? Then forward declarations would 
> go away (you could still have it as a comment to copy-and-paste where 
> you define the implementation) and you can have a single macro for the 
> PyMethodDef values, each class, etc. If you accumulated the 
> PyMethodDef values into a single macro it would help make up for the 
> convenience lost of converting a function by just cutting the old call 
> signature up to the new *_impl() function.

I *think* that would complicate some use cases.  People occasionally 
call these parsing functions from other functions, or spread their 
methoddef / typeobject structures throughout the file rather than 
putting them all at the end.

I'm proposing that the blob of text immediately between the Clinic input 
and the body of the impl contain (newlines added here for clarity):

    static char *parsing_function_doc;

    static PyObject *
    parsing_function(...);

    #define PARSING_FUNCTION_METHODDEF \
         { ... }

    static PyObject *
    parsing_function_impl(...)

Then the "accumulator" would get the text of the docstring and the 
definition of the parsing_function.


On the other hand, if we wanted to take this opportunity to force 
everyone to standardize (all methoddefs and typeobjects go at the end!) 
we could probably make it work with one giant block near the end.

Or I could make it flexible on what went into the accumulator and what 
went into the normal output block, and the default could be 
everything-in-the-accumulator.  Making the common easy and the uncommon 
possible and all that.  Yeah, that seems best.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140107/08762a20/attachment.html>


More information about the Python-Dev mailing list