[issue39949] truncating match in regular expression match objects repr

Quentin Wenger added the comment: Other pathological case: literal backslashes ``` >>> re.match(".*", r"\\") ``` -- ___ Python tracker ___ __

[issue39949] truncating match in regular expression match objects repr

Quentin Wenger added the comment: *off -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue39949] truncating match in regular expression match objects repr

Quentin Wenger added the comment: (but those are one-character escapes, so that should be fine - either the escape is complete or the backslash is trailing and can be "peeled of") -- ___ Python tracker

[issue39949] truncating match in regular expression match objects repr

Quentin Wenger added the comment: And ascii escapes should also not be forgotten. ``` >>> re.match(b".*", b"\t") >>> re.match(".*", "\t") ``` -- ___ Python tracker ___

[issue39949] truncating match in regular expression match objects repr

Quentin Wenger added the comment: An extraneous difficulty also exists for bytes regexes, because there non-ascii characters are repr'ed using escape sequences. So there's a risk of cutting one in the middle. ``` >>> import re >>> re.match(b".*", b"\xce") ``` -- __

[issue39949] truncating match in regular expression match objects repr

Seth Troisi added the comment: I was thinking about how to add the end quote and found these weird cases: >>> "asdf'asdf'asdf" "asdf'asdf'asdf" >>> "asdf\"asdf\"asdf" 'asdf"asdf"asdf' >>> "asdf\"asdf'asdf" 'asdf"asdf\'asdf' This means that len(s) +2 (or 3 for bytes) != len(repr(s))

[issue39949] truncating match in regular expression match objects repr

Quentin Wenger added the comment: File objects are an example of a square-bracket repr with string parameters in the repr, but no truncation is performed (see https://github.com/python/cpython/blob/master/Modules/_io/textio.c#L2912). Various truncations with the same (lack of?) clarity are d

[issue39949] truncating match in regular expression match objects repr

Quentin Wenger added the comment: Oh ok, I was mislead by the example in your first message, where you did have both the quote and ellipsis. I don't have a strong opinion. - having the quote is a bit more "clean" - but not having it makes clear than the pattern is truncated (per se, three do

[issue39949] truncating match in regular expression match objects repr

Seth Troisi added the comment: @matpi The current behavior is for the right quote to not appear I kept this behavior but happy to consider changing that. See the linked patch for examples -- ___ Python tracker

[issue39949] truncating match in regular expression match objects repr

Change by Seth Troisi : -- keywords: +patch pull_requests: +20100 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/20922 ___ Python tracker _

[issue39949] truncating match in regular expression match objects repr

Quentin Wenger added the comment: @eric.smith thanks, no problem. If I can give any advice on this present issue, I would suggest to have the ellipsis _inside_ the quote, to make clear that the pattern is being truncated, not the match. So instead of ``` <_sre.SRE_Match object; span=(0, 49)

[issue39949] truncating match in regular expression match objects repr

Eric V. Smith added the comment: Ah, I see. I missed that this issue was only about match objects. I apologize for the confusion. That being the case, I'll re-open the other issue. -- ___ Python tracker __

[issue39949] truncating match in regular expression match objects repr

Quentin Wenger added the comment: For a bit of background, the other issue is about the repr of compiled patterns, not match objects. Please see my argument there about the conformance to repr's doc - merely adding an ellipsis would _not_ solve this case. I have however nothing against the p

[issue39949] truncating match in regular expression match objects repr

Eric V. Smith added the comment: There was a discussion in issue40984 that the repr must be eval-able. I don't feel very strongly about this, mainly because I don't think anyone ever does eval(repr(some_regex)). I'd be slightly sympathetic to wanting the eval to fail if the repr had to trunc

[issue39949] truncating match in regular expression match objects repr

Seth Troisi added the comment: I didn't propose a patch before because I was unsure of decision. Now that there is a +1 from Raymond I'll working on a patch and some documentation. Expect a patch within the week. -- ___ Python tracker

[issue39949] truncating match in regular expression match objects repr

Change by Eric V. Smith : -- components: +Regular Expressions -Library (Lib) nosy: +ezio.melotti, mrabarnett resolution: not a bug -> stage: resolved -> needs patch status: closed -> open ___ Python tracker

[issue39949] truncating match in regular expression match objects repr

Raymond Hettinger added the comment: +1 for adding an ellipsis. It's a conventional way to indicate that the displayed data is truncated. Concur with Eric that missing close quote is too subtle (and odd, and unexpected). -- nosy: +rhettinger ___

[issue39949] truncating match in regular expression match objects repr

Change by Seth Troisi : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bu

[issue39949] truncating match in regular expression match objects repr

Eric V. Smith added the comment: I think the missing closing quote is supposed to be your visual clue that it's truncated. Although I'll grant you that it's pretty subtle. -- nosy: +eric.smith versions: +Python 3.9 ___ Python tracker

[issue39949] truncating match in regular expression match objects repr

New submission from Seth Troisi : Following on https://bugs.python.org/issue17087 Today I was mystified by why a regex wasn't working. >>> import re >>> re.match(r'.{10}', 'A'*49+'B') <_sre.SRE_Match object; span=(0, 10), match='AA'> >>> re.match(r'.{49}', 'A'*49+'B')