Ezio Melotti added the comment:
See also #19536.
I still think that if we do something about these issues, we should try to be
compatible with the regex module.
If we are going to add support for both iterability and __getitem__, they
should be consistent, so that list(m) == [m[0], m[1], m[N]].
This means that m[0] should be equal to m.group(0), rather than m.group(1).
Currently the Match object of the regex module supports __getitem__ (with m[0]
== m.group[0]) but is not iterable:
>>> m = regex.match('([^:]+): (.*)', 'foo: bar')
>>> m[0], m[1], m[2]
('foo: bar', 'foo', 'bar')
>>> len(m)
3
>>> list(m)
TypeError: '_regex.Match' object is not iterable
I can see different possible solutions:
1) do what regex does, have m[X] == m.group(X) and live with m[0] == m.group(0)
(this means that unpacking will be "_, key, value = m");
2) have m[0] == m.group(1), which makes unpacking easier, but is inconsistent
with both m.group() and with what regex does; *
3) disregard regex compatibility and implement what we think is best;
* since regex already has a few incompatibilities with re, a global
flag/function could be added to regex to make it behave like the re module
(where possible). If necessary, the re module could also include and ignore a
similar flag/function. This would make interoperability between the two easier.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9529>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
