From: Aahz on
[Original not available on my swerver, responding here]

>On 7/11/10 10:03 PM, Nathan Rice wrote:
>>
>> Yeah, I long ago filed the in place place in the same folder as
>> strings-as-sequences, all() returning True for an empty iterable and any
>> returning True rather than the thing which triggered it.

Because I love to repeat myself:

"...string iteration isn't about treating strings as sequences of strings,
it's about treating strings as sequences of characters. The fact that
characters are also strings is the reason we have problems, but characters
are strings for other good reasons." --Aahz
http://mail.python.org/pipermail/python-3000/2006-April/000897.html

Do you really want to give up Python's lovely string-slicing
capabilities?
--
Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/

"....Normal is what cuts off your sixth finger and your tail..." --Siobhan
From: John Nagle on
On 7/13/2010 4:22 AM, Gregory Ewing wrote:
> John Nagle wrote:
>> Arguably, if a function just does a "return",
>> it should be an error to try to use its return value.
>
> It's been suggested at least once before that the
> default return value for a function should be some
> special value that raises an exception if you try
> to do anything with it except throw it away.

Treating that case as an error would be consistent with the
way attribute access works in Python. In Python, attempting
to access a nonexistent attribute raises an exception. In
Javascript, that returns a null. Javascript makes no
distinction between "null" and "nonexistent", but Python
does.

It's un-Pythonic and inconsistent that functions which
return nothing are considered to return a None object.

John Nagle