[Python-ideas] Default return values to int and float

[Matt Joiner]

-1 to this idea unless it gives significant performance boosts for one or
more of the python implementations
On Oct 5, 2011 4:30 PM, "Ron Adam" <ron3200 at gmail.com> wrote:
> On Tue, 2011-10-04 at 19:21 -0700, Guido van Rossum wrote:
>> On Tue, Oct 4, 2011 at 4:13 PM, Steven D'Aprano <steve at pearwood.info>
wrote:
>> > Carl Matthew Johnson wrote:
>> >
>> >> This reminds me of the string.index vs. string.find discussion we had
>> >> a while back. In basically any situation where an exception can be
>> >> raised, it's sometimes nice to return a None-like value and sometimes
>> >> nice to have an out-of-band exception. I have a certain amount of
>> >> admiration for the pattern in Go of returning (value, error) from
>> >> most functions that might have an error, but for Python as it is
>> >> today, there's no One Obvious Way to Do It yet, and there's probably
>> >> none forthcoming.
>> >
>> > I beg to differ. Raising an exception *is* the One Obvious Way in
Python.
>> > But OOW does not mean "Only One Way", and the existence of raise
doesn't
>> > mean that there can't be a Second Not-So-Obvious Way, such as returning
a
>> > "not found" value.
>> >
>> > However, returning None as re.match does is better than returning -1 as
>> > str.find does, as -1 can be mistaken for a valid result but None can't
be.
>>
>> What works for re.match doesn't work for str.find. With re.match, the
>> result when cast to bool is true when there's a match and false when
>> there isn't. That's elegant.
>>
>> But with str.find, 0 is a legitimate result, so if we were to return
>> None there'd be *two* outcomes mapping to false: no match, or a match
>> at the start of the string, which is no good. Hence the -1: the intent
>> was that people should write "if s.find(x) >= 0" -- but clearly that
>> didn't work out either, it's too easy to forget the ">= 0" part. We
>> also have str.index which raised an exception, but people dislike
>> writing try/except blocks. We now have "if x in s" for situations
>> where you don't care where the match occurred, but unfortunately if
>> you need to check whether *and* where a match occurred, your options
>> are str.find (easy to forget the ">= 0" part), str.index (cumbersome
>> to write the try/except block), or "if x in s: i = s.index(x); ..."
>> which looks compact but does a redundant second linear search. (It is
>> also too attractive since it can be used without introducing a
>> variable.)
>>
>> Other ideas: returning some more structured object than an integer
>> (like re.match does) feels like overkill, and returning an (index,
>> success) tuple is begging for lots of mysterious occurrences of [0] or
>> [1].
>>
>> I'm out of ideas here. But of all these, str.find is probably still
>> the worst -- I've flagged bugs caused by it too many times to count.
>
> There is also the newer partition and rpartition methods, which I tend
> to forget about.
>
>
> I really don't like the '-1' for a not found case. They just get in the
> way.
>
>
> If len(s) was the not found case, you get a value that can be used in a
> slice without first checking the index, or catching an exception.
>
>>>> s[len(s):]
> ''
>
>
> Lets say we didn't have a split method and needed to write one.
>
> If s.find returned len(s) as the not found...
>
> def split(s, x):
> result = []
> start = 0
> while start < len(s):
> i = s.find(x, start)
> result.append(s[start:i]) # No check needed here.
> start = i + len(x)
> return result
>
> Of course you could you this same pattern for other things.
>
> cheers,
> Ron
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111005/b1e742c0/attachment.html>