[Python] I support PEP 326

As a matter of style wouldn't it be nice to refer to PEPs both by number
and by name? It is just a minor oversight but there is a tendency of
communities to migrate to refering to things just by numbers in a way
that excludes newcomers or hobbiests.

NOT directed at you in particular Gary!

Paul Prescod

What's PEP 326 again?

Jeremy

Sorry... it's a proposal that Python incorporates two singleton constants
that represent top and bottom values: Max and Min might be the names.

Max would be bigger than anything it's compared to and Min would be smaller.
It would be very convenient -- in code I was writing a week or two ago I was
thinking "wouldn't it be great if python had..." exactly what PEP 326
proposes. It would have saved... well... a few minutes. But those add up!

The PEP document gives a lot of examples of why it would be good.

http://www.python.org/peps/pep-0326.html

--Gary

"Gary Robinson" <grobinson at transpose.com> wrote in message
news:mailman.654.1074788734.12720.python-list at python.org...
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

"John Roth" <newsgroups at jhrothjr.com> wrote in message news:<10105bn3bsi63c9 at news.supernews.com>...
+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

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
None

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

Additionally, None comparing smaller than everything else is neither
intuitive, nor really documented (as reiterated a few times by a few
different people in python-dev). It was an arbitrary decision, but
better than None comparing larger than everything.

- Josiah

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.py/*checkout*/python/python/nondist/peps/pep-0326.txt?content-type=text%2Fplain&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

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.

In article <401081A1.E4C34F00 at alcyone.com>,
Erik Max Francis wrote:
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 :-)


From http Fri Jan 23 06:06:32 2004
From: http (Paul Rubin)
Date: 22 Jan 2004 21:06:32 -0800
Subject: cgi concurrency approaches?
Message-ID: <7x7jzjgso7.fsf@ruckus.brouhaha.com>

I'm wondering if folks here have favorite lightweight ways of dealing
with concurrency in cgi's. Take a simple case:

You want to write a cgi that implements a simple counter. The first
time it's called, it prints "1". The next time, "2", etc. The naive
implementation looks something like:

fd = open("counter.num", "rw")
n = int(fd.read())
fd.seek(0, 0)
fd.write("%d"% n+1)
print "Content-type: text/html\n\n"
print n

but of course there's the obvious race condition if two people hit the
cgi at the same time.

Fancier solutions include running an transactional database in another
process and connecting to it, setting up a daemon that remembers the
counter value in memory and serializes access through a socket that
the cgi opens, using a file-system specific hack like linking to
counter file to lock it, having a timeout/retry if the counter is
locked, with a possible hangup if a lock file gets left around by
accident, etc. Each is a big pain in the neck.

Anyone have some simpler approaches?

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

- Josiah

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

I agree with you that it's strange, but it's right. It might interest you
to know that APL has behaved the same way for more than 35 years. In APL,
the usual way of obtaining the largest positive value is to ask for the
lowest element of an empty sequence.

In Python, if you give min or max a single argument, it is assumed to be a
sequence, and if that sequence is empty, you get an exception. If you give
it more than one argument, those arguments are treated as elements of a
sequence, and you get an exception if there are no arguments (i.e. if the
sequence is empty).

Therefore, if min([]) were to return Max (which, although surprising, I
still think is reasonable), then min() should also return Max.

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

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

'as





















































[1]
1

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

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

--
/--------------------------------------------------------------------------\

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

In article <401091D5.EFA41F7 at alcyone.com>,
Erik Max Francis wrote:
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"

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.

In article <buq4ap$fsb$1 at news.service.uci.edu>,
Josiah Carlson wrote:
Highest and Lowest?

Regards. Mel.

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

"David M. Cooke" <cookedm+news at physics.mcmaster.ca> wrote in message
news:qnky8rzid3y.fsf at arbutus.physics.mcmaster.ca...
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
/--------------------------------------------------------------------------\

Gary Robinson <grobinson at transpose.com> wrote in message news:<mailman.654.1074788734.12720.python-list at python.org>...
I'm also in support of this PEP, and have cases in which I would use
the new singletons.

The biggest reason I believe the PEP should be accepted is that you
simply *can't* "roll your own" in a heterogenous environment. If I
have my Min/Max objects and you have your Min/Max objects, someone's
objects simply aren't going to work as expected.

I'm in favor of Minimum and Maximum, though, if only for ease in
discussing Python: the capital isn't obvious both verbally or at the
beginning of a properly written sentence.

