I support PEP 326

[Gary Robinson]

I've recently had a couple of cases of needing exactly what it proposes, and
having to kluge around the fact that it's not there. It's a great idea.

If there anywhere else I should be expressing my opinion on this, let me
know.

--Gary

--
Putting http://wecanstopspam.org in your email helps it pass through
overzealous spam filters.

Gary Robinson
CEO
Transpose, LLC
(e-mail address removed)
207-942-3463
Company: http://www.transpose.com
Blog: http://www.garyrobinson.net

 

[John Roth]

I've recently had a couple of cases of needing exactly what it proposes, and
having to kluge around the fact that it's not there. It's a great idea.

If there anywhere else I should be expressing my opinion on this, let me
know.

Just in case anyone can't find the PEP - it's the one that proposes
specific objects that will always sort highest and lowest.

I'm mildly in favor; it seems to be useful for some cases, and it
also seems easy enough to do. Of course, it would make None
the second smallest object.

John Roth

 

[Josiah Carlson]

I've recently had a couple of cases of needing exactly what it proposes, and

having to kluge around the fact that it's not there. It's a great idea.

If there anywhere else I should be expressing my opinion on this, let me
know.

Gary,

I'm glad you like my PEP. In general, many other people have found the
objects to be a useful addition. Seemingly the only stalling point is
where the Max/Min values are going to be placed, and what they should be
called. If you feel like looking at a listing of the possible locations
and names, check the previous version in cvs:
http://cvs.sourceforge.net/viewcvs..../pep-0326.txt?content-type=text/plain&rev=1.2

The listing was removed in the latest version because it detracted from
the specific functionality, which is more important than location. If
you feel like posting your exact use for the Max/Min value, that would
be great.

- Josiah

 

[Erik Max Francis]

I've recently had a couple of cases of needing exactly what it
proposes, and
having to kluge around the fact that it's not there. It's a great
idea.

If there anywhere else I should be expressing my opinion on this, let
me
know.

Seems quite reasonable to me. The only issue I'd take with it is the
choice of Min and Max for the names of the singletons; they're a little
too close to the functions min and max, which obviously they're both
likely to be used with. I would suggest something a little more verbose
such as Minimum and Maximum, or if you want to get silly, Infimum and
Supremum.

 

[Roy Smith]

Seems quite reasonable to me. The only issue I'd take with it is the
choice of Min and Max for the names of the singletons; they're a little
too close to the functions min and max, which obviously they're both
likely to be used with. I would suggest something a little more verbose
such as Minimum and Maximum, or if you want to get silly, Infimum and
Supremum.

I suppose you could special-case min() and max() to return the
appropriate singletons if called with no arguments.

There's something very nice about that. There's also something very
ugly about it. I'm having a hard time deciding which is stronger

 

[David M. Cooke]

Seems quite reasonable to me. The only issue I'd take with it is the
choice of Min and Max for the names of the singletons; they're a little
too close to the functions min and max, which obviously they're both
likely to be used with. I would suggest something a little more verbose
such as Minimum and Maximum, or if you want to get silly, Infimum and
Supremum.

Or, expressing the idea that they're the ends of a number line:

PosInf, NegInf
PosInfinity, NegInfinity
PositiveInfinity, NegativeInfinity

If IEEE floating point was done correctly everywhere, I'd say make
them the corresponding floating-point constants (Inf+ and Inf-).

Or,
FreakingHuge, FreakingHugeTheOtherWay

 

[Erik Max Francis]

Or, expressing the idea that they're the ends of a number line:

PosInf, NegInf
PosInfinity, NegInfinity
PositiveInfinity, NegativeInfinity

If IEEE floating point was done correctly everywhere, I'd say make
them the corresponding floating-point constants (Inf+ and Inf-).

The "if" conditional here is bad. Naming something "infinity" if it
weren't the IEEE floating point constants as well would be seriously
misleading.

After all, this _isn't_ a number line since we're talking about
comparing arbitrary objects.

Or,
FreakingHuge, FreakingHugeTheOtherWay

Don't be silly; that latter one should be FreakingUnhuge .

 

[Josiah Carlson]

Or, expressing the idea that they're the ends of a number line:

PosInf, NegInf
PosInfinity, NegInfinity
PositiveInfinity, NegativeInfinity

If IEEE floating point was done correctly everywhere, I'd say make
them the corresponding floating-point constants (Inf+ and Inf-).

Or,
FreakingHuge, FreakingHugeTheOtherWay

PosInf, NegInf
PosInfinity, NegInfinity
PositiveInfinity, NegativeInfinity

All suggest that the Max and Min (or whatever you want to call them) are
numbers. Such a thing is misleading, and also tends to tie PEP 326 with
PEP 754 (IEEE 754 Floating Point Special Values, which makes the case
for a consistant name for +/- FP Infinity).

As stated in my PEP:

Guido has brought up [2]_ the fact that there exists two constants
that can be used in the interim for maximum values: sys.maxint and
floating point positive infinity (1e309 will evaluate to positive
infinity). However, each has their drawbacks.

