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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
