When calling repr() on a compiled regex pattern like this:

import re
repr(re.compile('foo'))

you don't get the pattern of the regex out of the compiled form. Also all my research has shown no getter to allow this.

I noticed this in my application because I was unable to show good error messages for things involving regexes, which is a shame.

So please add the actual regex to the repr() form of the compiled regex, or alternatively provide a getter / property to get at it.

I'm not sure having the pattern in the repr will make it more readable, since the regex might even be very long. You can use the .pattern attribute if you want to see the pattern.

I'm not sure having the pattern in the repr will make it more readable,
since the regex might even be very long.

Hmm, I think it's a reasonable feature request myself.
Oops, I meant "enhancement", not "feature request" :)

In reply to Ezio, the repr of a large string, list, tuple or dict is also long.

The repr of a compiled regex should probably also show the flags, but should it just be the numeric value?

ISTM that .pattern is the one way to do it.

ISTM that .pattern is the one way to do it.

To me this is like saying the repr() of functions should not show their
name since .__name__ is the one way to do it. repr() is useful for
debugging and logging, why not make it more useful?

If you change the repr, it should at least eval-able, so be sure to capture the flags and whatnot.

Actually, one possibility that occurs to me is to provide the flags within the pattern. The .pattern attribute gives the original pattern, but repr could give the flags in-line at the start of the pattern:

>>> # Assuming Python 3.
>>> r = re.compile("a", re.I)
>>> r.flags
34
>>> r.pattern
'a'
>>> repr(r)
"<_sre.SRE_Pattern '(?i)a'>"

I'm not sure how to make it eval-able, unless you mean something more like:

>>> repr(r)
"re.Regex('(?i)a')"

where re.Regex == re.compile, which would be more meaningful than:

>>> repr(r)
"re.compile('(?i)a')"

If an eval-able re.Regex is used, the flags can be showed as second arg, like:
re.Regex('a', re.I|re.S)
instead of being added to the pattern as in
re.Regex('(?is)a')

The repr can be generated with something like
're.Regex({r.pattern!r}, {r.flags})'.format(r=r)
that currently prints
re.Regex('abc', 50)
but if bpo-11957 is fixed, the result will look like
re.Regex('abc', re.I|re.S)
for a regex created with
r = re.compile('abc', re.I|re.S)

but if bpo-11957 is fixed, the result will look like
re.Regex('abc', re.I|re.S)

That is what I would like to see.

I'm just adding this to the regex module and I've come up against a possible issue. The regex module supports named lists, which could be very big. Should the entire contents of those lists also be shown in the repr?They would have to be if the repr is to be a eval-able.

I'm just adding this to the regex module and I've come up against a
possible issue. The regex module supports named lists, which could be
very big. Should the entire contents of those lists also be shown in
the repr?They would have to be if the repr is to be a eval-able.

I don't see how eval()able repr is a big deal. Most reprs aren't, and I
think a readable and informative representation is the real goal.

"I don't see how eval()able repr is a big deal. Most reprs aren't, ..."

Sometimes, I wonder if we're even talking about the same programming language. Historically, a good deal of effort has gone into creating evalable reprs, if only because they accurately describe an object and because they teach users how to create similar objects.

But it only takes one committer who doesn't care about evalable reprs to permanently break the pattern for everyone :-(

Raymond, Antoine: I don't see your claims as contradictory, it's definitely true that the Python standardlib has historically tried to keep reprs as being eval-able, I think Antoine's correct that the vast majority of 3rd-party code does not keep with that trend.

But it only takes one committer who doesn't care about evalable reprs
to permanently break the pattern for everyone :-(

So 95% of our datatypes were committed by a single person? :)

Hey, I started the patch under default branch, and get the following working:

    >>> import re
    >>> re.compile("foo")
    re.compile("foo", re.UNICODE)
    >>> re.compile("foo", re.DOTALL)
    re.compile("foo", re.DOTALL|re.UNICODE)
    >>> re.compile("foo", re.DOTALL|re.MULTILINE)
    re.compile("foo", re.MULTILINE|re.DOTALL|re.UNICODE)
    >>>

Do you have any comments on it?

I want to adapt the patch to make it work with python 2.7 too. Do you think is it worthful?

The attached patch was done after commit 3fbfa61634de.

Python 2.7 is the end of the Python 2 line, and it's closed except for security fixes.

2.7 is on extended maintenance for normal bugs, but does not get new features/enhancements. It is too late for 3.3 also.

Thanks for the review ezio.melotti.

He has notice a few things in my patch:

• assertEquals is deprecated; should use assertEqual
• the convention is assertEqual(result, expected), not assertEqual(expected, result)
• it should handle quotes correctly
• some lines were longer than 80 chars
• add tests using inline flags (re.I instead of re.IGNORECASE)

And I realized I was not covering the case where no flags are enabled (byte string, for instance). And I have fixed all this issues.

And now I think this patch would work against py2x and py3k anyway.

Attaching a new patch.

Changed two test names to avoid misunderstanding.

Any news about this patch? Is it going to be merged?

When is next CPython release?

See also bpo-17087 which is essentially the same issue but for match objects.

Here is fixed and simplified patch.

• re.UNICODE omitted for string patterns.
• Long patterns are truncated.

New changeset 8c00677da6c0 by Serhiy Storchaka in branch 'default':
Issue bpo-13592: Improved the repr for regular expression pattern objects.
http://hg.python.org/cpython/rev/8c00677da6c0

Thank you Hugo for your contribution. Thank you Thomas and Ezio for your reviews and suggestions.

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

Isn't the trucation of long patterns too rough? Currently, repr(re.compile("a" * 1000)) returns something like "re.compile('aaaaaaaaaaaaa)", i.e. no ending quote and no indication that something was truncated (besides the missing quote). It looked like a bug to me at first sight.

This looks weird, but is not a bug. See bpo-26090. After implementing that feature truncating a pattern would look more explicit.