literals optimization (was Re: append on lists)

[Grant Edwards]

On 2008-09-16, Maric Michaud <maric at aristote.info> wrote:
> Le Tuesday 16 September 2008 16:57:26 Grant Edwards, vous avez écrit :
>> On 2008-09-16, Maric Michaud <maric at aristote.info> wrote:
>> > Le Tuesday 16 September 2008 15:57:53 Grant Edwards, vous avez écrit :
>> >> On 2008-09-16, Maric Michaud <maric at aristote.info> wrote:
>> >> 
>> >> > all expressions that return something, return a new object,
>> >>
>> >> That's not _quite_ true:
>> >> >>> a=1
>> >> >>> b=a.__add__(0)
>> >> >>> a is b
>> >>
>> >> True
>> >>
>> >> ;)
>> >
>> > This is implementation specific,
>>
>> Indeed.
>>
>> > the specification of the language says that it should be
>> > false,
>>
>> That's curious.  If so, then the implimentation is in violating
>> the specification.
>
> But it doesn't matter

No argument.

> as the "is" operator is not relevant for any use case with
> scalars and even strings and the optimization is not
> negligible. In fact, I'd rather say it's unspecified, each
> implementation does it its own way.

I was just pointing out that for some degenerate cases in the
C-Python implementation, the statement "all expressions that
return something, return a new object" is not true.  I'm not
saying it ought to be true.  I'm just saying that if the
specification says that, it's a bug (in the specification,
IMO).

If the specification states that, then either the specification
should be changed, or the implementation should be changed.
Waving away specification violations with claims of "it doesn't
matter" just seems like bad practice.  If a requirement doesn't
matter, then remove it from the specification.

>> Where is that in the specification?
>
> Each literal creates a new instance, and instances of int are
> not supposed to be unique for each value (at less it's not
> specified so), so "1 is not 1", but implementation can cache
> integers, short strings, to avoid creating an new instance
> each time they appear in code.

Quite true, but that's not what I was asking.

I was asking where in the specification <http://docs.python.org/ref/ref.html> 
it says that all expressions that return something, return a
new object.  

> jython do this also for integer (see above), but not for strings :
>
> maric at redflag1 17:33:52:~$ jython
> Jython 2.2.1 on java1.6.0_07
> Type "copyright", "credits" or "license" for more information.
>>>> a = "aaaa"
>>>> a is "aaaa"
> 0
> maric at redflag1 17:36:48:~$ ipython
>
>>>>[1]: a = "aaaa"
>
>>>>[2]: a is "aaaa"
> ...[2]: True
>
> BTW, I'm talking of Jython 2.2, Jython 2.4, which quite ready I think, can 
> change his mind as well.
>
>> I suspect the statement in the specification should only apply
>> to mutable objects.
>
> No, CPython also have a unique empty tuple, but tuple literals
> are not cached nor there are compile-time optimization :

I don't see how that's material.  My suggestion was that the
requirement of "returning a new object" only apply to mutable
objects, since it's clearly not true for some immutable objects
[nor would there be any benefit for it to be so].

The behavior with immutable objects (integers and tuples) is
then irrelevent.

-- 
Grant Edwards                   grante             Yow! I didn't order any
                                  at               WOO-WOO ... Maybe a YUBBA
                               visi.com            ... But no WOO-WOO!