[Python-Dev] PyPy progress: list of CPython 3.5 crashers and bugs

[Terry Reedy]

On 12/5/2016 3:42 AM, Armin Rigo wrote:

[what to do with]
> http://bitbucket.org/pypy/extradoc/raw/extradoc/planning/py3.5/cpython-crashers.rst

Independent isssues ultimately need separate tracker issues, but a few 
collective issues are definitely better than nothing on the tracker. 
Few free to open separate issues for any that you wish.

---
I believe that this item in your list is a design choice rather than a bug.
"* _collectionsmodule.c: deque_repr uses "[...]" as repr if recursion is
   detected.  I'd suggest that "deque(...)" is clearer---it's not a list."

I strongly suspect that Raymond H. intentionally choose to consistently 
represent deques as "deque(<somelist>)"  With recursion, some current 
results are:

 >>> import _collections as c
 >>> d = c.deque()
 >>> d.append(d)
 >>> d
deque([[...]])
 >>> d.append(1)
 >>> d
deque([[...], 1])
 >>> d.rotate()
 >>> d
deque([1, [...]])
 >>> l = []
 >>> l.append(l)
 >>> d2 = c.deque(l)
 >>> d2
deque([[[...]]])

With ... now being valid, all of these evaluate to a finite structure 
with a different representation ('Ellipsis' replacing '...').  The same 
would be true of what I believe is your proposal for the first example 
above: "deque(deque(...))".  I can see why you might prefer it.  On the 
other hand, it could be seen as falsely implying that the object is the 
result two calls to deque.  In any case, changing the repr (and possibly 
breaking existing code) would be an enhancement issue for 3.7 at the 
earliest.

At least it is the case that the representation of a pure recursive 
deque and a deque containing a pure recursive list are different.

-- 
Terry Jan Reedy