RetroSearch Browse

Tue Dec 6 01:18:45 EST 2016 · https://mail.python.org/pipermail/python-dev/2016-December/146906.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2016-December/146906.html below:

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