[Python-Dev] Proposed: The Great Argument Clinic Conversion Derby

Larry Hastings larry at hastings.org
Sun Jan 5 17:21:12 CET 2014



Let me start with a summary of the current status of Argument Clinic.  
It's checked in, it seems to be working fine.  As of Friday I've checked 
in some reasonably complete documentation as a howto:

    http://docs.python.org/3.4/howto/clinic.html

At last, here in beta 2, Argument Clinic is ready for prime time.

What about adoption?  That's where Argument Clinic has stalled.  By my 
estimate, there are about six hundred places that could be converted to 
work with Argument Clinic in CPython; as of this writing only a dozen or 
two have actually been converted.


Now, properly converting a function to work with Argument Clinic does 
not change its behavior.  Internally, the code performing argument 
parsing should be nigh-identical; it should call the same PyArg_Parse 
function, with the same arguments, and the implementation should perform 
the same work as a result.  The only externally observable change should 
be that inspect.signature() now produces a valid signature for the 
builtin; in all other respects Python should be unchanged.  No 
documentation should have to change, no tests should need to be 
modified, and absolutely no code should be broken as a result.  
Converting a function to use Argument Clinic should be a blissfully 
low-risk procedure, and produce a pleasant, easier-to-maintain result.


You see where I'm going with this.  I am now, reluctantly, proposing 
that once 3.4.0b2 ships (should be later today), we the Python core 
development community roll up our collective sleeves and attempt to 
convert all the builtins to work with Argument Clinic.  I call this "The 
Great Argument Clinic Conversion Derby".

The rules of the derby:

  * The derby stops when RC 1 gets tagged, which should be January 18th.
  * I'll create issues on the issue tracker for converting each C file.
  * Participants will take ownership of an issue for a particular file,
    and have a couple of days to submit a patch.  If an issue languishes
    I reserve the right to reassign it.
  * I pledge to be highly available and responsive during the derby.
  * I volunteer to convert posixmodule.c, which is about 60 functions
    (and therefore 10% of the workload).
  * I volunteer to review patches until my eyes bleed.  I'd prefer to
    review every single conversion, though it's possible that isn't
    feasible, not sure.  (Though I will have a /lot/ of time I can
    devote to this.)
  * I'll create a leader board where contributors are ranked by how many
    functions they've converted, if people want it, in an endeavor to
    spark interest and provide some bragging rights.



Upsides:

  * Every builtins we convert is one more builtin with introspection
    information. It'd be nice to have that in 3.4.
  * Easier maintenance going forward.

Downsides:

  * Someone could improperly convert a function, which could change the
    builtin's semantics and break code, and nobody notices and we ship
    the breakage in 3.4.0 final.



I've discussed this with a number of other core developers; so far I've 
only gotten positive responses.  Otherwise I wouldn't propose such 
madness.  (Making changes to 600 different places in the Python tree?  
What am I thinking?)  Keep in mind, this isn't "now or never"; the 
choice is between "convert now for 3.4" and "wait until after 3.4 final, 
then convert everything, and it'll ship in 3.5". We'll have this sooner 
or later--the question is, sooner? or later?

What say you?  +1?  -1e100?

Anxiously yours,


/arry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140105/1438d74f/attachment.html>


More information about the Python-Dev mailing list