[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
Thu Dec 7 14:00:26 CET 2006


On 7 Dec 2006, at 07:15, Fredrik Lundh wrote:

> Michael Urman wrote:
>
>> The idea that slicing a match object should produce a match object
>> sounds like a foolish consistency to me.
>
> well, the idea that adding m[x] as a convenience alias for m.group(x)
> automatically turns m into a list-style sequence that also has to
> support full slicing sounds like an utterly foolish consistency to me.

How about we remove the word "foolish" from the debate?

> the OP's original idea was to make a common use case slightly  
> easier to
> use.  if anyone wants to argue for other additions to the match object
> API, they should at least come up with use cases based on real  
> existing
> code.

An example where it might be useful:

  m = re.match('(?:([0-9]+) ([0-9]+) ([0-9]+) ([0-9]+) (?P<rect>rect)'
               '|([0-9]+) ([0-9]+) ([0-9]+) (?P<circle>circle))',
               lineFromFile)

  if m['rect']:
      drawRectangle(m[1:5])
  elif m['circle']:
      drawCircle(m[1:3], m[3])

Is that really so outlandish?  I'm not saying that this is  
necessarily the best way, but why force people to write

   list(m)[1:5]

or

   [m[i] for i in xrange(1,5)]

??

If the only reason is that some of the match object APIs, which I  
maintain are very unlikely to be wanted on a slice anyway, can't  
possibly produce consistent results, then why not just do away with  
the APIs and return a tuple or something instead?  That way you can  
treat the match object as if it were just a tuple (which it could  
easily have been).

> (and while you guys are waiting, I suggest you start a new thread  
> where
> you discuss some other inconsistency that would be easy to solve with
> more code in the interpreter, like why "-", "/", and "**" doesn't work
> for strings, lists don't have a "copy" method, sets and lists have
> different API:s for adding things, we have hex() and oct() but no  
> bin(),
> str.translate and unicode.translate take different arguments, etc.   
> get
> to work!)

Oh come on!  Comparing this with exponentiating strings is just not  
helpful.

Kind regards,

Alastair.

--
http://alastairs-place.net




More information about the Python-Dev mailing list