Regex anomaly

[Roy Smith]

In article <1136283651.921032.321000 at f14g2000cwb.googlegroups.com>,
 "Sam Pointon" <free.condiments at gmail.com> wrote:

> Would this particular inconsistency be candidate for change in Py3k?
> Seems to me the pos and endpos arguments are redundant with slicing,
> and the re.match function would benefit from having the same arguments
> as pattern.match. Of course, this is a backwards-incompatible change;
> that's why I suggested Py3k.

I don't see any way to implement re.I at match time; it's something that 
needs to get done at regex compile time.  It's available in the 
module-level match() call, because that one is really compile-then-match().