[Python-Dev] The Return Of Argument Clinic

[Nick Coghlan]

On 5 August 2013 18:48, Larry Hastings <larry at hastings.org> wrote:
> Question 0: How should we integrate Clinic into the build process?
>
> Clinic presents a catch-22: you want it as part of the build process,
> but it needs Python to be built before it'll run.  Currently it
> requires Python 3.3 or newer; it might work in 3.2, I've never
> tried it.
>
> We can't depend on Python 3 being available when we build.
> This complicates the build process somewhat.  I imagine it's a
> solvable problem on UNIX... with the right wizardry.  I have no
> idea how one'd approach it on Windows, but obviously we need to
> solve the problem there too.

Isn't solving the bootstrapping problem the reason for checking in the
clinic-generated output? If there's no Python available, we build what
we have (without the clinic step), then we build it again *with* the
clinic step.

> ___________________________________________________________________
> Question 1: Which C function nomenclature?

> Anyone have a strong opinion one way or the other?  I don't much
> care; all I can say is that the "obvious" way to do it when I
> started was to add "_impl" to the impl, as it is the new creature
> under the sun.

Consider this from the client side, and I believe it answers itself:
other code in the module will be expected the existing signature, so
that signature needs to stay with the existing name, while the new C
implementation function gets the new name.

> ___________________________________________________________________
> Question 2: Emit code for modules and classes?
>
> There are some complications to this, one of which I'll
> discuss next.  But I put it to you, gentle reader: how
> much boilerplate should Argument Clinic undertake to
> generate, and how much more class and module metadata
> should be wired in to it?

I strongly recommend deferring this. Incremental development is good,
and getting this bootstrapped at all is going to be challenging enough
without trying to do everything at once.

> ___________________________________________________________________
> Question 3: #ifdef support for functions?
>
>
> Do you agree that Argument Clinic should generate this
> information, and it should use the approach in 3) ?

I think you should postpone anything related to modules and classes
until the basic function support is in and working.

> ___________________________________________________________________
> Question 4: Return converters returning success/failure?
>
> Can we live with PyErr_Occurred() here?

Armin's suggestion of a valid return value (say, -1) that indicates
"error may have occurred" sounds good to me.

> ___________________________________________________________________
> Question 5: Keep too-magical class decorator Converter.wrap?
>
> I'd like to keep it in, and anoint it as the preferred way
> of declaring Converter subclasses.  Anybody else have a strong
> opinion on this either way?

Can't you get the same effect without the magic by having a separate
"custom_init" method that the main __init__ method promises to call
with the extra keyword args after finishing the other parts of the
initialization? Them a custom converter would just look like:

    class path_t_converter(Converter):
        def custom_init(self, *, allow_fd=False, nullable=False):
            ...

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia