Can a simple a==b 'hang' in and endless loop?

[Steven D'Aprano]

Exactly this is what Python does under the hood when writing
a = "some string"
b = "some string"
where a and b are actually, in terms of C, pointer to Python object data
structures which provide strings as arrays where it is possible to say
a[0], but ... if here
if(a==b):
print "True"
_does not_ print True, the Python engine is definitely broken.

Why are you comparing C behaviour to Python behaviour?
What is the point of the discussion?

 

[Claudio Grondi]

Exactly this is what Python does under the hood when writing
a = "some string"
b = "some string"
where a and b are actually, in terms of C, pointer to Python object
data structures which provide strings as arrays where it is possible
to say a[0], but ... if here
if(a==b):
print "True"
_does not_ print True, the Python engine is definitely broken.

Why are you comparing C behaviour to Python behaviour? What is the point
of the discussion?

The point is to find a way to create in Python two indentifiers a and b
without manipulating any of the __eq__ and to __eq__ related functions
in a way, that the simple
if a==b: print 'a==b'
statement results in an endless loop.
To my knowledge this is not possible to achieve in C, but is probably
achievable in Python.

Claudio

 

[Claudio Grondi]

The problem here is, that I mean, that in Python it makes no sense to
talk about a value of an object, because it leads to weird things when
trying to give a definition what a value of an object is.

Python object: 1
The value of that Python object: the int 1

Python object 4.7
The value of that Python object: the float 4.7

Python object "abc"
The value of that Python object: a string consisting of characters a, b
and c.

Python object [1, 4.7, "abc"]
The value of that Python object: a list containing objects 1, 4.7 and "abc".


Where's the problem?

My problem is, that I don't know if it is possible and if yes how to
overwrite the __eq__() methods of the built-in types.
With not built-in types I can do:
class classWithWeirdEqualityBehaviour:
def __init__(self, value)
self.value = value
def __eq__(self, other):
return False
a = classWithWeirdEqualityBehaviour(1)
b = classWithWeirdEqualityBehaviour(1)
a==b # gives False

False

Works for me.





In Python, you never care _where_ anything is stored. The id() function
returns the unique ID of an object, which as an implementation detail may
be the actual memory address, but that's just an implementation detail. In
any case, given a memory address, you can't do anything with that
knowledge.

The question here is, if this a handicap or a welcome feature?

From the one side I am glad that Python cares about memory allocation
for me, but on the other side I have trouble to accept, that I have no
direct access to the memory area where data are stored in order to
manipulate them. Having this possibility would enormously speed up some
conversions, because it were possible to get them down to a redefinition
of the data structure without being forced to loop over the actual
content or use a special extension library written in C for doing that.

Claudio

 

[Steve Holden]

Claudio Grondi wrote:

Exactly this is what Python does under the hood when writing
a = "some string"
b = "some string"
where a and b are actually, in terms of C, pointer to Python object
data structures which provide strings as arrays where it is possible
to say a[0], but ... if here
if(a==b):
print "True"
_does not_ print True, the Python engine is definitely broken.

Why are you comparing C behaviour to Python behaviour? What is the point
of the discussion?

The point is to find a way to create in Python two indentifiers a and b
without manipulating any of the __eq__ and to __eq__ related functions
in a way, that the simple
if a==b: print 'a==b'
statement results in an endless loop.
To my knowledge this is not possible to achieve in C, but is probably
achievable in Python.

So finally we understand what you are looking for (though not why ...).

>>>
>>> a = [1]
>>> a.append(a)
>>> a [1, [...]]
>>>
>>> b = [1]
>>> b.append(b)
>>> a == b

Traceback (most recent call last):

Is this what you seek? Not quite "an endless loop", but probably as
close as you are going to get given the necessariliy recursive data
structures required to induce it.

regards
Steve

 

[Steve Holden]

Steven D'Aprano wrote: [...]

In Python, you never care _where_ anything is stored. The id() function
returns the unique ID of an object, which as an implementation detail may
be the actual memory address, but that's just an implementation detail. In
any case, given a memory address, you can't do anything with that
knowledge.

The question here is, if this a handicap or a welcome feature?

A welcome feature, absolutely no doubt about it.

From the one side I am glad that Python cares about memory allocation
for me, but on the other side I have trouble to accept, that I have no
direct access to the memory area where data are stored in order to
manipulate them. Having this possibility would enormously speed up some
conversions, because it were possible to get them down to a redefinition
of the data structure without being forced to loop over the actual
content or use a special extension library written in C for doing that.

Well, if this isn't a case of premature optimization I've never seen
one. You apparently haven't yet written a single line of your
appliction, yet you are already concerned about its efficiency.

1. First, make it work.

2. Then, if it doesn;t work fast enough, make it work faster.

regards
Steve

 

[Fuzzyman]

(If I understand correctly...)

The reason he is looking for it, is in order to assert that Python
'comparison' is broken.

Part of this is because of his assertation that the term 'value' has no
meaning in Python.

He bases this on the fact that Java and C define 'value' to mean the
pointer when the object is mutable.

In fact Python defines value much more clearly. Value is *obviously*
type dependent. (This is why in Python you can implement your own
comparison methods).

For integers and floats, Python defines the value to be the numerical
value.

For strings it defines it to be the contents of the string.

For mutable objects it defines it to be the contents of the object, if
the object types are the same. i.e. [1] == [1], [1] != (1,)

For user defined classes, you are able to build your own definition of
value into the object - this doesn't prevent stupidity.

Python doesn't have a comparison operator analagous to his reference
languages - but IMHO Python is better here. He can achieve what he
wants by subclassing the built in datatypes and overriding the
comparison methods to behave as he desires.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[Claudio Grondi]

Claudio Grondi wrote:


Exactly this is what Python does under the hood when writing
a = "some string"
b = "some string"
where a and b are actually, in terms of C, pointer to Python object
data structures which provide strings as arrays where it is possible
to say a[0], but ... if here
if(a==b):
print "True"
_does not_ print True, the Python engine is definitely broken.




Why are you comparing C behaviour to Python behaviour? What is the
point of the discussion?

The point is to find a way to create in Python two indentifiers a and
b without manipulating any of the __eq__ and to __eq__ related
functions in a way, that the simple
if a==b: print 'a==b'
statement results in an endless loop.
To my knowledge this is not possible to achieve in C, but is probably
achievable in Python.

So finally we understand what you are looking for (though not why ...).

I will intentionally not elaborate here about the why, as my experience
with this thread has already shown, that this is not only not helpful in
getting the answer to the actual question, but results in 'hiding' the
goal to the reader which needs to be revealed as it gets lost in the
explanation.

a = [1]
a.append(a)
a [1, [...]]

b = [1]
b.append(b)
a == b

Traceback (most recent call last):

Is this what you seek? Not quite "an endless loop", but probably as
close as you are going to get given the necessariliy recursive data
structures required to induce it.

Wow! I haven't got this evil idea myself yet (even if as I understand
there is no problem to achieve similar thing also in C), so I have
learned a bit more about Python again. Am I right supposing, that this
becomes possible because the .append() goes not that far to try to
generate the actual list (getting trapped in the endless loop) and only
lets the second list element point to the object with the list itself.
The trouble with it becomes apparent later when working with such bad
defined list as it is the case when applying the '==' operator to it.
Thank you for sharing this with me, but again ...

