On 2/25/2013 7:11 PM, Larry Hastings wrote:
Following up on a conversation on python-dev from last December:
http://mail.python.org/pipermail/python-dev/2012-December/122920.html
I'm pleased to announced PEP 436, proposing Argument Clinic for adoption
into the CPython source tree.
http://www.python.org/dev/peps/pep-0436/
The PEP gives an internal, developer-focused rationale. I think there is
also an external, user-focused rationale. As much as possible (with
obvious caveats about type introspection), I think it should be
transparent to users (other than speed) whether a function is
implemented in Python or C. People who love keyword calling currently
have to learn which module by module and function by function.
Tranparency will become even more important as more modules are dual
coded, and as users move code between implementations. I presume some of
the complexities of PyArg_ParseTupleAndKeywords arise from pursuing
this goal. And if I understand correctly, this PEP should reduce some of
the complexities. The 'future goal' of C function signature info will
further aid transparency.
This user rationale suggests that positional-only functions should be
discouraged.
It also suggests another future goal: a clinic backend that would
instead output a skeleton python file with def header lines and
docstrings, leaving the bodies to be filled in. One could also wish for
the opposite: a python file processor that would convert def header
lines and docstrings to a skeleton C file with clinic specifications.
> Do we need to support tuple unpacking?
Well, Python 3 dropped that for python functions, so it is not needed
needed for conversions to or from python 3 files. I suspect the same
rationale applies to C as well as Python functions: the unpacking can be
done explicitly in the body, as needed.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
