Mailman 3 Smallest/Largest singletons - Python-ideas

newer
A Wiki-style documentation with an...

Smallest/Largest singletons

George Sakkis

10 Nov 2008 10 Nov '08

4:46 p.m.

One small side-effect of not being able to compare incompatible types in 3.0 is that None cannot be used any more as the smallest element. Yes this has always been an implementation artifact and a hack, but it was very convenient none the less. Is it maybe the right time to add a builtin Smallest (and also Largest) object, i.e. two singletons so that `Smallest < x` for every x: x is not Smallest and `Largest > x` for every x: x is not Largest ? Although it's not hard to define them in pure Python and one could object with "not every n-liner needs to be a builtin", the main added value is that these will be endorsed as the standard, otherwise we risk mymodule.Smallest clashing with with yourmodule.Smallest. George

Attachments:

attachment.htm (text/html — 755 bytes)

Show replies by date

Scott Dial

14 Nov 14 Nov

7:25 a.m.

George Sakkis wrote:

...

One small side-effect of not being able to compare incompatible types in 3.0 is that None cannot be used any more as the smallest element. Yes this has always been an implementation artifact and a hack, but it was very convenient none the less. Is it maybe the right time to add a builtin Smallest (and also Largest) object, i.e. two singletons so that `Smallest < x` for every x: x is not Smallest and `Largest > x` for every x: x is not Largest ? Although it's not hard to define them in pure Python and one could object with "not every n-liner needs to be a builtin", the main added value is that these will be endorsed as the standard, otherwise we risk mymodule.Smallest clashing with with yourmodule.Smallest.

You can more-or-less take all of the replies to the thread about a blessed "__missing__" object and apply them to "Smallest"/"Largest". Using special objects to be lazy with your algorithm will never be wise. Eventually, someone will use them to mean something else entirely. It's almost always better to avoid using special objects or to roll-your-own (so that nobody can use it unexpectedly). Furthermore, preloading an output value with a nonsense value like "Smallest" or "Largest" is just asking for it to get leaked accidentally (the same problem exists with preloading None). -1 Let's not provide features for misguided programming idioms. -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu

Josiah Carlson

16 Nov 16 Nov

10:33 p.m.

On Thu, Nov 13, 2008 at 11:25 PM, Scott Dial wrote:

...

George Sakkis wrote:

...
One small side-effect of not being able to compare incompatible types in 3.0 is that None cannot be used any more as the smallest element. Yes this has always been an implementation artifact and a hack, but it was very convenient none the less. Is it maybe the right time to add a builtin Smallest (and also Largest) object, i.e. two singletons so that `Smallest < x` for every x: x is not Smallest and `Largest > x` for every x: x is not Largest ? Although it's not hard to define them in pure Python and one could object with "not every n-liner needs to be a builtin", the main added value is that these will be endorsed as the standard, otherwise we risk mymodule.Smallest clashing with with yourmodule.Smallest.

You can more-or-less take all of the replies to the thread about a blessed "__missing__" object and apply them to "Smallest"/"Largest". Using special objects to be lazy with your algorithm will never be wise. Eventually, someone will use them to mean something else entirely. It's almost always better to avoid using special objects or to roll-your-own (so that nobody can use it unexpectedly). Furthermore, preloading an output value with a nonsense value like "Smallest" or "Largest" is just asking for it to get leaked accidentally (the same problem exists with preloading None).

-1 Let's not provide features for misguided programming idioms.

See PEP 326. Unless additional motivations are presented, I'm going to have to be -1 as well (despite 326 being my PEP). - Josiah

George Sakkis

17 Nov 17 Nov

1:21 a.m.

On Sun, Nov 16, 2008 at 5:33 PM, Josiah Carlson wrote: On Thu, Nov 13, 2008 at 11:25 PM, Scott Dial

...

> wrote:

...
George Sakkis wrote:

...
One small side-effect of not being able to compare incompatible types in 3.0 is that None cannot be used any more as the smallest element. Yes this has always been an implementation artifact and a hack, but it was very convenient none the less. Is it maybe the right time to add a builtin Smallest (and also Largest) object, i.e. two singletons so that `Smallest < x` for every x: x is not Smallest and `Largest > x` for every x: x is not Largest ? Although it's not hard to define them in pure Python and one could object with "not every n-liner needs to be a builtin", the main added value is that these will be endorsed as the standard, otherwise we risk mymodule.Smallest clashing with with yourmodule.Smallest.

You can more-or-less take all of the replies to the thread about a blessed "__missing__" object and apply them to "Smallest"/"Largest". Using special objects to be lazy with your algorithm will never be wise.

s/lazy/elegant

...

Eventually, someone will use them to mean something else entirely. It's almost always better to avoid using special objects or to roll-your-own (so that nobody can use it unexpectedly). Furthermore, preloading an output value with a nonsense value like "Smallest" or "Largest" is just asking for it to get leaked accidentally (the same problem exists with preloading None).

-1 Let's not provide features for misguided programming idioms.

I don't consider Dijkstra's shortest path algorithm and the others mentioned in PEP 326 as examples of misguided programming idioms. See PEP 326. Unless additional motivations are presented, I'm going

...

to have to be -1 as well (despite 326 being my PEP).

The additional motivation since the PEP is that the None hack (as equivalent to Smallest) cannot be used anymore in 3.x, and I'm sure I'm not the only one using it. Besides, the reasons for rejection read more like a lukewarm -0 ("not that useful, easily implemented, can't decide on a name"), not a strong "this is silly" -1. George

Scott Dial

2:21 a.m.

George Sakkis wrote:

...

...
Using special objects to be lazy with your algorithm will never be wise.

