Joran van Apeldoorn added the comment:
Hi,
I was not suggesting that the documentation literally says they should be the
same but it might be unexpected for users if ASCCI characters change properties
depending on whether they are considered in a unicode or pure ASCII setting
Joran van Apeldoorn added the comment:
Small addition, the sre categories CATEGORY_LINEBREAK and
CATEGORY_UNI_LINEBREAK also do not agree on ASCII characters.
The first is only '\n' while the second also includes for example '\r' and some
others. These do not seem to correspond to anything
Change by Joran van Apeldoorn :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue45869>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Joran van Apeldoorn :
The expectation would be that the re.A (or re.ASCII) flag should not impact the
matching behavior of a regular expression on strings consisting only of ASCII
characters. However, for the characters 0x1c till 0x1f, the classes \s and \S
differ
Joran van Apeldoorn added the comment:
After compiling 3.7 and 3.8 as well it seems that the change happened between
those versions.
I was a able to patch compiler.c for 3.9 to make it work (first time changing
cpython internals, so no guarantees).
Patch is attached.
This trips up one
Joran van Apeldoorn added the comment:
Digging around with the disassembler shows that this originates in the
bytecode.
Code:
import dis
src = """
def printingdec(f):
raise Exception()
return f
def dummydec(f):
return f
@printingdec
@dummydec
def
New submission from Joran van Apeldoorn :
When applying multiple decorators to a function, a traceback from the top
generator shows the bottom generator instead.
For example
def printingdec(f):
raise Exception()
return f
def dummydec(f):
return f
@printingdec
