On 05.12.16 20:38, Terry Reedy 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.
There was a discussion about this a year ago. I proposed to use <...> or
<deque object at ...> for disambiguation.
https://mail.python.org/pipermail/python-ideas/2015-December/037537.html
https://mail.python.org/pipermail/python-ideas/2015-December/037544.html
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
