[Python-Dev] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects (original) (raw)

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