[Python-Dev] Re: PEP 326 now online (original) (raw)

Josiah Carlson jcarlson at uci.edu
Fri Jan 9 15:29:38 EST 2004

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

You are free to disagree that two objects, which clearly state that they are either the largest or smallest objects, are not clear. I don't know how to address your concern.

In terms of the names for such objects, as well as their locations being good and descriptive, that is still an open issue, and is listed as such in the latest version of the PEP, which is available at http://www.python.org/peps/pep-0326.html

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

It is not whether "if we don't have it we can do it easy", it is about "if we have it, we can do it easier". The Queue module, just recently brought up, is one of those examples where having it for interthread communication is invaluable. Sure, everyone could write their own threaded Queue class when needed, but having it there to use is nice.

Arguably, there aren't any usage cases where None is necessary. But yet we have None.

Which is preferable:

_mynone = [] def foo(arg=_mynone): if id(arg) == id(_mynone): #equivalent to None pass

def goo(arg=None): if arg is None: pass

Again, it is not about "can we do it easy without", it is "can we do it easier with".

- 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.

I don't know how difficult modifying the comparison function to test whether or not one object in the comparison is the universal max or min, so cannot comment. I'm also don't know if defining a rcmp method would be sufficient.

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

I don't see how the length of the implementation has anything to do with how useful it is. I (and others) have provided examples of where they would be useful. If you care to see more, we can discuss this further off-list.

- 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).

That also ignores the idea of an absolute minimum. There are two parts of the proposal, a Maximum and a Minimum. The existance of which has already been agreed upon as being useful. Whether they are in the standard library, standard language, or otherwise, and what name they will have, are all currently open issues. A few options are listed in the Open Issues portion of the PEP, in not so many words.

- 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.

I don't see how using the features of a data structure already in the standard language is "abuse". Perhaps I should have created my own custom class that held all the relevant information, included a cmp method, added attribute access and set rutines ...OR... maybe it was reasonable that I used a tuple and saved people the pain of looking through twice as much source, just to see a class, that has nothing to do with the PEP.

More information about the Python-Dev mailing list