-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve the repr for regular expression match objects #61289
Comments
Experience teaching Python has shown that people have a hard time learning to work with match objects. A contributing cause is the opaque repr: >>> import re
>>> s = 'On 3/14/2013, Python celebrate Pi day.'
>>> mo = re.search(r'\d+/\d+/\d+', s)
>>> mo
<_sre.SRE_Match object at 0x100456100> They could explore the match object with dir() and help() and the matchobject methods and attributes: >>> dir(mo)
['__class__', '__copy__', '__deepcopy__', ...
'end', 'endpos', 'expand', 'group', ... ]
>>> mo.start()
3
>>> mo.end()
12
>>> mo.group(0)
'3/14/2013' However, this gets old when experimenting with alternative regular expressions. A better solution is to improve the repr: >>> re.search(r'\d+/\d+/\d+', s)
<SRE Match object: start=3, stop=12, group(0)='3/14/2013'> This would make the regular expression module much easier to work with. |
Showing start and stop would be OK, but there might be many groups and they might contain lot of text, so they can't simply be included in the repr as they are. |
Is this a duplicate of bpo-13592? |
Just showing group(0) should be helpful. And perhaps the number of groups. If a string is really long, we can truncate it like reprlib does. The main goal is to make it easier to work with match objects at the interactive prompt. They are currently too opaque. |
bpo-13592 is indeed the issue I was thinking about, but apparently that's about _sre.SRE_Pattern, so it's not the same thing.
Often the interesting group is group(1), so showing only group(0) seems a bit arbitrary.
If we show only group(0), this might be useful as an indication that there are(n't) other groups.
That's certainly an option. FWIW I don't usually care about the start/end, and, if included, these values could be included as span=(3,12). |
Here's my patch attempt. The repr of a match object has the following format: |
What about such output? >>> re.search('p((a)|(b))(c)?', 'unpack')
<SRE Match object: [2: 5]: 'p'(('a')())('c')> Or may be ('p', [['a'], []], ['c']) if you prefer legal Python expression. |
Serhiy, at the first glance, that repr doesn't make sense to me, thus it seems a little difficult to comprehend. |
Well, then first will commit a simpler patch. I left comments on Rietveld. |
Here's the new version. I added a few replies on the Rietveld. |
Added the new version. |
Serhiy, are there any left issues with my latest patch? It would be nice if we could get this into 3.4. |
Added the new patch, which addresses Serhiy's comments. >>> import re
>>> re.search(b"a", b"a")
Assertion failed: (PyUnicode_Check(op)), function _PyUnicode_CheckConsistency, file Objects/unicodeobject.c, line 309. Should a check be added for this also? |
Use correct first argument to getslice(). |
Latest patch attached. |
It is too complicated (and perhaps erroneous). Why not use just self->pattern->logical_charsize? |
I could use self->pattern->logical_size, but it seems that I still need the call to getstring for bytes & co, to obtain the view to the underlying buffer (otherwise the group0 part from the repr will contain random bytes). I didn't find a simpler way to achieve this. |
Well. Here is a patch. I have changed repr() a little. repr() now contains match type qualified name (_sre.SRE_Match). "groups" now equals len(m.groups()). "span" representation now contains a comma (as repr(m.span())). Raymond, Ezio, is it good to you? |
I discussed this briefly with Serhiy on IRC and I think the repr can be improved.
Currently it looks like:
>>> re.compile(r'[/\\]([.]svn)').match('/.svn')
<_sre.SRE_Match object: groups=1, span=(0, 5), group0='/.svn'> One problem is that the group count doesn't include group 0, so from the example repr one would expect that the info are about the 1 (and only) group in "groups=", whereas that is actually group 0 and there's an additional group 1 that is not included in the repr. A possible solution is to separate the group count from the info about group 0: To make things even less confusing we could avoid calling it group0 and use something like "match=", or alternatively remove the group count (doesn't the count depend only on the regex, and not on the string?). |
Added patch based on Serhiy's, which addresses your comments. It drops the group count and renames group0 to |
LGTM (except unrelated empty line at the end of Modules/_sre.c). |
New changeset 29764a7bd6ba by Serhiy Storchaka in branch 'default': |
Thanks all participants for the discussion. |
New changeset 4ba7a29fe02c by Ezio Melotti in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: