[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