On Mon, 2004-01-26 at 20:32, Josiah Carlson wrote: > What does everyone think of the following? > > A few people have suggested that the Max and Min objects be available as > the result of calls to max() and min(), this would solve the location > and name problem, and shouldn't break any old code. > > 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 > > > 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), > then replacing the TypeError exception for behavior 1 with the following > seems reasonable: > min() -> Min > max() -> Max I don't like it at all. min() (and max() ...) is supposed to return the smallest item from its arguments. Calling it with no arguments does not mean that we're trying to find the value that would be smaller than anything we passed to it, if we had passed something to it. It's just a programmer error. I haven't made any comment on the PEP 326 thread, so I'll offer my two cents and leave it at that. I can't recall ever needing a Min/Max object in eight years of Python programming. I admit its utility in some circumstances. It seems like a fine candidate for the Python Cookbook; perhaps if it sees widespread use we could consider putting it in the standard library one day. (And I'd call them bottom and top rather than min and max to avoid confusion with the functions.) Jeremy
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