On 02/26/2013 08:11 AM, Terry Reedy wrote:
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.
I think positional-only functions should be discouraged, but we don't
really need Clinic to do that. I suppose we don't need Clinic to
support signatures for built-in functions either, though Clinic would be
a much bigger help in that department.
So, here's my interpretation of the above suggestion: one user-focused
rationale for Clinic is that it'll make it easier for developers to
write built-ins that behave identically to functions written in Python,
and this benefits users. Do you agree with that?
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.
Well, right now Clinic has no visibility into variables, just
functions. So such a skeleton python file would be a bit incomplete.
That's mildly interesting to consider, though--telling Clinic about
module variables, that is. Another possible use of Clinic is to do
conformance testing for alternative implementations, that is, having
PyPy (for example) make sure that they got their reimplemented standard
library API correct.
//arry/
_______________________________________________
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
