[Python-Dev] sizeof(long) != sizeof(void*)

Martin v. Löwis martin at v.loewis.de
Tue Aug 5 21:46:25 EDT 2003


"Tim Peters" <tim.one at comcast.net> writes:

> Ah!  You must mean this line in test_buffer_info():
> 
>         self.assert_(isinstance(bi[0], int))

That's what I meant, indeed.

> > Likewise, test_descr expects that id() and hash() return the same value by
> > default.
> 
> Sorry, I couldn't follow that one.  Like, the id() and hash() of what?
> Certainly nobody expects, e.g., that hash("xyz") == id("xyz").

I mean this:

    # Test the default behavior for static classes
    class C(object):
        def __getitem__(self, i):
            if 0 <= i < 10: return i
            raise IndexError
    c1 = C()
    vereq(hash(c1), id(c1))


> 
> > Is that a bug in the Win64 port, or in the tests?
> 
> I don't understand what problem(s) you're seeing -- showing tracebacks is
> always more useful than trying to paraphrase in English.

Certainly, yes. Unfortunately, I don't have access to my Email account
at the same computer I have access to a Win64 machine, so I thought
paraphrasing might be sufficient - and indeed, in one case, you were
guessing right.

The third case is one of repr() failing, where it puts a "foo object
at ABCDEFL" in one place, and "foo object at abcdef" in the other,
for the test case

        i3 = ClassWithFailingRepr()
        eq(r(i3), ("<ClassWithFailingRepr instance at %x>"%id(i3)))


> Trent Mick did the Win64 port, and I believe all tests passed at the
> time he finished that.  'Twas quite a while ago, though, and I don't
> of anyone running tests on Win64 since then.  Still, because they
> used to pass, I expect any problems that may exist now are shallow.

I feel this is deeper: Should there be a guarantee that the type used
to represent <type 'integer'> is large enough to hold a void*, or not?

You seem to think that Python should make no such guarantee, which
would then indicate that three of the four failing tests are broken
(I'm uncertain about test_queue at the moment).

Regards,
Martin



More information about the Python-Dev mailing list