Josiah Carlson wrote:
> Current behavior of min and max:
> 1. without arguments raises a TypeError
> 2. with a single non-sequence argument raises a TypeError
> 3. with an empty sequence as an argument raises a ValueError
> 4. with one argument that is a non-empty sequence returns the min or max
> of the sequence
> 5. with more than one argument returns the min or max of *args
To be more precise: not sequence but iterable:
>>> def f():
... yield 1; yield 2; yield 3
...
>>> max(f())
3
> If we assume that no one is calling min or max without arguments in
> order to raise a TypeError (which seems like a reasonable assumption),
I'm not sure. Suppose I collect a number of things in a collection and
pass it to max with *: max(*mycollection). If, by error, mycollection is
empty, I want a TypeError, not a silent failure because it suddenly
started returning an object. Of course, I shouldn't use the '*' form
then, but I think it's a realistic scenario.
> then replacing the TypeError exception for behavior 1 with the following
> seems reasonable:
> min() -> Min
> max() -> Max
I don't think I like this solution. I do like the idea of min/max, and
had a recent use case when writing an Interval type, but I builtin type
with a good name. I think 'extreme' would be a good name, where
'extreme(True)' would return an object behaving like Highest and
'extreme(False)' would return an object behaving like Lowest.
yours,
Gerrit.
--
246. If a man hire an ox, and he break its leg or cut the ligament of
its neck, he shall compensate the owner with ox for ox.
-- 1780 BC, Hammurabi, Code of Law
--
PrePEP: Builtin path type
http://people.nl.linux.org/~gerrit/creaties/path/pep-xxxx.html
Asperger's Syndrome - a personal approach:
http://people.nl.linux.org/~gerrit/english/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4