[Python-Dev] Re: PEP 326 now online

[Josiah Carlson]

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

 - Josiah