[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

Tal Einat added the comment: Alright, so let's push through the existing PR for rejecting such octal escapes in byte strings. We'll also need another PR for raising a deprecation warning for such octal escapes in strings. -- keywords: +easy, easy (C)

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

Guido van Rossum added the comment: For sure the Python tokenizer/parser should reject octal escapes that produce values >= 256. Certainly in bytes strings. Probably also in text strings (nobody using Unicode thinks in octal). This is ancient behavior though (it's the same in 2.7) so it may

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

Terry J. Reedy added the comment: I can't find who wrote this block treating octal escapes beginning with 4-7 the same as those beginning with 0-3. case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': c = s[-1] - '0'; if (s

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

Tal Einat added the comment: The PR looks pretty good, but the question is whether we want to break backwards compatibility in the name of correctness. In this case, the silent buggy behavior of keeping the (mod 256) of the value seems worth fixing to me. -- nosy: +taleinat

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

Jeffrey Kintscher added the comment: The PR is ready for review. It raises ValueError if the escaped octal value in a byte string is greater than 255. -- ___ Python tracker

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

Change by Jeffrey Kintscher : -- keywords: +patch pull_requests: +14461 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14654 ___ Python tracker

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

Jeffrey Kintscher added the comment: Here is the problematic code in _PyBytes_DecodeEscape in Objects/bytesobject.c: c = s[-1] - '0'; if (s < end && '0' <= *s && *s <= '7') { c = (c<<3) + *s++ - '0'; if (s < end && '0' <= *s && *s <=

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

Jeffrey Kintscher added the comment: >>> b'\407' b'\x07' >>> ord(b'\407') 7 This is the object structure passed to builtin_ord(): (lldb) p *((PyBytesObject *)(c)) (PyBytesObject) $19 = { ob_base = { ob_base = { ob_refcnt = 4 ob_type = 0x0001003cb0b0 } ob_size =

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

Terry J. Reedy added the comment: https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals says, for \ooo, "In a bytes literal, hexadecimal and octal escapes denote the byte with the given value. In a string literal, these escapes denote a Unicode character with

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

Change by SilentGhost : -- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett, serhiy.storchaka versions: +Python 3.9 ___ Python tracker ___

[issue37367] octal escapes applied inconsistently throughout the interpreter and lib

New submission from Dan Snider : At present, the bytecode compiler can generate 512 different unicode characters, one for each integral from the range [0-511), 512 being the total number of syntactically valid permutations of 3 octal digits preceded by a backslash. However, this does not