On Thu, Mar 10, 2005 at 10:22:45PM -0500, Raymond Hettinger wrote: > [Bill Janssen] > > I think I'd want them to be: > > > > def any(S): > > for x in S: > > if x: > > return x > > return S[-1] > > > > def all(S): > > for x in S: > > if not x: > > return x > > return S[-1] > > > > Or perhaps these should be called "first" and "last". > > -1 > > Over time, I've gotten feedback about these and other itertools recipes. > No one has objected to the True/False return values in those recipes or > in Guido's version. > > Guido's version matches the normal expectation of any/all being a > predicate. Also, it avoids the kind of errors/confusion that people > currently experience with Python's unique implementation of "and" and > "or". > > Returning the last element is not evil; it's just weird, unexpected, and > non-obvious. Resist the urge to get tricky with this one.
Perl returns the last true/false value as well, and it is a subtle trap. I worked at a perl shop that had a long style guide which outlawed using that side effect but people did anyway. I'm +1 on having it return a true boolean for the same reason "if (x = calc_foo()):" isn't supported, if there is a quirky side effect available someone will use it and someone else won't notice. [in fact we had a guy who was "downsized" for doing things like calling database queries on the return value of a function that was documented as returning True/False] Perl shops require long style guides becuase perl is, ummm, perl. Python is a boon because YAGN (a style guide). The fewer side effects the better. -Jack _______________________________________________ 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
