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

[Claudio Grondi]

Steve Holden wrote:
> Claudio Grondi wrote:
> 
>> Steve Holden wrote:
>>
>>> 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.
> 
>> 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.
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
> 
> regards
>  Steve