[Python-Dev] Re: PEP 326 now online

[Gustavo Niemeyer]

[has this message hit the list? I haven't received it]

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

Both of them.

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

Understood, but not agreed.

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

Please, let's not ignore how these usage cases differ in wideness.

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

It's not hard at all. It's just a matter of being worth.

> so cannot comment.  I'm also don't know if defining a __rcmp__ method
> would be sufficient.

How would two objects with rcmp react?

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

Let me explain. If you have code that is useful very ocasionally and is
implemented with three or four lines of code, the standard library is
not the place for it.

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

The best place to put useful examples is in the PEP itself. If you have
further examples of this, please include there. So far I haven't seen
any examples which are worth such implementation, as I've presented.

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

Neither of these points are isolated. They just sum to each other to make
my own opinion.

> 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

I'd like to be presented with some case where None is not enough,
preferably with some other argument besides "that's one or two lines
shorter", since having dozens of "shorter features" contradicts the
Python oposition to the Perl model.

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

Sorry. I'll try to explain that with softer words to avoid polluting our
discussion.

You're trying to introduce a new structure in the language just to turn
these usage cases into slightly more readable code (in your opinion)
but at the same time you don't want to use the features already in the
language which would turn your own example into more readable code and
would kill the need for the new presented structures.

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

Using examples which are better written in a more clear way inside a PEP
which is purposing a structure for better readability of code is not a
good way to convince people.

-- 
Gustavo Niemeyer
http://niemeyer.net