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

Erik Bray erik.m.bray at gmail.com
Mon Jan 6 21:53:58 CET 2014


On Sun, Jan 5, 2014 at 11:21 AM, Larry Hastings <larry at hastings.org> wrote:
> 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.

Hi,

If it goes forward I would be willing to help out with the derby on a
few modules.  I haven't followed the Argument Clinic arguments closely
before now, so I don't know if this question has been addressed.  I
didn't see it mentioned in the docs anywhere, but will the policy be
to *prefer* renaming existing functions to the names generated by
clinic (the "_impl" names) or to override that to keep the existing
names?

I ask because some built-in functions are used internally by other
built-in functions.  I don't know how common this is but, for example,
fileio_read calls fileio_readall.  So if fileio_readall is renamed to
io_FileIO_readall_impl or whatever we need to also go through and fix
any references to fileio_readall.  Should be easy enough, but I wonder
if there are any broader side-effects of this.  Might it be safer for
the first round to keep the existing function names?

Erik


More information about the Python-Dev mailing list