On Tue, Sep 30, 2014 at 09:57:44PM +0200, Antoine Pitrou wrote:
On Tue, 30 Sep 2014 12:16:13 -0500 Ryan Gonzalez <rymg19@gmail.com> wrote:
This works:
re.search('(abc)', 'abc').group(1)
but this doesn't:
re.search('(abc)', 'abc').group(1L)
The latter raises "IndexError: no such group". Shouldn't that technically work?
Yes, it's a bug. Feel free to open an issue.
I'm not so sure that it's a bug. Should .group(1.0) work? That also is numerically equal to 1. MatchObject.group does not necessarily have to obey the semantics of list.index or dict.__getitem__. Just because ['a', 'b'].index(1L) and {1: 'b'}[1.0] both return 'b' doesn't force .group() to do the same. The documentation for .group is underspecified, and perhaps TypeError would be a more appropriate error rather than IndexError, but IndexError is consistent with other bad arguments: py> re.search('(abc)', 'abc').group([]) Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: no such group So I don't think this is a bug, I think it is just an unfortunate choice of misleading exception type. The re module goes back to at least 1.5, and as far as I can tell, .group has never accepted longs. (I have tested it on 2.4 through 2.7, and 1.5, and it fails with all of them.) So this is a long-established restriction on the argument. (Another restriction is that a maximum of 99 groups are supported, so there are no cases where a long is needed.) Allowing longs is a new feature, not a bug fix. Since 2.7 is bug-fix only mode, and this fix is unneeded in 3.x, there is no point in raising an issue to the tracker. -- Steven