On Sun, Jan 5, 2014 at 11:21 AM, Larry Hastings <la...@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 _______________________________________________ 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
