[Martin v. Lowis] > On Win64, a number of tests fail as they expect that a Python integer > can represent a platform pointer. If by "Python integer" we mean the union of int and long, that's a good assumption. > For example, test_array expects that buffer_info returns an integer. That can't be right -- buffer_info returns a tuple on all platforms. The first element of the tuple is constructed via PyTuple_SET_ITEM(retval, 0, PyLong_FromVoidPtr(self->ob_item)); and PyLong_FromVoidPtr() is supposed to be smart enough to return a Python long if sizeof(void*) > sizeof(long) (by way of the platform C "long long" type, which should be __int64 on any flavor of Windows). Ah! You must mean this line in test_buffer_info(): self.assert_(isinstance(bi[0], int)) That's clearly a bug in the test; it should read self.assert_(isinstance(bi[0], (int, long))) > 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"). > 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. 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4