[Python-Dev] Re: PEP 326 now online

[Gustavo Niemeyer]

> [...]
> > My suggestion is to not introduce these objects at all, and if they're
> > going to be introduced, there should be internal support for them in the
> > interpreter, or they're meaningless. Every object with a custom cmp
> > method would have to take care not to be greater than your objects.
> 
> Interpretation:
> You are -1 on the PEP in general.  If it does get introduced, then you
> are +1 on there being a special case in the interpreter for when Min or
> Max are in the comparison.

That's it.

> If given the proper values for PyMinObject and PyMaxObject (quite the
> large 'if given'), it is an 5 line modification to PyObject_Compare in
> object.c:
[...]

I know it's easy, I just don't think it's worth. Anyway, you've
explained it in the above sentence.

> > Comments about the "Max Examples":
> > 
> > - If the objects in the sequence implement their own cmp operator, you
> >   can't be sure your example will work. That turns these structures
> >   (call them as you want) into something useless.
> 
> 
> Those who want to use Max and/or Min, and want to implement their own
> cmp operator - which uses non-standard behavior when comparing against Max
> and/or Min - may have to deal with special cases involving Max and/or
> Min.
> 
> This makes sense because it is the same deal with any value or object
> you want to result in non-standard behavior.  If people want a special
> case, then they must write the special case.

What I mean is that I'd have to review every generic class I ever
wrote which is supposed to be compatible with the standard library
to check if they're compatible with Min/Max. I don't like this
approach, but that's just my opinion.

> > - "Max" is a possible return from this function. It means the code using
> >   your "findmin_Max" will have to "if foo == Max" somewhere, so it kills
> >   your argument of less code as well.
> 
> No, it doesn't.
> min(a, Max) will always return a.

Interesting, you say that it doesn't, but...

> I should have included a test for empty sequences as an argument in
> order to differentiate between empty sequences and sequences that have
> (0, None, Max) as their actual minimum values (in the related code
> snippets).
> 
> This results in the simplification of the (0, None) examples into one,
> but introduces an index variable and sequence lookups for the general
> case:
[...]
> Now they both have the same number of lines, but I find the second one
> a bit clearer due its lack of sequence indexing.

... you actually agree. :-)

> > [...]
> > > An even better question would be, "How would two objects with __cmp__
> > > react?"  Checking a few examples, it is whoever is on the left side of
> > > the comparison operator.
> > 
> > Exactly. That's the point. Your "Top" value is not really "Top", unless
> > every object with custom comparison methods take care about it.
> 
> Certainly anyone who wants to use Max/Min may have to take care to use
> it properly.  How is this any different from the way we program with any
> other special values?

I don't want to use them, but I'd have to be careful so that other
people might use them. Again, I don't like this approach.

[...]
> One of 3 cases would occur:
> 1. If Max and Min are in the standard distribution, then the people who
> use it, would write code that is compatible with it (ok).

Wrong. People which use Max/Min might be unaware that they must take
care when building __cmp__ so that their classes are compatible with
Min/Max.

> 2. Those that have no need for such extreme values will never write code
> that /could/ be incompatible with it (ok).

Wrong. Those that have no need for such extreme values will have even
more chances to do that.

> 3. Those that don't know about Max/Min, or write their own
> implementations that overlap with included Python functionality, would
> not be supported (ok) (I hope the reasons for this are obvious, if they
> are not, I will clarify).

Same case.

> In any case, the PEP describes the behavior and argues about the
> creation of the "One True Implementation of the One True Maximum Value
> and One True Minimum Value", and including it in the standard Python
> distribution in a reasonable location, with a name that is intuitive.

Ok, and I thank you for you patience defending the matter. Opinions
diverge, and the divergences should be explained. Once everyone is
aware about the issues, someone will have to decide if it is
implemented or not (I'm glad it's not my job :-).

> I like your optimization of comparisons to None, but the real difference
> between using None and Max in the node elements are the following:
[...]

Oops.. the real difference is exposed with any alternative
implementation. Introducing code which "emulates" your own
scheme is pretty tendentious.

> Out of curiosity, why did you use cmp(*pair)*-1 and not -cmp(*pair)?

Because that's the first implementation that came into my mind.

-- 
Gustavo Niemeyer
http://niemeyer.net