On 2008-09-16, Maric Michaud <[EMAIL PROTECTED]> wrote: > Le Tuesday 16 September 2008 16:57:26 Grant Edwards, vous avez écrit : >> On 2008-09-16, Maric Michaud <[EMAIL PROTECTED]> wrote: >> > Le Tuesday 16 September 2008 15:57:53 Grant Edwards, vous avez écrit : >> >> On 2008-09-16, Maric Michaud <[EMAIL PROTECTED]> 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 : > > [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] 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! -- http://mail.python.org/mailman/listinfo/python-list