RetroSearch Browse

Fri Jan 9 12:40:51 EST 2004 · https://mail.python.org/pipermail/python-dev/2004-January/041858.html

> I don't know about that; until this thread, I've basically agreed with
> every direction Python has gone in the 5 years since I started using it,
> but that is a one-way relationship.

I think this shouldn't be added to the standard library at all, for a
few reasons:

- All given examples in the PEP are easily rewritable with existent
  logic (and I disagree that the new method would be easier to
  understand);

- I can't think about any real usage cases for such object which
  couldn't be easily done without it;

- The "One True Large Object" isn't "True Large" at all, since depending
  on the comparison order, another object might belive itself to be
  larger than this object. If this was to be implemented as a supported
  feature, Python should special case it internally to support the
  "True" in the given name.

- It's possible to implement that object with a couple of lines, as
  you've shown;

- Any string is already a maximum object for any int/long comparison
  (IOW, do "cmp.high = 'My One True Large Object'" and you're done).

- Your Dijkstra example is a case of abusement of tuple's sorting
  behavior. If you want readable code as you suggest, try implementing
  a custom object with a comparison operator, instead of writting
  "foo = (a,b,c,d)", and "(a,b,c,d) = foo", and "foo[x][y]" all over
  the place.

-- 
Gustavo Niemeyer
http://niemeyer.net

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-January/041858.html below:

[Python-Dev] Re: PEP 326 now online