On Wed, Jul 1, 2020 at 1:57 AM MRAB
On 2020-06-30 13:25, Chris Angelico wrote:
On Tue, Jun 30, 2020 at 2:28 PM MRAB
wrote: On 2020-06-30 02:14, Steven D'Aprano wrote: [snip]
Counter-proposal: hex escapes allow optional curly brackets, similar to unicode name escapes. You could even allow spaces within the braces, for grouping:
# Existing: "\N{HYPHEN-MINUS}" # '-' "\x2b" # '+'
# Proposed enhancement: "\x{2b}2c" # '+2c' "\x{2b2c}" # '+,' "\x{DEAD BEEF}" # "\xDE\xAD\xBE\xEF"
This could work in f-strings and bytes as well. I think this might be of use for people who do a lot of work with binary file formats and hex escapes.
I think this is backwards compatible too, since "\x{" is currently a syntax error.
There's a precedent in other languages that use this form instead of \uXXXX and \UXXXXXXXX.
Be careful of semantics here. I'm not sure which languages do what, but I just checked Perl, and "\x{1234}" is equivalent to Python's "\u1234", not to "\x12\x34". This proposal is for the latter, which could be sneakily confusing to someone who also writes in Perl.
MRAB, can you name other languages that use this form?
Ah, right. I missed that bit. That's what happens if you post when you should be sleeping!
I was just referring to \x{...} as used in Perl, etc.
Ah, no probs :)
I suppose that "\x{DEAD BEEF}" could also mean "\x{DEAD}\x{BEEF}" or "\uDEAD\uBEEF".
Yeah, that would be handy. Reminds me of the way I used to work in REXX, where you could write "41 42 43 44"x (yes, it's a string *suffix*) and it would be equivalent to "ABCD". The spaces were optional in REXX, because it worked with bytes, but it might be safer to mandate them (to avoid the ambiguous interpretation). ChrisA