I think there is a lot of code that relies on the repr() or str() so there can be security implications. Since this idea is far from new it strongly reminds me of the mail thread https://bikeshed.org/ from the living legend PhK.
Honestly this is fine.. you know it's a 2 character optimisation but whatever... EXCEPT IT BREAKS BACKWARDS COMPAT.
Seriously? Breaking compat for crap like this? It must take copious amounts of cocaine to actually hit publish after writing this thing.
But what was I expecting really... These are the maintainers that removed a _standard library_ package (`imp`) in 3.12 breaking all kinds of projects for no reason at all. Just mark it deprecated (which they did) and leave it there for heaven's sake.
Anyway... I guess this is fine as long as it leaves repr() and str() the way they are.
I think there is a lot of code that relies on the repr() or str() so there can be security implications. Since this idea is far from new it strongly reminds me of the mail thread https://bikeshed.org/ from the living legend PhK.
Here is the discussion thread on Python Discourse: https://discuss.python.org/t/pep-802-display-syntax-for-the-...
I agree that set() is the ugly child of the [], {}, () family, but is a two character optimization for readability really worth it?
Honestly this is fine.. you know it's a 2 character optimisation but whatever... EXCEPT IT BREAKS BACKWARDS COMPAT.
Seriously? Breaking compat for crap like this? It must take copious amounts of cocaine to actually hit publish after writing this thing.
But what was I expecting really... These are the maintainers that removed a _standard library_ package (`imp`) in 3.12 breaking all kinds of projects for no reason at all. Just mark it deprecated (which they did) and leave it there for heaven's sake.
Anyway... I guess this is fine as long as it leaves repr() and str() the way they are.