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

[Greg Stein]

On Wed, 9 Feb 2000, Trent Mick wrote:

>... description of Systems A and B

> [Greg Stein]:
>...
> > Assuming that we can say that id() is allowed to return a PyLongObject,
> > then this should just use PyLong_FromVoidPtr. On most platforms, it will
> > still return an Integer. For Win64 (and some other platforms), it will
> > return a Long.
> 
> 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. That sounds dangerous. Are there
> pickling portability issues or external interface issues? I know that noone
> should really need to be passing converted pointer results between
> platforms, but... shouldn't two Python interpreters running on identical
> hardware behave identically. This seems to me the only (or safest) way to
> guarantee portability.

No issues that I foresee. id() is only useful as an unique identifier, and
it should *only* be used as that. It should not be used as an access point
for an object's address.

Within a particular interpreter invocation, "id(x)==id(y)" IFF "x is y"
(as Tim Peters pointed out). This will hold for System A or B if id() can
return a long value.

Within a given pickle, an id() can only be used to match up references to
a single object. Again, this will continue to match.

For external interfaces, it is possible that people are passing id() to
something and that target is expecting an "int" rather than possible a
"long". IMO, that possibility is negligible. I've never seen it.

People do use the id() value when they are printing a repr() of objects.
Those uses may overflow, though, because people are using '%d' or '%x'
format codes. It should be %s.

>...
> > The problem already solved (it's so much fun to borrow Guido's time
> > machine!). Some of the C code just needs to catch up and use the new
> > functionality, though.
> 
> How so? Do you mean with PyLong_{As|From}VoidPtr()?

Yah.

>...
> Taking it as a given that Python should be made to run on the various 64-bit
> platforms,

Yes, that is a given. Python has been running on Alpha processors for a
long time now; I'd say you found bugs rather than semantic problems.

> there are two ways to deal with this:
> 1. Continue to base PyInt on 'long' and bolt on things like LONG_LONG,
> PyLong_FromVoidPtr with return types of either PyInt or PyLong as necessary;
> or
> 2. Add a level of typedef abstraction to decouple Python from the
> no-longer-really-valid wish that 'long' is that largest native integer and
> couple PyInt with the actual largest native integral value.
> 3. (I know I said there were only two. Spanish Iqui...:) Andrew Kuchling has
> this all under control (as Tim intimated might be the case) or I am really
> missing something.
>... discussion of options and intlongest_t and stuff ...

I think that you're concentrating on the wrong problem. PyInt and PyLong
are fine integer abstractions (and Andrew is working to minimize the
apparent differences). You're looking at changing Int/Long to solve the
"store a pointer into an integer-like thing." Instead, I think it is much
more straight-forward to look at why the pointer needs to be stored and
whether it matters that you use an Int or Long.

IMO, it doesn't matter what type is used to store pointer-values, as long
as you can go back/forth. There is no other operation needed.

In other words, rather than change the numeric model for what is a small
problem, just change the small problem. I would agree with you if there
was a fundamental, underlying problem, but I don't believe there is.
Integers store at least 32 signed bits of data, Longs store arbitrary
precision. Python doesn't deal with pointers, so I don't think we need to
design the integers around the capability of holding them.

Note that a C extension can also use PyCObject to store an arbitrary
pointer.

>...
> If you are skeptical because it sounds like I am just talking and asking for
> a volunteer to make these changes, it might help to know that I am
> volunteering to work on this. (Yes, Tim. ActiveState *is* paying me to look
> at this stuff.) I just want to see what the general reaction is to this: You
> are going about this in the wrong way? Go for it? Yes, but...?

Understood, but it seems like you would be applying your efforts for
little gain. IMO, the problem of storing pointers into integers is a red
herring.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/