On Tue, May 7, 2013 at 6:27 PM, Armin Rigo wrote:
> Hi Antoine,
>
> On Tue, May 7, 2013 at 8:25 AM, Antoine Pitrou wrote:
>> For me, a patch that mandated general-purpose containers (list, dict,
>> etc.) respect object identity would be ok.
>
> Thanks, that's also my opinion.
>
> In PyPy's approa
Hi Antoine,
On Tue, May 7, 2013 at 8:25 AM, Antoine Pitrou wrote:
> For me, a patch that mandated general-purpose containers (list, dict,
> etc.) respect object identity would be ok.
Thanks, that's also my opinion.
In PyPy's approach, in trying to emulate CPython vs. trying to
convince users th
On Mon, 06 May 2013 22:50:55 -0400
Terry Jan Reedy wrote:
>
> > 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
On Mon, May 6, 2013 at 7:50 PM, Terry Jan Reedy wrote:
> On 5/6/2013 6:34 PM, Antoine Pitrou wrote:
>
>> On Mon, 06 May 2013 18:23:02 -0400
>> Terry Jan Reedy wrote:
>>
>>>
>>> 'Item' is necessarily left vague for mutable sequences as bytearrays
>>> also store values. The fact that Antoine's exa
On 5/6/2013 6:34 PM, Antoine Pitrou wrote:
On Mon, 06 May 2013 18:23:02 -0400
Terry Jan Reedy 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-mand
On Mon, 06 May 2013 18:23:02 -0400
Terry Jan Reedy 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. You
On 5/6/2013 10:20 AM, Nick Coghlan wrote:
On Mon, May 6, 2013 at 11:26 PM, Antoine Pitrou wrote:
Le Mon, 6 May 2013 23:18:54 +1000,
Nick Coghlan a écrit :
We're not going to change the language design because people don't
understand the difference between "is" and "=="
For sure. The definit
On Mon, May 6, 2013 at 4:46 AM, Armin Rigo wrote:
> This is clearly a language design issue though. I can't really think
> of a use case that would break if we relax the requirement, but I
> might be wrong. It seems to me that at most some modules like pickle
> which use id()-keyed dictionaries
On Mon, May 6, 2013 at 11:26 PM, Antoine Pitrou wrote:
> Le Mon, 6 May 2013 23:18:54 +1000,
> Nick Coghlan a écrit :
>> We're not going to change the language design because people don't
>> understand the difference between "is" and "==" and then wrongly blame
>> PyPy for breaking their code.
>
>
Le Mon, 6 May 2013 23:18:54 +1000,
Nick Coghlan a écrit :
>
> IIRC, Jython just delays calculating the object id() until it is
> called, and lives with it potentially being incredibly expensive to
> calculate. Is there some way PyPy can run with a model where "is" is
> defined in terms of values
On Mon, May 6, 2013 at 6:46 PM, Armin Rigo wrote:
> This is clearly a language design issue though. I can't really think
> of a use case that would break if we relax the requirement, but I
> might be wrong. It seems to me that at most some modules like pickle
> which use id()-keyed dictionaries
On 5/6/2013 4:46 AM, Armin Rigo wrote:
'is' *is* well-defined. In production code, the main use of 'is' is for
builtin singletons, the bool doubleton, and object instances used as
sentinals. The most common use, in particular, is 'if a is None:'. For
such code, the result must be independent o
Hi all,
In the context PyPy, we've recently seen again the issue of "x is y"
not being well-defined on immutable constants. I've tried to
summarize the issues and possible solutions in a mail to pypy-dev [1]
and got some answers already. Having been convinced that the core is
a language design i
13 matches
Mail list logo
