Originally, the regex was definitive. The current text, as @ofek pointed out, was changed because I objected to that - but my intent in objecting was that people shouldn’t have to reverse-engineer the regex to know the rules. So to that extent I agree with you. But the regex was precise and I think that was important - the fact that the text wasn’t updated to be equally precise (and to match the regex) was IMO an oversight, and as such doesn’t reflect an intention to have different rules.
I agree that the process wasn’t ideal here, but I think that’s not so much to do with the situation now, as with the whole process of having competing PEPs. Ideally, I’d be against ever having competing PEPs, requiring one PEP to be rejected before an alternative could be submitted - but I don’t see how that would work in practice.
The problem with making a decision of one over another, and then refining the chosen PEP, is that it’s then not clear what was accepted. Was PEP 723 accepted just because it’s TOML? Or just because it mirrors pyproject.toml? Or because it includes requires-python? Or because it allows for other block types in future? Possibly all of these, although PEP 722 also experimented with multiple blocks, and dropped the idea because of parsing complexities that are quite reminiscent of the issues being raised here. If PEP 723 changes, does the decision stand? Could I make PEP 722 more acceptable if I changed it? At what point are we just abandoning the decision in that case?
I won’t debate @brettcannon’s decision here. It’s an incredibly stressful job, making a decision between two competing PEPs, and no matter what you decide, you always feel that some group is annoyed at you. I really appreciate the fact that Brett was willing to act as PEP delegate, and put so much effort and expertise into making a decision that was bound to be controversial. I suffered a lot of criticism for the decision over editable installs, and I absolutely will not subject Brett to that sort of thing.
So with that said, we have an accepted PEP. It says what it says, and people had all the time they needed before the PEPs were submitted for approval to request changes. What we’ve ended up with may not be perfect, but we need, as a community, to stand by our processes and our decisions. If we can’t do that, we will never be able to make progress.
We have a process for changing accepted standards. If there’s evidence that we need to invoke that, then we can do so. But I think we should give it more than 3 days after acceptance before deciding we need to take that route.
Both @ofek and I (as the authors of the two competing PEPs) have stated that PEP 723 should be read as saying that the regex defines the behaviour in this case. That should be sufficient in the short term at least. Clarifying, but not changing, the specification can happen later, once the spec is online - as per our process, that would need agreement[1] that it is just a clarification, if it were to be done without a PEP.
From me, as interoperability spec PEP delegate. ↩︎