this is still _not_ what I am looking for, because Python detects here
the problem and throws an exception. What I am looking for is an endless
loop where there is no any response from Python about a problem.

Claudio

 

[Steve Holden]

Claudio Grondi wrote:

Steven D'Aprano wrote:


Claudio Grondi wrote:



Exactly this is what Python does under the hood when writing
a = "some string"
b = "some string"
where a and b are actually, in terms of C, pointer to Python object
data structures which provide strings as arrays where it is possible
to say a[0], but ... if here
if(a==b):
print "True"
_does not_ print True, the Python engine is definitely broken.




Why are you comparing C behaviour to Python behaviour? What is the
point of the discussion?



The point is to find a way to create in Python two indentifiers a and
b without manipulating any of the __eq__ and to __eq__ related
functions in a way, that the simple
if a==b: print 'a==b'
statement results in an endless loop.
To my knowledge this is not possible to achieve in C, but is probably
achievable in Python.

So finally we understand what you are looking for (though not why ...).

I will intentionally not elaborate here about the why, as my experience
with this thread has already shown, that this is not only not helpful in
getting the answer to the actual question, but results in 'hiding' the
goal to the reader which needs to be revealed as it gets lost in the
explanation.

a = [1]
a.append(a)
a [1, [...]]

b = [1]
b.append(b)
a == b

