On 5 August 2013 18:48, Larry Hastings <la...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
