> On Dec 5, 2016, at 10:38 AM, Terry Reedy <[email protected]> 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
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
