This patch corrects a problem in test_file.py on Windows:
f.truncate() seeks to the truncation point, but does not empty the
buffers. In the test, f.tell() returns -1...
(It's still technically broken since the va_args code assumes %x is
an int while we're passing a long, but that's mostly theoretical,
and it's done all over the place.)
Updates to ctypes for python 3.0 to make the tests pass.
Notable changes are:
- return bytes instead of str8
- integers in range(256) are accepted as "one char string":
libc.strchr("abcdef", 98) is now valid.
- directly use the wide-char version of the win32 function LoadLibrary.
Code that has been returning str8 becomes much more apparent thanks to this
(e.g., struct module returning str8 for all string-related formats or sqlite3
passing in str8 instances when converting objects that had a __conform__
method). One also has to watch out in C code when making a key from char *
using PyString in the C code but a str instance in Python code as that will not
longer compare equal.
Once str8 gains a constructor like the current bytes type then
test_modulefinder needs a cleanup as the fix is a little messy in that file.
Thanks goes to Thomas Lee for writing the patch for the change giving an
initial run-down of why most of the tests were failing.
Additional patch by Christian Heimes to deal more cleanly with the
FILE* vs file-descriptor issues.
I cleaned up his code a bit, and moved the lseek() call into import.c.
beginning of a file through a file pointer is not reflected when reading from a
file descriptor. Using both fflush() and fpurge() does not solve it. One must
use lseek() directly on the file descriptor to get the desired effect.
This might suggest that we standardize on either file pointers (FILE) or file
descriptors (int) for all C code used.
to be called a buffer). Shares code with stringobject when possible.
Adds unit tests with common code that should be usable to test the PEPs
mutable buffer() and immutable bytes() types.
http://bugs.python.org/issue1261
Changes to make __file__ a proper Unicode object, using the default
filesystem encoding.
This is a bit tricky because the default filesystem encoding isn't
set by the time we import the first modules; at that point we fudge
things a bit. This is okay since __file__ isn't really used much
except for error reporting.
Tested on OSX and Linux only so far.