On Tue, Jun 30, 2020 at 5:05 AM Steven D'Aprano <[email protected]> wrote:
> For single-character escape codes, I see no benefit at all to this, only
> disadvantages. However I do see a tiny potential benefit to hex escapes,
> for the rare occassions that they are immediately followed by something
> that looks like it could be part of the escape but isn't:
>
> "\x2b2c" # Looks like '+,' but is '+2c'
>
Those are not rare, any escapes \n \t etc. can be followed by text,
but anyway, I agree in general - only if you have good syntax highlighting.
> Counter-proposal: hex escapes allow optional curly brackets, similar to
> unicode name escapes. You could even allow spaces within the braces, for
> grouping:
>
> # Proposed enhancement:
> "\x{2b}2c" # '+2c'
> "\x{2b2c}" # '+,'
> "\x{DEAD BEEF}" # "\xDE\xAD\xBE\xEF"
Nice. But I am not sure about the data type and interpretation depending
on string type. E.g. the second example:
"\x{2b2c}" # '+,'
In my example I was showing hex codepoints, e.g. U+2b2c is ⬬ (Black
Horizontal Ellipse)
IIUC you shown a byte array with arbitrary spacing, whereas I meant
characters by
codes without leading zeroes, separated by space.
So how you would propose to input those then?
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/2BX2GFO7WQERUNXORZMOJFKKDOEDDLLW/
Code of Conduct: http://python.org/psf/codeofconduct/
