[Python-Dev] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects
Alastair Houghton
alastair at alastairs-place.net
Tue Dec 5 15:30:38 CET 2006
On 5 Dec 2006, at 09:02, Ben Wing wrote:
> Fredrik Lundh wrote:
>> Ka-Ping Yee wrote:
>> taking everything into account, I think we should simply map
>> __getitem__
>> to group, and stop there. no len(), no slicing, no sequence or
>> mapping
>> semantics. if people want full sequence behaviour with len and
>> slicing
>> and iterators and whatnot, they can do list(m) first.
>>
> i'm ok either way -- that is, either with the proposal i previously
> published, or with this restricted idea.
I prefer your previous version. It matches my expectations as a user
of regular expression matching and as someone with experience of
other regexp implementations.
(The current groups() method *doesn't* match those expectations,
incidentally. I know I've been tripped up in the past because it
didn't include the full match as element 0.)
Basically, I don't see the advantage in the restrictions Frederik is
proposing (other than possibly being simpler to implement, though not
actually all that much, I think). Yes, it's a little unusual in that
you'd be able to index the match "array" with either integer indices
or using names, but I don't view that as a problem, and I don't see
how not supporting len() or other list features like slicing and
iterators helps. What's more, I think it will be confusing for
Python newbies because they'll see someone doing
m[3]
and assume that m is a list-like object, then complain when things like
for match in m:
print match
or
m[3:4]
fail to do what they expect.
Yes, you might say "it's a match object, not a list". But, it seems
to me, that's really in the same vein as "don't type quit or exit,
press Ctrl-D".
Kind regards,
Alastair.
--
http://alastairs-place.net
More information about the Python-Dev
mailing list