PEP 0637: Add another rationale

[smurfix]

Another use for this PEP is parameterizing a function that takes another function (plus its arguments). We need some Pythonic way to distinguish keywords the caller from those for the passed-in function. This notation would work much like typing and thus avoid the shortcomings of alternate solutions.

[the-knights-who-say-ni]

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@smurfix

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

[smurfix]

Account at bpo updated.

[stevendaprano]

I like this use-case, but I think it needs to be explained better. I didn't really understand it until I followed the links to the trio-run bug report and read this:

"Anyway, here's the problem: a function like run has to take the thing to run, and it also has to take its own arguments to configure how it runs it. So we need some way to distinguish which arguments are for which, but all the possible solutions involve some kind of awkwardness."

My personal feeling is that quoting the trio-run dev directly, with a link to the bug report, actual speaks stronger than the code samples. The problem with the code samples is that until you understand what they are intended to do, which requires some familiarity with trio-run, they look "good enough" -- especially the first, without partial.

smurfix, if you agree, would you care to reword the rationale?

Otherwise, if you disagree and think that your existing wording is superior, I won't argue further. Either way, I think it is an excellent use-case.

[smurfix]

Reworded the rationale and (over g)commented the example code

[JelleZijlstra]

This has a merge conflict now; it would also be good to get a review from the PEP authors.

[stefanoborini]

@JelleZijlstra on it.

[stefanoborini]

I think it's a great use case, but we will have to find a way to have it idiomatic for some design choices.
It reminds me of the syntax in cuda kernels, and it could be pointed out as such in the use case. Other than this, I'm +1 for accepting it after conflict resolved.

[gvanrossum]

@stefanoborini -- This PR is still open; what do you want to do with it?

[stefanoborini]

@gvanrossum Good for me. can be merged.