On 02:17 pm, fij...@gmail.com wrote:
On Fri, Jul 8, 2011 at 4:14 PM, Amaury Forgeot d'Arc
<amaur...@gmail.com> wrote:
2011/7/8 Cesare Di Mauro <cesare.di.ma...@gmail.com>:
I fully agree. It's not an issue, but an implementation-specific
detail
which programmers don't have to assume always true.
CPython can be compiled without "smallints" (-5..256, if I remember
correctly) caching. There's a #DEFINE that can be disabled, so EVERY
int (or
long) will be allocated, so using the is operator will return False
most of
the time (unless you are just copied exactly the same object).
The same applies for 1 character strings, which are USUALLY cached by
CPython.
But the problem here is not object cache, but preservation of object
identity,
which is quite different.
Python containers are supposed to keep the objects you put inside:
[citation needed] array.array does not for one
Yes, and array.array is weird. :) It either exists as a memory
optimization (ie, I don't want objects) or a way to directly lay out
memory (to pass to a C API). Either way, you can't put arbitrary
objects into it either - so it's already a little special, even if you
disregard the fact that it doesn't preserve the identify the objects you
can put into it.
However, you're right. It exists, and it has this non-identity-
preserving behavior. Is it a good thing, though? Or just an accident
of how someone tried to let CPython be faster for some types of
problems?
myList.append(x)
assert myList(-1) is x
myDict[x] = 1
for key in myDict:
� �if key is x:
� � � �...
also dict doesn't work if you overwrite the key:
d = {1003: None}
x = 1003
d[x] = None
d.keys()[0] is x
This doesn't invalidate the original point, as far as I can tell. It
just demonstrates again that you can have two instances of 1003.
Whether dict guarantees to always use the new key or the old key when an
update is made is a separate question.
I think it would be better if object identity didn't depend on this
mysterious quality of "immutability". The language is easier to
understand (particularly for new programmers) if one can talk about
objects and references without having to also explain that _some_ data
types are represented using things that are sort of like objects but not
quite (and worse if it depends on what types the JIT feels like playing
with in any particular version of the interpreter).
Jean-Paul
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
