<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, May 6, 2013 at 7:50 PM, Terry Jan Reedy <span dir="ltr"><<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 5/6/2013 6:34 PM, Antoine Pitrou wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 06 May 2013 18:23:02 -0400<br>
Terry Jan Reedy <<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
'Item' is necessarily left vague for mutable sequences as bytearrays<br>
also store values. The fact that Antoine's example 'works' for<br>
bytearrays is an artifact of the caching, not a language-mandated<br>
necessity.<br>
</blockquote>
<br>
No, it isn't.<br>
</blockquote>
<br></div>
Yes it is. Look again at the array example.<div class="im"><br>
>>> from array import array<br>
>>> x = 1001<br>
>>> myray = array('i', [x])<br>
>>> myray[0] is x<br>
False<br>
<br></div>
Change 1001 to a cached int value such as 98 and the result is True instead of False. For the equivalent bytearray example<div class="im"><br>
<br>
>>> b = bytearray()<br>
>>> b.append(98)<br>
>>> b[0] is 98<br>
True<br>
<br></div>
the result is always True *because*, and only because, all byte value are (now) cached. I believe the test for that is marked as CPython-specific.<div class="im"><br>
<br>
> You are mixing up values and references.<br>
<br></div>
No I am not. My whole post was about being careful to not to confuse the two. I noted, however, that the Python *docs* use 'item' to mean either or both. If you do not like the *doc* being unclear, clarify it.<div class="im">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A bytearray or a array.array may indeed store values, but a list stores references to<br>
objects.<br>
</blockquote>
<br></div>
I said exactly that in reference to CPython. As far as I know, the same is true of lists in every other implementation up until Pypy decided to optimize that away. What I also said is that I cannot read the *current* doc as guaranteeing that characterization. The reason is that the members of sequences, mutable sequences, and lists are all described as 'items'. In the first two cases, 'item' means 'value or object reference'. I see nothing in the doc to force a reader to change or particularized the meaning of 'item' in the third case. If I missed something *in the specification*, please point it out to me.<div class="im">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm pretty sure that not respecting identity of objects stored in<br>
general-purpose containers would break a *lot* of code out there.<br>
</blockquote>
<br></div>
Me too. Hence I suggested that if lists, etc, are intended to respect identity, with 'is' as currently defined, in any implementation, then the docs should say so and end the discussion. I would be happy to commit an approved patch, but I am not in a position to decide the substantive content. Hence, I tried to provide a neutral analysis that avoided confusing the CPython implementation with the Python specification.<br>


<br>
In my final paragraph, however, I did suggest that Pypy respect precedent, to avoid breaking existing code and expectations, and call their mutable sequences something other than 'list'.<br></blockquote><div><br>

</div><div style>Wouldn't the entire point of such things existing in pypy be that the implementation is irrelevant to the user and used behind the scenes automatically in the common case when a container is determined to fit the special constraint?</div>

<div style><br></div><div style>I personally do not think we should guarantee that "mylist[0] = x; assert x is mylist[0]" succeeds when x is an immutable type other than None.  If something is immutable and not intended to be a singleton and does not define equality (like None or sentinel values commonly tested using is such as arbitrary object() instances) it needs to be up to the language VM to determine when to copy or not in most situations.</div>

<div style><br></div><div style>You already gave the example of the interned small integers in CPython.  String constants and names used in code are also interned in today's CPython implementation.  This doesn't tend to trip any real code up.</div>

<div style><br></div><div style>-gps</div></div></div></div>