+1
And to be specific, I’m indeed +1 to the {/} syntax as proposed, and -1 to all the rejected syntaxes.
A few minor points of feedback:
I notice that the Rejected Ideas section doesn’t currently list (/) among its extensive list of what other syntaxes were rejected and why - should this be added? I’m sure I’ve seen some posts in support of (/) rather than {/} for the empty set because (/) looks “more like” ∅… but the argument I’ve seen (and personally also agree with) for {/} rather than (/) is that non-empty sets are written with braces, not parentheses.
I also didn’t see any discussion of whitespace in the PEP - this post for example asks the question of whether it’s better to parse {/} as a single token (and therefore forbid variants with whitespace like { / }), or whether to parse it as three separate tokens (and therefore allow variants with whitespace). The PEP does give the grammar, from which it can be seen that the second option has been chosen (and, again, I agree with this decision) - but it’d be nice if it stated why this form was chosen (perhaps another Rejected Ideas section for “Parse {/} as a single token and forbid whitespace”?).
As a final nitpick:
beginners may not know how to recover the
settype if they have overriden the name: techniques to do so (e.g.type({1}-{1})) are not immediately obvious
Surely the example here could be simplified to type({1}), as that also produces set.