Traceback (most recent call last):

Is this what you seek? Not quite "an endless loop", but probably as
close as you are going to get given the necessariliy recursive data
structures required to induce it.

Wow! I haven't got this evil idea myself yet (even if as I understand
there is no problem to achieve similar thing also in C), so I have
learned a bit more about Python again. Am I right supposing, that this
becomes possible because the .append() goes not that far to try to
generate the actual list (getting trapped in the endless loop) and only
lets the second list element point to the object with the list itself.
The trouble with it becomes apparent later when working with such bad
defined list as it is the case when applying the '==' operator to it.
Thank you for sharing this with me, but again ...

Yes, clearly Python is able to create recursive data structures of this
type, just as C and Java are. As you can see when the interpreter prints
the representation of such lists, the __repr__() method does indeed
detect such recursion and places ellipses ("...") in the output to
indicate it.

When you say "Python goes not so far as to try to generate the actual
list" you reveal a misunderstanding about Python. The interpreter
responds to the statement

a.append(a)

just as it responds to every other append() method call: it adds a new
item to the list and binds (i.e. stores a reference to) the argument (in
this case the list as itself) to that new item. No special cases are
required here, this is what the interpreter always does.

this is still _not_ what I am looking for, because Python detects here
the problem and throws an exception. What I am looking for is an endless
loop where there is no any response from Python about a problem.

Ah, I see. So you want Python to be a worse language than it actually
is. I don't think you are going to find what you are looking for.

regards
Steve

 

[Fuzzyman]

Claudio Grondi wrote:
[snip..]

Wow! I haven't got this evil idea myself yet (even if as I understand
there is no problem to achieve similar thing also in C), so I have
learned a bit more about Python again. Am I right supposing, that this
becomes possible because the .append() goes not that far to try to
generate the actual list (getting trapped in the endless loop) and only
lets the second list element point to the object with the list itself.

I think you've got this.

a = []

Here a is a reference to a list object.

a.append(a)

As mentioend previously - you pass around references (names), not
values.

Here you've put a reference to the list object a as the first member of
the list a.

The trouble with it becomes apparent later when working with such bad
defined list as it is the case when applying the '==' operator to it.
Thank you for sharing this with me, but again ...

this is still _not_ what I am looking for, because Python detects here
the problem and throws an exception. What I am looking for is an endless
loop where there is no any response from Python about a problem.

Loops tend to be caused by function or method calls - so they add
frames to the stack and get detected as recursion.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[Claudio Grondi]

(If I understand correctly...)

The reason he is looking for it, is in order to assert that Python
'comparison' is broken.

a bit this way, but why formulate it with such a negative touch?
Lets understand it more as looking for a way to get a deep understanding
of the concept behind the Python '==' operator (and many other things
related to it) and a way to explain it to a C programmer (because it
differs from the concept he knows from C). If it should turn out, that
there is some inconsistency in the Python concept it will become
apparent why and then it can be discussed further or even lead to a PEP
and everyone here will profit from this. If it turns out that there is
no inconsistency, one more Python user (i.e. me ) will get deep
understanding of this Python concept and maybe can help others seeking
same enlightenment.

