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.
Hmm, I think it's a reasonable feature request myself.
Oops, I meant "enhancement", not "feature request" :)

> 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?

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 #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)

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.

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.

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.

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.