I support PEP 326

[Jeremy Fincher]

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.

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

 

[Josiah Carlson]

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

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

 

[Josiah Carlson]

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.

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..../pep-0326.txt?content-type=text/plain&rev=1.2
), you suggestions are definitely appreciated.

Thank you,
- Josiah

 

[Heather Coppersmith]

On 27 Jan 2004 13:18:43 -0800,

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

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

Regards,
Heather

 

[Jeremy Fincher]

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.

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

 

[Anthony Baxter]

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.

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

 

[Gerrit Holl]

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.

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.

--
227. If any one deceive a barber, and have him mark a slave not for
sale with the sign of a slave, he shall be put to death, and buried in his
house. The barber shall swear: "I did not mark him wittingly," and shall
be guiltless.
-- 1780 BC, Hammurabi, Code of Law

 

[Skip Montanaro]

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

 

[Josiah Carlson]

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

 

[Jeremy Fincher]

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.

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

 

[Skip Montanaro]

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