Part of this is because of his assertation that the term 'value' has no
meaning in Python.

This seems to me still to be true, but lets postpone the discussion of
it (which should first give a definition what 'value' means in Python)
and about if it makes sense to use this term to describe something which
is far away from the common understanding of it to another thread and a
later time when I get even more clear picture about it as it is the case
now.

He bases this on the fact that Java and C define 'value' to mean the
pointer when the object is mutable.

I base it on the fact, that a value is what is actually stored in memory
in a data structure which can be reached used a name (i.e. an
identifier). This way of understanding what value means allows to
distinguish between memory content (the value) and memory address
(represented by the name of the variable). The concept of the pointer in
C does not change the meaning of the term value, because there is a
value a pointer has (i.e. there is data in memory addressed by the
variable name which is the pointer) and that this value means here an
address is another beer (leading to much confusion when learning to work
with pointers in C).
By the way: please don't mix Javascript and Java - these are two totally
different things. Java is a programming language you can compile for a
Java VM, Javascript is the interpreted scripting language used for
scripting of HTML where its Windows version JScript is a full featured
scripting engine like Python is. I haven't mentioned Java as I know only
very little about it, I have mentioned Javascript (JScript) I am much
more experienced with.

In fact Python defines value much more clearly. Value is *obviously*
type dependent. (This is why in Python you can implement your own
comparison methods).

For integers and floats, Python defines the value to be the numerical
value.

For strings it defines it to be the contents of the string.

For mutable objects it defines it to be the contents of the object, if
the object types are the same. i.e. [1] == [1], [1] != (1,)

For user defined classes, you are able to build your own definition of
value into the object - this doesn't prevent stupidity.

Python doesn't have a comparison operator analagous to his reference
languages - but IMHO Python is better here. He can achieve what he
wants by subclassing the built in datatypes and overriding the
comparison methods to behave as he desires.

You seem here to try to give a definition of the term 'value' for
Python. If I understand it right, the definition of the term can't be
generally given for many reasons. It depends at least on type and in
advanced usage it can be arbitrary defined or changed.
That is why I mean, that it makes no sense to talk in Python about
value. I see not much sense in taking existing term in order to redefine
it for a new context - the result is always increase of confusion. Let
give it another name in order to know, that it must be defined for the
context it is used before it becomes meaningful.
Any suggestions?

Claudio

 

[Claudio Grondi]

Claudio Grondi wrote:


Steven D'Aprano wrote:


Claudio Grondi wrote:



Exactly this is what Python does under the hood when writing
a = "some string"
b = "some string"
where a and b are actually, in terms of C, pointer to Python
object data structures which provide strings as arrays where it is
possible to say a[0], but ... if here
if(a==b):
print "True"
_does not_ print True, the Python engine is definitely broken.





Why are you comparing C behaviour to Python behaviour? What is the
point of the discussion?




The point is to find a way to create in Python two indentifiers a
and b without manipulating any of the __eq__ and to __eq__ related
functions in a way, that the simple
if a==b: print 'a==b'
statement results in an endless loop.
To my knowledge this is not possible to achieve in C, but is
probably achievable in Python.


So finally we understand what you are looking for (though not why ...).

I will intentionally not elaborate here about the why, as my
experience with this thread has already shown, that this is not only
not helpful in getting the answer to the actual question, but results
in 'hiding' the goal to the reader which needs to be revealed as it
gets lost in the explanation.

a = [1]
a.append(a)
a
[1, [...]]

b = [1]
b.append(b)
a == b
Traceback (most recent call last):
File "<stdin>", line 1, in ?
RuntimeError: maximum recursion depth exceeded in cmp


Is this what you seek? Not quite "an endless loop", but probably as
close as you are going to get given the necessariliy recursive data
structures required to induce it.

