Any list larger than any number by way of dimensions?

[Peter Knoerrich]

Khrm,

just today I ran over some bit of (my!) code that inadvertently had omitted
a len() function call:

data = [ ... some list ]
buffersize = min(data,10)

Of course what I really wanted was

buffersize = min(len(data),10)

It happens so that I'd have expected python to bark at me for that like
I deserve, except it didn't. In fact my freshest python 2.3.4 - just
downloaded and compiled - seems to think that any list is larger than any
single number:

$ ./python
Python 2.3.4 (#1, Jun 28 2004, 17:36:42)
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

[] > 1e99999 True

Now in a way that makes a lot of sense, since one could fold up any
one-dimensional space just tightly enough for it to fit into any
two-dimensional space (even very small ones).

Still, to use a british expression, where's the beef? Is there some
subtle philosophical point to this like the distinction between split and
join? I hesitate to report this as a bug, even though it could have made
my day pretty miserable if that buffersize above had been short.

Have a good day in any dimension you happen to inhabit and don't worry:
If anyone's going to fold you up and put you into a tiny cubicle in
a higher dimenstion you'll just never know.

Peter-With-The-Snakes Knörrich
Dr. Hagen & Partner GmbH
(e-mail address removed)

 

[Peter Otten]

$ ./python
Python 2.3.4 (#1, Jun 28 2004, 17:36:42)
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

[] > 1e99999 True

Now in a way that makes a lot of sense, since one could fold up any
one-dimensional space just tightly enough for it to fit into any
two-dimensional space (even very small ones).

Still, to use a british expression, where's the beef? Is there some
subtle philosophical point to this like the distinction between split and
join? I hesitate to report this as a bug, even though it could have made
my day pretty miserable if that buffersize above had been short.

I think this is one of Python's very few _design_ bugs. From a recent
python-dev thread on "Comparing heterogeneous types":

[Aahz] "Guido has all-but-decreed that the
future of comparisons is that TypeError will be raised for all operators
other than == and <> for types that have no appropriate relationship
system."

Google might find you more.

The "all-but" worries me a bit, though.

Peter

 

[Harald Massa]

Peter,

data = [ ... some list ]
buffersize = min(data,10)

Of course what I really wanted was

buffersize = min(len(data),10)

if my memory suits me right, when everything else fails, Python is just
comparing the IDs of the objects. IDs are connected to the memory
addresses.

 

[Peter Knoerrich]

Ah, Harald and Peter -

thanks then. I'll just have to watch my step.

Peter

 

[Dan Bishop]

Peter,

data = [ ... some list ]
buffersize = min(data,10)

Of course what I really wanted was

buffersize = min(len(data),10)

if my memory suits me right, when everything else fails, Python is just
comparing the IDs of the objects. IDs are connected to the memory
addresses.

That's true for user-defined objects, but for built-in types the rule is

None < number < list < string < tuple

Which is consistent but wrong.

 

[David Fraser]

Peter,

data = [ ... some list ]
buffersize = min(data,10)

Of course what I really wanted was

buffersize = min(len(data),10)

if my memory suits me right, when everything else fails, Python is just
comparing the IDs of the objects. IDs are connected to the memory
addresses.

That's true for user-defined objects, but for built-in types the rule is

None < number < list < string < tuple

Which is consistent but wrong.

It's consistent but arbitrary. How can you say its wrong? It does what
its defined to do.

David

 

[Reinhold Birkenfeld]

Peter,


data = [ ... some list ]
buffersize = min(data,10)

Of course what I really wanted was

buffersize = min(len(data),10)

if my memory suits me right, when everything else fails, Python is just
comparing the IDs of the objects. IDs are connected to the memory
addresses.

That's true for user-defined objects, but for built-in types the rule is

None < number < list < string < tuple

Which is consistent but wrong.

It's consistent but arbitrary. How can you say its wrong? It does what
its defined to do.

You cannot say it is "wrong" in the usual sense that a string would have
to be greater than a tuple, but in my eyes it is "wrong" that the types
even give a result when compared, as opposed to raising a TypeError or
something like this.

IMHO, this behavior is only useful for implementing ugly tricks that
should be avoided anyway, so I vote for removing this comparability.

Reinhold

 

[Paul Miller]

[re: None < number < list < string < tuple ]

It's consistent but arbitrary. How can you say its wrong? It does what
its defined to do.

It may be right, but it's probably not The Right Thing To Do(tm). The
main problem /I/ have with it is that complex numbers represent an
exception (no pun intended) to this rule among all the built-in types
in that they don't compare to anything.

I wonder if the Right Thing (tm) would be to have comparisons between
types raise an exception unless the interpreter is instructed
otherwise by a __cmp__ method. This neatly takes care of subclasses
of builtin types, so you could still use a subclass of int, for
example, anywhere you could use an int (unless you specifically
override __cmp__).

from __future__ import comparisons, anyone?

 

[Reinhold Birkenfeld]

[re: None < number < list < string < tuple ]

It's consistent but arbitrary. How can you say its wrong? It does what
its defined to do.

It may be right, but it's probably not The Right Thing To Do(tm). The
main problem /I/ have with it is that complex numbers represent an
exception (no pun intended) to this rule among all the built-in types
in that they don't compare to anything.

I wonder if the Right Thing (tm) would be to have comparisons between
types raise an exception unless the interpreter is instructed
otherwise by a __cmp__ method. This neatly takes care of subclasses
of builtin types, so you could still use a subclass of int, for
example, anywhere you could use an int (unless you specifically
override __cmp__).

from __future__ import comparisons, anyone?

+1

Reinhold

 

[Peter Knoerrich]

None < number < list < string < tuple

IMHO, this behavior is only useful for implementing ugly tricks that
should be avoided anyway, so I vote for removing this comparability.

Uhm... Motion seconded.

Although, I've just found some Obfuscated Python snippets. I'm feeling
tempted now to... abuse this some

Peter.