
On Sat, 2005-08-27 at 10:16 -0700, Josiah Carlson wrote:
Guido van Rossum <gvanrossum@gmail.com> wrote: [...] Oh, there's a good thing to bring up; regular expressions! re.search returns a match object on success, None on failure. With this "failure -> Exception" idea, shouldn't they raise exceptions instead? And goodness, defining a good regular expression can be quite hard, possibly leading to not insignificant "my regular expression doesn't do what I want it to do" bugs. Just look at all of those escape sequences and the syntax! It's enough to make a new user of Python gasp.
I think re.match() returning None is an example of 1b (as categorised by Terry Reedy). In this particular case a 1b style response is OK. Why; 1) any successful match evaluates to "True", and None evaluates to "False". This allows simple code like; if myreg.match(s): do something. Note you can't do this for find, as 0 is a successful "find" and evaluates to False, whereas other results including -1 evaluate to True. Even worse, -1 is a valid index. 2) exceptions are for unexpected events, where unexpected means "much less likely than other possibilities". The re.match() operation asks "does this match this", which implies you have an about even chance of not matching... ie a failure to match is not unexpected. The result None makes sense... "what match did we get? None, OK". For str.index() you are asking "give me the index of this inside this", which implies you expect it to be in there... ie not finding it _is_ unexpected, and should raise an exception. Note that re.match() returning None will raise exceptions if the rest of your code doesn't expect it; index = myreg.match(s).start() tail = s[index:] This will raise an exception if there was no match. Unlike str.find(); index = s.find(r) tail = s[index:] Which will happily return the last character if there was no match. This is why find() should return None instead of -1.
With the existance of literally thousands of uses of .find and .rfind in the wild, any removal consideration should be weighed heavily - which honestly doesn't seem to be the case here with the ~15 minute reply time yesterday (just my observation and opinion). If you had been ruminating over this previously, great, but that did not seem clear to me in your original reply to Terry Reedy.
bare in mind they are talking about Python 3.0... I think :-) -- Donovan Baarda <abo@minkirri.apana.org.au> http://minkirri.apana.org.au/~abo/