[Python-Dev] FW: 64-bit port of Python

[Trent Mick]

[Tim Peters]:
> Trent, you should be on the Python-Dev list if you're going to (as I sure
> hope you are!) be working on Python internals.  This requires Guido's
> approval, but in his temporary absence I'm channeling his
> approval for you.
> Guido can take it up with David Ascher if he doesn't like that (*nobody*
> messes with David -- the guy is a hard core psycho).

Thank you Tim! I went through the mailman subsription procedure and got the
expected "Subscription was deferred..." message. Will that sit quietly in
Guido's or Barry's mailbox?

>
> [on id]
> > This means that my System A and System B (above) get different
> > resultant object types for id() just because the compiler used
> > for their Python interpreter uses a different data model.
>
> So long as they're using different memory models, and so long as Python
> distinguishes between int and long, I'd say that's *expected*.  id()'s are
> valid only for the life of a single run, and, as Greg said, the only thing
> you can do with them that's guaranteed to work is compare them
> for equality
> (well, you can use cmp on 'em too, but that's unusual and will work fine
> anyway).

Unfortunately, the couple of examples that I picked to show that some
improper sizeof() assumptions still existed in the code included the id()
function. I did not mean to dwell on id() but rather that I thought it would
be reasonable that the Python core should run identically on (A) Trillian
(Linux64) on itanium (Intel64) and on (B) Win64 on itanium. Maybe not.


[Tim's good explanation of why a data typename abstraction layer is a bad
thing for Python]

Okay, I am convinced. My idealism is showing through.


> > Well, just using 'int' carries the implicit assumption that 'int'
> > is at least 16-bits wide.
>
> ANSI C guarantees that it is, BTW.

Surprise! I should know that. I suppose I was basing by assumptions on a
port of gcc to the HC11 (8-bit microprocessor) that I onced worked with that
had 8-bit ints.



Trent