[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [pygame] Odd key code behaviour
Michael Robin wrote:
>>
>> I always wondered why Python even included "is".
>> Given "explicit is better than implicit" and
>> the anti-TMTOWTDI senitments, I'd think that
>> the explict:
>> id(x) == id(y)
>> is much better than:
>> x is y.
>A thread like this just came up on the Tutor list. Remember one of
>Python's goals is to allow people to produce naturally looking source
>code, and "x is y" is just a natural thing to write. Especially for new
>programmers who might not have much of a clue of how objects are dealt
>with internally.
I think that's the problem - it "looks so natural"
that people will use it because it sounds nice.
("Is" is an exremely overload word in English.)
(If you look at c.l.py, I think you'll find that
some people new to Python will use "is" in place
of == by accident.) Object identity should be a fairly
infrequent operation compared to object equality - and
there are very complex and implementation-dependent
issues involved, as we see with the -1..100 case.
>> I always do this when I want to compare object
>> identity because it's so much more self documenting.
>I don't really see a difference. "is" can only be used in the one sense
>anyhow, so it acts as a constant alias for "id(x) == id(y)". Given this
>there's not really a chance that anybody could confuse it with anything
>else.
Sure, if you know what it does...
>Anyhow, just wanted to offer another POV on this. Sorry for being
>off-topic. :-)
Me too - I just bothered because I was just involved in a similar thread
in c.l.py (see below), and I only bothered with that because
it came up while trying to teach someone python.
Back to the regularly scheduled games...
- - - - - - - - - - - - - - -
The idea of 'same object' is really program- and language-implementation
dependent.
Even atomic objects can be tricky:
---------------------
>>> 12345678 is 12345678
>>> 1
>>> a = 12345678
>>> b = 12345678
>>> a is b
0
>>> 3 is 3
>>> 1
>>> a = 3
>>> b = 3
>>> a is b
1
--------------------
Small integers are optimized, so they will have the same object pointers,
but in general numbers aren't garanteed object identity.
Note that '12345678 is 12345678' (a one-liner) was not even
scalable to a two-liner at the interpreter prompt.
And of course, with floats you're not even sure about object equality...
As for strings, consider:
-----------------
>>>
>>> a = "abc1"
>>> b = "abc1"
>>> a is b
1
>>> "a b c 1" is "a b c 1"
1
>>> a = "a b c 1"
>>> b = "a b c 1"
>>> a is b
0
------------------
This is because as an optimization, the Python reader treats all
strings that are valid identifiers (even if they are 'constants')
specially - they are interned. (That is, they are added to a special
dictionary so that their id's will be the same, speeding up
compare operations later.) So in this case, the reader is effecting
object identity.
Python is not akin to a "hashed LISP" - so, in general,
the answer to:
> > since they are immutable, does it just "point" multiple
> > references to an identical tuple to the same object?
is 'no, they do not', unless you know that:
(a) they are "smallints"
(b) they are identifier-like strings interned by the reader,
or other objects the reader decides to cache.
(c) they are strings you interned yourself
(d) they are objects that you looked up in a mapping yourself
and arranged to point to the same object
(e) your algolrithm is designed to point like-objects to like-objects
by some other design.
(f) ??? (am I missing something?)
In general, if your objects are computed at run-time rather than
read by the reader, don't expect automagic object identity except in
rare cases.
As for lists, the way default args work (e.g., def fn(arg=[0]) )
is at least one reason why the reader can't hash them.
- - - - - - - - - - - - - -
--
======================================================================
Paul Sidorsky Calgary, Canada
paulsid@shaw.ca http://members.shaw.ca/paulsid/
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org