SUMMARY:
I share with you extracts from a personal email Rick Teachey sent me, on my involvement in PEP 637 (keyword arguments in item access), and my answers to some important questions he asks.

BACKGROUND:
Last week, prior to my publicly stating my resignation as a co-author of PEP 637, Ricky Teachey sent me a personal email. I found it so deep and perceptive that I asked him for permission to share extracts with you on this list. I'm pleased that he's allowed this, and I'm most grateful to him for this.

The rest of this post consists of extracts from his email, and some brief comments from me.

RICKY'S EMAIL and MY RESPONSES:

Ricky Teachey wrote:
It is clear to all-- not a secret-- you take a different view on the desirability of what is currently the favored proposal. It seems to me what has happened here is, Guido, Steven, and now Stefano believe that your involvement in the PEP (one that is championing that proposal you have significant disagreements with) has been undertaken by you out of a motivation to either get it drastically changed, or (again, in their belief) perhaps even to replace it totally with something else.
 
Now I want you to know I don't get that impression from you. I get the impression you joined the PEP team out of a simple desire to make it better, even though you disagreed with parts of it.

PEP 1 says:
The PEP author is responsible for building consensus within the community and documenting dissenting opinions.

[The PEP] should clearly explain why the existing language specification is inadequate to address the problem that the PEP solves. 

I want keyword arguments in item access to be added to Python, and I want it to be done well. Something that won't cause difficulty 3 to 5 years from now. PEP 1, as above, has good advice that contributes to this goal. These are areas I particularly wanted to contribute to, as a PEP author. I have no wish to use improper methods to obtain what I think is best.

Ricky Teachey wrote:
I also understand, though, that at least part of the motivation [for developing kwkey] is something else; you believe that if people experiment a bit ahead of time using actual code, the deficiencies of the current proposal will feel worse than people are imaging in their minds. I wouldn't suggest you back down from saying that outright, too. But if you can say so, I would emphasize that the primary purpose is helping people experiment.

At least when convenient, I'm all for experiments prior to making hard-to-reverses changes to Python.

PEP 1 says:
For a PEP that adds new functionality or changes language behavior, it is helpful to include a section on how to teach users, new and experienced, how to apply the PEP to their work. 

A basic idea of kwkey is an equivalence between
    d[1, 2, a=3, b=4] = val
    X(1, 2, a=3, b=4)[d] = val
provided X and item keyword access are given the same semantics. This idea will I think help greatly with the 'teach users' section of the PEP.

Observation, experiment and theory are fundamental to science. Astronomy has the observatory. Biology, chemistry and physics have the laboratory. All research scientists publish. We can use kwkey to do experiments, without first having to create a new version of Python. It makes experiments cheap.

My opinions result in predictions for the result of these experiments. But rather than discuss opinions, I'd like us to do experiments and share our experience. I've been surprised by the results of my own experiments using kwkey! We can all learn from experiments, particularly if we're observant.

Ricky Teachey wrote:
However, on the other hand, if the first is not really your purpose-- if what you really want is for people to use the package and realize the proposal needs to be changed, I would [...] suggest asking to write a competing PEP, and promote kwkey a great tool that the steering council can use to make a good choice between competing PEPs.

I applaud your suggestion, that the steering council use kwkey as part of making a choice. And 
I think we're getting closer to having a second PEP.

Here's an idea. At present both of
    d[1:2]
    d[1:2, 3:4, 5, 6]
are valid syntax, but neither of
    d[(1:2)]
    d[(1:2, 3:4, 5, 6)]
are valid syntax. This is, I think, a bit of an anomaly.

I suggest a PEP that extended the syntax to allow
    (1:2)
    (1:2, 3:4, 5, 6)
to be expressions (to be used as function arguments, with the existing item access semantics). I think this is something which most supporters of keyword arguments in item access could support. And which few opponents of keyword arguments in item access would oppose. It's a small and fairly safe change.

And this change would, via constructs such as
   X((1:2), a=(3:4))[d] = val
allow us to get perhaps 75% of the benefits provided by the larger (and more risky) change that would allow
    d[1:2, a=3:4] = val

I think we could get (1:2) etc expressions into the next version of Python (in 2021). And then, if 
    X((1:2), a=(3:4))[d] = val
is widely used, and the semantics of X agreed upon, perhaps
    d[1:2, a=(3:4)] = val
could be added in 2022. My big concern is making a big change now, whose problems emerge in 2023 to 2025.

I hope this helps. And I thank Ricky both for his thoughtful personal email, and for giving me permission to share it with you.

-- 
Jonathan