[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