s/lazy/elegant

To each his own, but your substitution fails to convince me that magic values are more readable than using a "valid" flag variable.

...

...
-1 Let's not provide features for misguided programming idioms.

I don't consider Dijkstra's shortest path algorithm and the others mentioned in PEP 326 as examples of misguided programming idioms.

The algorithm isn't misguided. The use of a magic constant is misguided. Please don't confuse the language I choose. The only way it's safe is if you if-check the output values from your algorithm, and then there is no reason to have a special value, just use a flag. If you are not doing the if-check, then you are using a misguided programming idiom (unless you have proven for all possible inputs, there is a solution to your algorithm.) While in the examples in PEP 326, it's vaguely clear that it's not a problem. I imagine many uses that behave like this: minval = Max for i in vals: if i < minval: minval = i Which is a failure of design championed by a programming idiom you want to create. At least, if they attempt to pick some "Max" value, they will have the opportunity to realize the mistake rather than assume "it's the Python way". Furthermore, the PEP's examples aren't compelling because you can roll-your-own easily if you want such a thing, and since I consider it strictly bad to use them as output values, it makes no difference if its a built-in or not.

...

Besides, the reasons for rejection read more like a lukewarm -0 ("not that useful, easily implemented, can't decide

Perhaps, but I for one think it's silly. -Scott -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu

George Sakkis

2:39 a.m.

On Sun, Nov 16, 2008 at 9:21 PM, Scott Dial < scott+python-ideas@scottdial.com >wrote: George Sakkis wrote:

...

...
...
Using special objects to be lazy with your algorithm will never be wise.

s/lazy/elegant

To each his own, but your substitution fails to convince me that magic values are more readable than using a "valid" flag variable.

So the concept of infinity is a "magic value" and a flag variable is not ? I bet you find C-like error codes more readable than exceptions too. George

Leif Walsh

3:22 a.m.

On Sun, Nov 16, 2008 at 9:39 PM, George Sakkis wrote:

...

...
George Sakkis wrote:

...
...
Using special objects to be lazy with your algorithm will never be wise.

s/lazy/elegant

To each his own, but your substitution fails to convince me that magic values are more readable than using a "valid" flag variable.

So the concept of infinity is a "magic value" and a flag variable is not ? I bet you find C-like error codes more readable than exceptions too.

Whoa, whoa, calm down, kids. I'm going -1 on this, by the way. If you come across an absolute need for this, it's likely that you're doing something wrong, and if you have namespace clashes, you're definitely doing something wrong. It's too easy to fix most of the use cases for Smallest or Largest with None, in any case: minval = None for elt in lst: if minval is None or elt < minval: minval = elt -- Cheers, Leif

George Sakkis

1:43 a.m.

On Sun, Nov 16, 2008 at 5:33 PM, Josiah Carlson wrote: On Thu, Nov 13, 2008 at 11:25 PM, Scott Dial

...

> wrote:

...
George Sakkis wrote:

...
One small side-effect of not being able to compare incompatible types in 3.0 is that None cannot be used any more as the smallest element. Yes this has always been an implementation artifact and a hack, but it was very convenient none the less. Is it maybe the right time to add a builtin Smallest (and also Largest) object, i.e. two singletons so that `Smallest < x` for every x: x is not Smallest and `Largest > x` for every x: x is not Largest ? Although it's not hard to define them in pure Python and one could object with "not every n-liner needs to be a builtin", the main added value is that these will be endorsed as the standard, otherwise we risk mymodule.Smallest clashing with with yourmodule.Smallest.

You can more-or-less take all of the replies to the thread about a blessed "__missing__" object and apply them to "Smallest"/"Largest". Using special objects to be lazy with your algorithm will never be wise.

s/lazy/elegant

...

Eventually, someone will use them to mean something else entirely. It's almost always better to avoid using special objects or to roll-your-own (so that nobody can use it unexpectedly). Furthermore, preloading an output value with a nonsense value like "Smallest" or "Largest" is just asking for it to get leaked accidentally (the same problem exists with preloading None).

-1 Let's not provide features for misguided programming idioms.

...

to have to be -1 as well (despite 326 being my PEP).

Roberto Bonvallet

27 Nov 27 Nov

4:09 a.m.

George Sakkis wrote:

...

Is it maybe the right time to add a builtin Smallest (and also Largest) object, i.e. two singletons so that `Smallest < x` for every x: x is not Smallest and `Largest > x` for every x: x is not Largest ?

Largest = float('Infinity') Smallest = float('-Infinity') -- Roberto Bonvallet

skip＠pobox.com

6:59 p.m.

>> Is it maybe the right time to add a builtin Smallest (and also >> Largest) object, i.e. two singletons so that `Smallest < x` for every >> x: x is not Smallest and `Largest > x` for every x: x is not Largest >> ? Roberto> Largest = float('Infinity') Roberto> Smallest = float('-Infinity') Hmmm... Python 2.7a0 (trunk:67276M, Nov 18 2008, 21:20:11) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> Smallest = float('-Infinity') >>> Largest = float('Infinity') >>> Smallest < 'a' True >>> Largest < 'a' True In short, it will likely work for numbers but not other types. Skip

5627

Age (days ago)

5644

Last active (days ago)

List overview

Download

9 comments

6 participants

participants (6)

George Sakkis
Josiah Carlson
Leif Walsh
Roberto Bonvallet
Scott Dial
skip＠pobox.com

Smallest/Largest singletons

George Sakkis

Scott Dial

Josiah Carlson

George Sakkis

Scott Dial

George Sakkis

Leif Walsh

George Sakkis

Roberto Bonvallet

skip＠pobox.com

tags

participants (6)