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.
FWIW there was another issue about changing _sre.SRE_Match to something better, but I can't find it right now.

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.

Just showing group(0) should be helpful.

Often the interesting group is group(1), so showing only group(0) seems a bit arbitrary.

And perhaps the number of groups.

If we show only group(0), this might be useful as an indication that there are(n't) other groups.

If a string is really long, we can truncate it like reprlib does.

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:
(groups=\d+, span=(start, end), group0=the entire group or the first X characters, where X is represented by a new constant in sre_constants.h, SRE_MATCH_REPR_SIZE).

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.
Also, this approach fails when bytes are involved:

>>> 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:
<_sre.SRE_Match object (1 group); group0='/.svn', span=(0, 5)>

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 match.

LGTM (except unrelated empty line at the end of Modules/_sre.c).

New changeset 29764a7bd6ba by Serhiy Storchaka in branch 'default':
Issue bpo-17087: Improved the repr for regular expression match objects.
http://hg.python.org/cpython/rev/29764a7bd6ba

Thanks all participants for the discussion.

New changeset 4ba7a29fe02c by Ezio Melotti in branch 'default':
bpo-13592, bpo-17087: add whatsnew entry about regex/match object repr improvements.
http://hg.python.org/cpython/rev/4ba7a29fe02c