> > I just got a comment from another user suggesting modifying the > > min/max.__cmp__ so that they are the actual minimum and maximum. > > > > An interesting approach, which makes some sense to me. Not to me. Random reuses like this would make Python into a mysterious language. > This was my suggestion. I am for this PEP and am willing to write the > reference implementation for the new min and max builtins if there's > enough interest. Not from me -- don't waste your time. > I have, like some others here, used my own One True Large Object. I > think the best reason to have One True Large Object is because you > can't really compare two implementations of the One True Large Object > and expect to get a meaningful result out of it. > > For the record, my use case had to do with a giant sorted list of > tuples and the bisect module. The first element of a tuple was a > timestamp, the rest of the tuple isn't worth explaining but I never > wanted to compare against it. The "database" had two primary > operations, inserting records *after* a timestamp, and finding every > record between two timestamps. Let's take a look: Your example (snipped here) seems to ask for a different kind of data structure, rather than an object larger than everything else. --Guido van Rossum (home page: http://www.python.org/~guido/)
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