On Tue, Feb 26, 2013 at 12:30 AM, Stefan Krah wrote:

Larry Hastings wrote:

...

http://bugs.python.org/issue16612

I'm guessing python-dev is the right place for the ten-thousand-foot view topics: the merits of the specific proposed DSL syntax, the possible

...

extension API, and the approach as a whole. So for now let's just use

runtime the bug

...

tracker issue for code reviews and the like.

For anyone who isn't following the issue: A PEP proposing a different DSL will be forthcoming either this or next weekend.

If the two proposals share at least the motivation, would it not be more constructive to just have them listed as alternatives in a single PEP? This could serve as a useful single source of information for the new proposed features. Eli

On Wed, Feb 27, 2013 at 12:40 AM, Stefan Krah wrote:

Eli Bendersky wrote:

...

For anyone who isn't following the issue: A PEP proposing a different DSL will be forthcoming either this or next weekend.

If the two proposals share at least the motivation, would it not be more constructive to just have them listed as alternatives in a single PEP? This could serve as a useful single source of information for the new proposed features.

I find PEPs that propose multiple alternatives hard to read. My PEP won't be short: It will contain a token specifications, a yacc grammar and an attempt to specify the semantics of the DSL.

More importantly, the competing PEPs have different champions, so you and Larry need to be free to make the best case you can. Cheers, Nick. P.S. I was thinking the last time we had truly competing PEPs was way back when the with statement was designed, but it turns out the competing namespace package designs were also separate PEPs. PEP 315 was more an after the fact here's-a-better-way-to-implement-this redesign of PEP 309, and PEP 3150 vs 403 is just me having an ongoing discussion with myself (and occasionally others) over a feature I doubt would ever make it past Guido even if I do eventually decide to propose one of them. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

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