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

[Raymond Hettinger]

> On Dec 5, 2016, at 10:38 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> 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 was right that this was a design choice.  To my eye, the current form looks better than "deque(deque(...))".  Also, we use  {...} instead of OrderedDict(...).  The idea is communicate a repeated reference rather than suggesting that the named constructor is called again or trying to communicate type.  Since the repr has been in place for over a decade, changing it would be unnecessarily disruptive (to users and to the other implementations).  I think we should just let it be.


Raymond