Wow! I haven't got this evil idea myself yet (even if as I understand
there is no problem to achieve similar thing also in C), so I have
learned a bit more about Python again. Am I right supposing, that this
becomes possible because the .append() goes not that far to try to
generate the actual list (getting trapped in the endless loop) and
only lets the second list element point to the object with the list
itself. The trouble with it becomes apparent later when working with
such bad defined list as it is the case when applying the '=='
operator to it.
Thank you for sharing this with me, but again ...

Yes, clearly Python is able to create recursive data structures of this
type, just as C and Java are. As you can see when the interpreter prints
the representation of such lists, the __repr__() method does indeed
detect such recursion
> and places ellipses ("...")

The Python tutorial '3.2 The standard type hierarchy' says:
"""
Ellipsis: This type has a single value. There is a single object with
this value. This object is accessed through the built-in name Ellipsis.
It is used to indicate the presence of the "..." syntax in a slice. Its
truth value is true.
"""
Not very helpful in understanding what it is, so it still belongs to the
dark unknown area of Python to me.
Any hints towards enlightenment what this from the geometry known term
'ellipsis' mean in Python? Googling shows, that I am not the first who
doesn't know what it is in context of Python, so probably there is
already a good explanation somewhere, but where?

> in the output to
indicate it.

When you say "Python goes not so far as to try to generate the actual
list" you reveal a misunderstanding about Python. The interpreter
responds to the statement

a.append(a)

just as it responds to every other append() method call: it adds a new
item to the list and binds (i.e. stores a reference to) the argument (in
this case the list as itself) to that new item. No special cases are
required here, this is what the interpreter always does.

Ah, I see. So you want Python to be a worse language than it actually
is. I don't think you are going to find what you are looking for.

Does it mean you reject to try to give a solution because of the reason
why I seek for it, or do you want to say, that there is to your
knowledge no possible solution except those you have already given?

Claudio

 

[Dave Hansen]

Dave Hansen wrote:

[[email protected] wrote]

Fuzzyman wrote: [...]
In this case :

a = ['some string']
b = ['somestring']
a == b
False (probably)
That depends, the C syntax is like this :

char *a="hello";
char *b="hello";

assert(a==b);

// true, the compiler knows the two hello are the same and assign the
same address(sort of id() in python) to a and b

No. The C standard says the compiler is _allowed_ to re-use character
literal constants, but is not _required_ to do so.

I could have sworn that fuzzyman's example contained a literal string in
an array, and an array comparision, so why are you talking about com-
paring string literals ? a compiler for which

I was responding to bonono's example, not fuzzyman's. Perhaps a more
appropriate response would have been that his example (besides being
incorrect) didn't match the situation under consideration.

char* a[] = { "some string" };
char* b[] = { "some string" };

...

if (a == b)
printf("True\n");

prints True is definitely broken.

Definitely. However,

if (a[0] == b[0])
puts("True");

May or may not print "True." Either answer is allowed. In C.

Regards,
-=Dave

 

[Claudio Grondi]

Steven D'Aprano wrote:
[...]

The higher level of abstraction/indirection in Python results in making
the concepts of 'value', 'having a value' or 'comparing values'
useless,
where it helps in C to express the difference between address and
content at that address and to distinguish between the information
telling _what_ is stored in memory and the information about _where_ it
is stored.



In Python, you never care _where_ anything is stored. The id() function
returns the unique ID of an object, which as an implementation detail
may
be the actual memory address, but that's just an implementation
detail. In
any case, given a memory address, you can't do anything with that
knowledge.

The question here is, if this a handicap or a welcome feature?

A welcome feature, absolutely no doubt about it.

From the one side I am glad that Python cares about memory allocation
for me, but on the other side I have trouble to accept, that I have no
direct access to the memory area where data are stored in order to
manipulate them. Having this possibility would enormously speed up
some conversions, because it were possible to get them down to a
redefinition of the data structure without being forced to loop over
the actual content or use a special extension library written in C for
doing that.

Well, if this isn't a case of premature optimization I've never seen
one. You apparently haven't yet written a single line of your
appliction, yet you are already concerned about its efficiency. Wrong guess.

