On Mon, May 6, 2013 at 7:50 PM, Terry Jan Reedy <tjre...@udel.edu> wrote:
> On 5/6/2013 6:34 PM, Antoine Pitrou wrote:
>
>> On Mon, 06 May 2013 18:23:02 -0400
>> Terry Jan Reedy <tjre...@udel.edu> wrote:
>>
>>>
>>> 'Item' is necessarily left vague for mutable sequences as bytearrays
>>> also store values. The fact that Antoine's example 'works' for
>>> bytearrays is an artifact of the caching, not a language-mandated
>>> necessity.
>>>
>>
>> No, it isn't.
>>
>
> Yes it is. Look again at the array example.
>
> >>> from array import array
> >>> x = 1001
> >>> myray = array('i', [x])
> >>> myray[0] is x
> False
>
> Change 1001 to a cached int value such as 98 and the result is True
> instead of False. For the equivalent bytearray example
>
>
> >>> b = bytearray()
> >>> b.append(98)
> >>> b[0] is 98
> True
>
> 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.
>
>
> > You are mixing up values and references.
>
> 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.
>
>
> A bytearray or a array.array may indeed store values, but a list stores
>> references to
>> objects.
>>
>
> 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.
>
>
> I'm pretty sure that not respecting identity of objects stored in
>> general-purpose containers would break a *lot* of code out there.
>>
>
> 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.
>
> 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'.
>
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?
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.
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.
-gps
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
