I have alternate syntax suggestion to toss into the mix. This may trigger an immediate negative reaction from some, but give it a look and at least ponder it as this would also be concise which is one thing the ,/ syntax has going for it.
Repurpose the old Python 2 tuple unpacking argument syntax. It was removed in Python 3 because it was extremely uncommon, not a lot of people even knew of it.
Instead of the existing PEP-570’s proposed:
def castle(name, should_burn, /, sink_into_swamp):
That would look like:
def castle((name, should_burn), sink_into_swamp):
Long time pythonistas and Guidos: Don’t read that with your remaining Python 2 eye. All I’m suggesting is that the () around the first parameters causes them to be positional only. Instead of a ,/. No actual tuples involved. I doubt most of the world’s Python developers would mind this syntax. It’d be the first time they’ve seen it.
Good: Concise. No use of / as a mystery parameter. Less violent slashing in the code. () are prettier.
Bad: Python 2 literature covers this syntax and some tiny minority of very old Python 2-only code actually uses it with a semi-different meaning. This could also trip up people porting the rare Python 2 that used tuple unpacking args code to Python 3, but their API already needs changing as is so they already have that problem. If that was the only hold up, it could be ameliorated by going through an extra release cycle behind a from __future__ import.
Similarities: In Python 2 this was a way to specify required positional only arguments. Unfortunately they needed to be manually wrapped in an iterable when calling the function. We’d be restoring a subset of that concept without any of the odd magic iterable passing and unpacking.
Alternatives, well, we’ve got other tokens that could do this instead of (). {} or [] perhaps. Though I think both of those would lead to more confusion as they imply mutable types rather than a mere ordered grouping so I’m not going there.
No tuples were harmed to bring you this message.