+1 for me, this would lift a pretty arbitrary constraint
I have a working implementation, it only requires trivial changes to the grammar:
If this looks good to everyone we can open a proper issue and I’ll make a pull request.
2 Likes
Not sure how I feel about this:
def foo(/, *):
pass
Also note that this would require a PEP.
I don’t see a problem with it. The parameter separators are used in a vacuous way, but they still specify a valid signature:
- All parameters before
/are positional-only - All parameters between
/and*are named - All parameters after
*are keyword-only
I haven’t proposed a PEP before, but it seems like a disproportionately heavy process for such a minor adjustment? I genuinely don’t know.
1 Like
It’s a change to the language syntax, so I do think it requires a PEP. That means it needs a core dev sponsor.
While the adjustment is minor, this will require people to update documentation and various language tools (linters, language servers, etc) and so it’s not a trivial amount of work.
Hmm it might be difficult to find a sponsor for this. But I’ll try to come up with a straightforward draft. Thanks!
This is kinda crucial. If you can’t find even one core dev willing to support the proposal, it’s a dead proposal. The point of a PEP is to convince the Steering Council that this is worth doing, which is a fairly high bar; finding just one core dev who’s willing to say “yes, this proposal is worth moving forward with” is comparatively easier.
The issue is that this would be a legitimate improvement, but almost no one will notice it, which probably doesn’t make it very enticing to work on for any core dev. Where do I go to find a core dev once I have a draft?
You don’t need a core dev to work on it, you just need to convince them to sponsor your PEP[1]. The place to find them is right here[2].
But none of them have commented on this thread so far as I suspect it’s going to be a tough sell.
I want to reiterate what I mentioned above: this might seem like a tiny change, but it’ll create a fair amount of work for people. So it’s not trivial.
1 Like
I mean, I have a branch with the required changes ready to merge, and I can write the PEP, but yeah I’m afraid that with the number of man-hours required by the process alone it’s not going to be worth it.
If any core dev happens to be passing by, I’d be grateful if you considered sponsoring this, I promise I won’t bother you too much. 
Proposed edit to thread title: “Increase generality of / and * in function signatures [needs sponsor]”
2 Likes
Fantastic! Thanks for your work on this.
Thanks for the suggestion - I’ve made a slightly different edit, inspired by Valentin’s commit message. Hopefully we can gain support from a core dev
2 Likes
I have some sympathies for the proposal as it removes an arbitrary restriction in the grammar and I think one should always strive for simplicity. Nonetheless, there are significant costs of implementing this:
- The commit does not contain the changes to the documentation of Python and no item for the change logs, so it could not be merged as-is.
- No analysis has been done on the costs for syntax highlighters, type checkers or linters. Just out of curiosity, I tried black (which has its own parser) and it failed:
$ cat test.py
def foo(/, a):
pass
$ python -m black test.py
error: cannot format test.py: Cannot parse: 1:8: def foo(/, a):
Oh no! 💥 💔 💥
1 file failed to reformat.
So, besides of updating cpython itself, tools need to be updated as well.
On the flipside: The gain of the proposal is almost nothing.
3 Likes
I’ll add the docs and news blurb when making the actual pull request.
When it comes to updating those tools, it should be pretty trivial, as the changes to cpython’s own grammar would suggest. I’ll look into black/pyright/ruff/etc and try to prepare a pull request for each of the major open-source project I know of. And for any lesser-known tool out there, they’ll probably have ample time to update until one of their users runs into a use case that relies on inert parameter separators. The good thing about a progressive enhancement like this is that it doesn’t cost much for people to keep abiding by the previous restriction while the ecosystem catches up, so it keeps the pressure on tools maintainers fairly low.