I support PEP 326

[Mel Wilson]

Re: I support PEP 326

In article <buq4ap$fsb$1@n ews.service.uci .edu>,
Josiah Carlson <jcarlson@nospa m.uci.edu> wrote:[color=blue][color=green]
>> Or, expressing the idea that they're the ends of a number line:
>>
>> PosInf, NegInf
>> PosInfinity, NegInfinity
>> PositiveInfinit y, NegativeInfinit y[/color][/color]

Highest and Lowest?

Regards. Mel.

[Josiah Carlson]

Re: I support PEP 326

Mel Wilson wrote:[color=blue]
> In article <buq4ap$fsb$1@n ews.service.uci .edu>,
> Josiah Carlson <jcarlson@nospa m.uci.edu> wrote:
>[color=green][color=darkred]
>>>Or, expressing the idea that they're the ends of a number line:
>>>
>>>PosInf, NegInf
>>>PosInfinit y, NegInfinity
>>>PositiveInfi nity, NegativeInfinit y[/color][/color]
>
>
> Highest and Lowest?
>
> Regards. Mel.[/color]

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]

Re: I support PEP 326

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

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

[A. Lloyd Flanagan]

Re: I support PEP 326

"John Roth" <newsgroups@jhr othjr.com> wrote in message news:<10105bn3b si63c9@news.sup ernews.com>...
[color=blue]
> 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[/color]

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

Re: I support PEP 326

[color=blue]
> +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...[/color]

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]

Re: I support PEP 326

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

If Min and None were two different names for the same object, such behavior
would be moot.
However, the following anomalies might then appear:
[color=blue][color=green][color=darkred]
>>> None[/color][/color][/color]
None[color=blue][color=green][color=darkred]
>>> Min[/color][/color][/color]
None

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

[Jeremy Fincher]

Re: I support PEP 326

Gary Robinson <grobinson@tran spose.com> wrote in message news:<mailman.6 54.1074788734.1 2720.python-list@python.org >...[color=blue]
> 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.[/color]

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]

Re: I support PEP 326

Andrew Koenig wrote:[color=blue][color=green]
>>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...][/color]
>
>
> If Min and None were two different names for the same object, such behavior
> would be moot.
> However, the following anomalies might then appear:
>[color=green][color=darkred]
> >>> None[/color][/color]
> None[color=green][color=darkred]
> >>> Min[/color][/color]
> None
>
> (after all, if they're the same object, how is the interpreter to know which
> print name to use?)[/color]

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]

Re: I support PEP 326

> I'm also in support of this PEP, and have cases in which I would use[color=blue]
> 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.[/color]

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

[Heather Coppersmith]

Re: I support PEP 326

On 27 Jan 2004 13:18:43 -0800,
tweedgeezer@hot mail.com (Jeremy Fincher) wrote:
[color=blue]
> ... 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.[/color]

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

Regards,
Heather

--
Heather Coppersmith
That's not right; that's not even wrong. -- Wolfgang Pauli

[Jeremy Fincher]

Re: I support PEP 326

Josiah Carlson <jcarlson@nospa m.uci.edu> wrote in message news:<bv6ph8$18 1$1@news.servic e.uci.edu>...[color=blue]
> 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.[/color]

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]

Re: I support PEP 326

[color=blue][color=green][color=darkred]
>>> Jeremy Fincher wrote[/color][/color]
> 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.[/color]
[color=blue][color=green][color=darkred]
>>> len(dir(__built ins__))[/color][/color][/color]
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]

Re: I support PEP 326

Anthony Baxter wrote:[color=blue][color=green][color=darkred]
> >>> len(dir(__built ins__))[/color][/color]
> 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.[/color]

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
--
PrePEP: Builtin path type

http://people.nl.linux.org/~gerrit/creaties/path/pep-xxxx.html

Asperger's Syndrome - a personal approach:

http://people.nl.linux.org/~gerrit/english/

[Skip Montanaro]

Re: I support PEP 326

[color=blue][color=green]
>> 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.[/color][/color]

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]

Re: I support PEP 326

Skip Montanaro wrote:[color=blue][color=green][color=darkred]
> >> 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.[/color][/color]
>
> 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[/color]

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