Jeremy

Unfortunately, I have a feeling that the PEP may be killed because there
doesn't seem to be a location/name that is agreeable to those with
voting power in python-dev.

A new module included into the standard library seems to be the easiest
way to get it into Python. However, considering that you cannot
guarantee that the Max/Min will get their __cmp__ method called (when
comparing against user-defined classes), you cannot guarantee the ordering.

If it were to get special treatment, by including it as a pseudo-builtin
(always in Python, but doesn't have a name in __builtin__), it is a 5
line modification to PyObject_Compare in object.c to guarantee the
orderings with Max/Min:
http://mail.python.org/pipermail/python-dev/2004-January/042275.html


That email also makes a case for min() and max() returning the minimum
and maximum object respectively, whose string representations would be
'min()' and 'max()' respectively. It would result in the overloading of
the min and max functions, but there is no general consensus in
python-dev; some people like it due to its similarity to using int(),
list(), dict(), float(), str(), long(), etc., but others (including
Guido himself) think that min() and max() /should/ produce TypeErrors.

I'm thinking that maybe it should produce a warning for a release or two
(that it used to produce a TypeError, unless 'from future import
extremes' is at the beginning of a script), but in Python 2.5 or 2.6
remove the warning.

Yeah. If someone has a strong opinion either way, perhaps you should
comment in python-dev. If anyone has a better name/location suggestion,
(that is not listed as an option in the current or previous versions in CVS:
http://python.org/peps/pep-0326.html
http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/nondist/peps/pep-0326.txt?content-type=text%2Fplain&rev=1.2
), you suggestions are definitely appreciated.

Thank you,
- Josiah

Josiah Carlson <jcarlson at nospam.uci.edu> wrote in message news:<bv6ph8$181$1 at news.service.uci.edu>...
I simply can't understand this aversion to sticking useful things in
the builtin namespace. Especially when marginally useful things like
reversed (a trivially written 3-line generator) have been put there.

Jeremy

125

That's a _lot_ of stuff in one module. Even if you exclude the 40-odd
exceptions that are there, that's still a lot of guff in one big flat
namespace.

Anthony

Any plans to clean it up in Python 3.0?

In my opinion, a lot of builtins could either be deleted or moved into a
module:

buffer
complex -> to math
open (use file)
long
abs -> to math
apply -> use extended syntax
compile -> to sys
divmod -> to math
execfile -> to sys
filter, reduce -> to functional?
intern -> ?
map -> use list comp
oct/hex -> to math?
range/xrange (unify)
round -> to math

Gerrit.

Gerrit> Any plans to clean it up in Python 3.0?

Yes, there has been some discussion about this on python-dev. It doesn't
appear a PEP's been written yet.

Skip

Hey Skip,

I know you commented on the flat namespace of __builtin__, but I've not
seen any comments on PEP 326. Don't feel like you need to answer, but
what are your feelings on it (even if you hate the PEP and give it a -1,
you'll not hurt my feelings)?

- Josiah

Josiah> I know you commented on the flat namespace of __builtin__, but
Josiah> I've not seen any comments on PEP 326.

http://mail.python.org/pipermail/python-dev/2004-January/042308.html

I guess I don't sort() stuff enough...

Skip

Anthony Baxter <anthony at interlink.com.au> wrote in message news:<mailman.884.1075263037.12720.python-list at python.org>...
There certainly is, but are the mistakes of the past going to doom us
to put things in the wrong place until we get to clean it up? I think
the one appropriate place for the proposed constants is __builtins__,
for the obvious reasons that (a) all other singleton constants are
there (None, True, False) and (b) ease of implementation of cmp (with
Maximum and Minimum in __builtins__, it's a 5-line change, I read on
Python-dev).

Yes, __builtins__ is bloated, but as Mr. Holl mentioned, a significant
amount of it can be removed once Guido's willing to break
backwards-compatibility. But why make 3.0 even more
backwards-incompatible than it is now by sticking rightful builtins
somewhere else just to keep the builtin namespace artificially
smaller?

(Or consider this: as a native speaker of English, I have a working
vocabulary of tens of thousands of English words, and a non-working
vocabulary in the hundreds of thousands. Do people really believe
that the difference between 125 and 127 (or 150, or 200) builtins is
going to increase my cognitive load significantly?)

Jeremy

Sure they will: Mine is mymodule.Min; yours is yourmodule.Min.
Use "from import" at your own risk and peril.

Regards,
Heather