[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