[Python-Dev] The Return Of Argument Clinic (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Aug 5 11:55:22 CEST 2013

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 PyErrOccurred() 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

More information about the Python-Dev mailing list