On 2/26/2013 1:47 PM, Larry Hastings wrote:
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
If I were writing something like Clinic, I would be tempted to not have
that option. But I was actually thinking about something in the
positional-only writeup that mentioned the possibility of adding
something to the positional-only option.
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?
yes, especially with signatures.
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.
Module variables are option few enough to copy by hand. Methods are more
of a problem. As I understand it, C module files are structured
something like the following, which is 'unusual' for a python file.
def meth1_impl(...
def meth2_impl(...
class C:
meth1 = meth1_impl
meth2 = meth2_impl
So producing an idiomatic skeleton would require more that an alternate
backend. Rather function entries should be stored and not output until
the structure (class) definition is encountered. Two passes would be a
lot easier than one.
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/
--
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