1. First, make it work. I did.

2. Then, if it doesn;t work fast enough, make it work faster.

I did it, too.

Exactly in this order.

And out of this experience I mean to know, that it seems to be no other
way for fast conversions as using own extension modules or existing
ones. But if it necessary to use more than one existing extension module
and the modules used are not compatible to each other, the problem
persists.
And because I haven't mastered to write an own CPython extension module
yet, my idea was to try to understand how Python works under the hood in
order to find a workaround, but it seems, that there is none, so I have
to master Pyrex first, then the problems will go away, right?

In other words, there is no way to avoid C programming in case available
extension modules don't fit as solution for the task where speed
matters, because there is no low level access to the data in Python.

In this context I wish Python would have an 'advanced mode' I could
switch to, to get low level access to the data - is it a bad idea?

Claudio

 

[Terry Hancock]

From the one side I am glad that Python cares about
memory allocation
for me, but on the other side I have trouble to accept,
that I have no direct access to the memory area where
data are stored in order to manipulate them. Having this
possibility would enormously speed up some conversions,
because it were possible to get them down to a
redefinition of the data structure without being forced
to loop over the actual content or use a special
extension library written in C for doing that.

It is precisely this power that makes C such a dangerous
language to program in -- it's what makes it so easy to
crash your program, any other program running on the same
machine, and shoot yourself and your dog each in the foot.

Sometimes you really do need that power, and isn't
it wonderful that we have C for those times?

If you find yourself really needing this kind of capability
in Python, then you can write an extension module to create
it.

As a compromise, BTW, there is also Pyrex, which gives you
C-like capabilities from a more Python-like language, and
was specifically created for making Python Extensions. I
believe, for example, that Soya 3D now uses Pyrex in
preference to C for highly-optimized code.

For everyday use, though, I recommend keeping the guard
rails firmly in place.

Imagine what the world would be like if we didn't have plugs
and outlets? What if every time you wanted to move a lamp
you had shut off the power and rewire your house? Safe
abstraction levels are a big time-saver.

 

[Christopher Subich]

The Python tutorial '3.2 The standard type hierarchy' says:
"""
Ellipsis: This type has a single value. There is a single object with
this value. This object is accessed through the built-in name Ellipsis.
It is used to indicate the presence of the "..." syntax in a slice. Its
truth value is true.
"""
Not very helpful in understanding what it is, so it still belongs to the
dark unknown area of Python to me.
Any hints towards enlightenment what this from the geometry known term
'ellipsis' mean in Python? Googling shows, that I am not the first who
doesn't know what it is in context of Python, so probably there is
already a good explanation somewhere, but where?

