On 7 Dec 2006, at 01:01, Josiah Carlson wrote:
> *We* may not be confused, but it's not about us (I'm personally
> happy to
> use the .group() interface); it's about relative newbies who,
> generally
> speaking, desire/need consistency (see [1] for a paper showing that
> certain kinds of inconsistancies are bad - at least in terms of
> grading
> - for new computer science students). Being inconsistant because it's
> *easy*, is what I consider silly. We've got the brains, we've got the
> time, if we want slicing, lets produce a match object.
Oh, it isn't that I don't want to produce a match object; I think
you've mistaken my intention in that respect. I'd be equally happy
for it to be a match object, *but*...
> If we don't want
> slicing, or if prodicing a slice would produce a semantically
> questionable state, then lets not do it.
...if you return match objects from slicing, you have problems like m
[::-1].groups(). *I* don't know what that should return.
What led me to think that a tuple or list would be appropriate is the
idea that slicing was a useful operation and that I felt it was
unlikely that anyone would want to call the match object methods on a
slice, coupled with the fact that slices clearly have problems with
some of the match object methods. A match object, plus sequence
functionality, minus match object methods, is basically just a sequence.
If you're worried about types, you could do something like this:
generic match object
|
+--------------+-------------+
| |
real match object match object slice
where the "generic match object" perhaps doesn't have all the methods
that a "real match object" would have. (In the extreme case, generic
match object might basically just be a sequence type.)
Then slicing something that was a "generic match object" always gives
you a "generic match object", but it might not support all the
methods that the original match object supported.
> Half-assing it is a waste.
Sure. We're agreed there :-)
>> Look, I give in. There's no point trying to convince any of you
>> further, and I don't have the time or energy to press the point.
>> Implement it as you will. If necessary it can be an extension of my
>> "re" replacement that slicing is supported on match objects.
>
> I'm sorry to see you give up so easily. One thing to realize/remember
> is that basically everyone who frequents python-dev has their own
> "make
> life easier" function/class library for those things that have been
> rejected for general inclusion in Python.
It's just that I'm tired and have lots of other things that need
doing as well. Maybe I do have a bit more time to talk about it,
we'll see.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