- On most architectures sys.maxint is arbitrarily small (2**31-1 or
2**63-1) and can be easily eclipsed by large 'long' integers or
floating point numbers.

- Comparing long integers larger than the largest floating point
number representable against any float will result in an exception
being raised::
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to float

Even when large integers are compared against positive infinity::
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to float

- These same drawbacks exist when numbers are small.

 

[Roy Smith]

The "if" conditional here is bad. Naming something "infinity" if it
weren't the IEEE floating point constants as well would be seriously
misleading.

After all, this _isn't_ a number line since we're talking about
comparing arbitrary objects.


Don't be silly; that latter one should be FreakingUnhuge .

You could name them Python and Perl. Then you could do stuff like:

for language in allLanguages:
if Perl < language < Python:
print language, "is more than Perl but less than Python"

 

[Josiah Carlson]

I suppose you could special-case min() and max() to return the

appropriate singletons if called with no arguments.

There's something very nice about that. There's also something very
ugly about it. I'm having a hard time deciding which is stronger

That behavior was called very bad names by Guido. We shall not speak of
it any longer. Heh.

- Josiah

 

[Andrew Koenig]

I suppose you could special-case min() and max() to return the

appropriate singletons if called with no arguments.

There's something very nice about that. There's also something very
ugly about it. I'm having a hard time deciding which is stronger

I'm afraid it's not right, because calling min() with no arguments should
return Max and calling max() with no arguments should return Min.

This behavior is correct because it preserves the intuitive property that if
s1 and s2 are (possibly empty) sequences, min(min(s1),min(s2)) should be
equal to min(s1+s2), and similarly for max. If you like, Max is the
identity element for min and Min is the identity element for max.

 

[Paul Prescod]

I'm afraid it's not right, because calling min() with no arguments should
return Max and calling max() with no arguments should return Min.

This behavior is correct because it preserves the intuitive property that if
s1 and s2 are (possibly empty) sequences, min(min(s1),min(s2)) should be
equal to min(s1+s2), and similarly for max. If you like, Max is the
identity element for min and Min is the identity element for max.

Calling min with no arguments need not be the same as calling it with an
empty sequence argument. That is not necessarily an argument for making
the empty function call return something arguably strange...

Paul Prescod

 

[Erik Max Francis]

Calling min with no arguments need not be the same as calling it with
an
empty sequence argument.

Since min(S) and min(*S) behave identically, I submit to you that they
_should_ be.

 

[John Roth]

Or, expressing the idea that they're the ends of a number line:

PosInf, NegInf
PosInfinity, NegInfinity
PositiveInfinity, NegativeInfinity

If IEEE floating point was done correctly everywhere, I'd say make
them the corresponding floating-point constants (Inf+ and Inf-).

If you do that you lose the ability to have those two constants be
in a list that *also* has end delimiters. A large part of the proposal
is that the end delimiters shouldn't have any other meaning: in other
words, there's no rational reason to use them in any other context
than ordering. (People will always come up with irrational reasons,
of course.) [grin]

John Roth

 

[A.Schmolck]

Since min(S) and min(*S) behave identically, I submit to you that they
_should_ be.

They don't. (See bottom for example).

'as

min([[1]]) [1]
min(*[[1]])

1

 

[Josiah Carlson]

Highest and Lowest?

Regards. Mel.[/QUOTE]

That was a suggestion, as was High and Low. I removed potential
locations because it detracts from the main focus of the PEP, the
existance of the objects.
- Josiah

 

[Andrew Koenig]

Calling min with no arguments need not be the same as calling it with an

empty sequence argument. That is not necessarily an argument for making
the empty function call return something arguably strange...

Having min() and min([]) return different values is also arguably strange.

 

[A. Lloyd Flanagan]

Just in case anyone can't find the PEP - it's the one that proposes
specific objects that will always sort highest and lowest.

I'm mildly in favor; it seems to be useful for some cases, and it
also seems easy enough to do. Of course, it would make None
the second smallest object.

John Roth

+1 on the PEP. The names Max and Min seem fine to me, but I'm not
married to them.

What would be the consequence of making Min and None compare equal?
Then the "None as second lowest" issue goes away. I can't think of an
example where that would cause problems, but there probably are
some...

 

[Josiah Carlson]

+1 on the PEP. The names Max and Min seem fine to me, but I'm not
married to them.

What would be the consequence of making Min and None compare equal?
Then the "None as second lowest" issue goes away. I can't think of an
example where that would cause problems, but there probably are
some...

The issue is that when Min and None are in a sequence that gets sorted,
you can end up with Minimums and Nones getting interspersed like so:
[Min, None, Min...]

In general, that behavior is frowned upon.

- Josiah

 

[Andrew Koenig]

The issue is that when Min and None are in a sequence that gets sorted,

you can end up with Minimums and Nones getting interspersed like so:
[Min, None, Min...]

If Min and None were two different names for the same object, such behavior
would be moot.
However, the following anomalies might then appear:
None

(after all, if they're the same object, how is the interpreter to know which
print name to use?)