Python interreter and codecs module don't recognize unicode escape \u{xxx}.

[mrolle45]

Bug report

Bug description:

>>> codecs.decode('\u{0041}',encoding='unicode-escape')
  File "<python-input-2>", line 1
    codecs.decode('\u{0041}',encoding='unicode-escape')
                  ^^^^^^^^^^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-1: truncated \uXXXX escape
>>> codecs.decode('\u0041',encoding='unicode-escape')
'A'
>>> '\u{0041}'
  File "<python-input-4>", line 1
    '\u{0041}'
    ^^^^^^^^^^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-1: truncated \uXXXX escape
>>> '\u0041'
'A'

I'm not sure when the \u{xxx} escape was introduced to the world, but it should be recognized by codecs.decode and the Python interpreter. The above sample was run on Python 3.13.1 on Windows.

CPython versions tested on:

3.13

Operating systems tested on:

No response

[terryjreedy]

The codecs call is irrelevant. You entered an invalid string. You either need to omit the parentheses, as you later did, or use '\N{CHARNAME}', where 'CHARNAME' is a recognized name in the Unicode database. See https://docs.python.org/3/reference/lexical_analysis.html#escape-sequences.

[ericvsmith]

I agree this isn't a bug.

@mrolle45 : What's your evidence that this escape sequence was "introduced to the world"? And even if it were, we'd need more motivation than that to add it to Python. What problem would it solve?

[picnixz]

I don't know why the hexadecimal ordinal value should be considered the same as a named entity, namely why \U{XXXX} would be better than \UXXXX.

I will close this one as "not planned" as the bracket-style syntax should be reserved for named entities and not hexadecimal values. If needs arise, please open a DPO thread first with sufficient evidence that real-world applications would benefit from this feature.