Ellipsis has a very well-known meaning -- but it's not geometry at all
(that's ellipse). From Webster online:

Ellipsis (noun):
1 a : the omission of one or more words that are obviously understood
but that must be supplied to make a construction grammatically complete
b : a sudden leap from one topic to another
2 : marks or a mark (as ... or · or --) indicating an omission (as of
words) or a pause

Does it mean you reject to try to give a solution because of the reason
why I seek for it, or do you want to say, that there is to your
knowledge no possible solution except those you have already given?

Your problem is badly specified. It seems to boil down to:

Given a and b as some combination of builtin types, is it possible for
the equality comparison (a==b) to hang?

The answer, so far as I know, is 'no'. That said, the answer is useless.

Firstly, you ignore the possiblity that '==' raises some form of error.
I don't know of any builtins that raise TypeError or the like on
comparison, but you've already seen examples that generate recursion
errors. In fact, since the situations likely to lead to looping in ==
constructs use recursion anyway (calling == on members of structure
types), your "infinite loop" becomes a stack depth error.

Secondly, you also ignore objects with overloaded or otherwise custom
__eq__ methods -- the default and well-documented way of supplying
equality comparisons to custom objects, which are first-class citizens
in a Python environment. (In fact, (1).__cmp__(1) [which provides a
general comparison] works.) Since these methods can contain arbitrary
Python code, comparison in Python *can* cause an infinite loop, IO, or
your grandmother to find out just what you've been hiding on your computer.

If you want to find out something about the principles behind Python,
ask about the principles flat-out; don't construct a contrived case like
this and wonder when the community's response is mostly confusion.

 

[Donn Cave]

You seem here to try to give a definition of the term 'value' for
Python. If I understand it right, the definition of the term can't be
generally given for many reasons. It depends at least on type and in
advanced usage it can be arbitrary defined or changed.
Yes!

That is why I mean, that it makes no sense to talk in Python about
value. I see not much sense in taking existing term in order to redefine
it for a new context - the result is always increase of confusion. Let
give it another name in order to know, that it must be defined for the
context it is used before it becomes meaningful.
Any suggestions?

Aargh, you are so close. The thing you're talking about is,
exactly, "value". The realization you just had, that is so valid,
is that it is futile to talk about value, per se. Changing the
word you use will do nothing to improve this.

Donn Cave, (e-mail address removed)

 

[Grant Edwards]

It is precisely this power that makes C such a dangerous
language to program in -- it's what makes it so easy to crash
your program, any other program running on the same machine,

Nonsense. Under Windows 3.0 that may be true, but on any real
OS, you can't "crash any other program running on the same
machien" in C, assembly, Python, or Lisp.

 

[Terry Hancock]

or when the objects being members of the list redefine
__eq__ so, that no matter how different they are, the
lists always compare True.

If those objects have redefined __eq__ so that they are all
equal in value to each other, then this is quite intuitive,
although not necessarily very useful -- the author of the
objects is saying that "one is as good as another". I can't
think of any kind of object for which such a definition of
value would be useful.

But in the real world ...

Lets consider a real example. Suppose I have a variety of
"fill level" indicators (class 'fl' below). They may
contain, let's say, a numerical value and a unit of liquid
measure (and probably an epsilon for float comparisons,
BTW):

True

a = [fl(1.04,'pint')]
b = [fl(1.00,'liter')]
a == b

True

(Not tested, because I'm not going to waste time writing fl
right now!)

The point is, the author of this hypothetical 'fl' class
wants its value to be isomorphic to the amount of liquid its
representation would contain, regardless of choice of units
(and probably to within a reasonable experimental error to
take care of float precision).

The author of a class has the power to DEFINE what "value"
is in Python. And that is an extremely useful capability. If
the interpreter were to impose this definition (which is
what you seem to be asking for when you complain that
"value" has no meaning in Python), that would terribly
reduce the utility of Python.

In general, the use of "value" (that is, "value"
distinct from "identity") implies that some kind of math is
going to be done with the objects. This is true even with
strings, in that comparison and other operators are defined
with respect to them, and depend on their literal value (not
their identity as an object in memory).

If objects NEED to only be compared by identity, then they
should leave __eq__ alone and identity will be used when
they are compared.

 

[Fredrik Lundh]

Nonsense. Under Windows 3.0 that may be true, but on any real
OS, you can't "crash any other program running on the same
machien" in C, assembly, Python, or Lisp.

given that it's trivial to create fork bombs and memory monsters in all
those languages, I think you might need to define the term "real OS".

(or do you run all your programs in a virtual sandbox ?)

</F>

 

[Terry Hancock]

this is still _not_ what I am looking for, because Python
detects here the problem and throws an exception. What I
am looking for is an endless loop where there is no any
response from Python about a problem.

I seriously doubt that what you are looking for exists.
Without manipulating __eq__, python comparisons are pretty
straightforward. Unless the object itself were infinite,
you couldn't get an infinite loop, and you've seen what
happens when you create an infinite object by recursion.

"""
Two boys sat near the airport, enthralled to watch the
planes launching, but strangely disappointed. One turned
to the other, and said "Aww, that one didn't blow up
either".
"""
;-)

Cheers,
Terry