are some unicode values used.  I'm not sure if this is the correct
on all operating systems, but this works on Linux w/o unicode.

making it unicode with the default encoding.  I'm not sure if this is
a problem in and of itself.  However, the test seems to be testing
something different, so at least get that working.  Need to revisit
the unicode problem.

Changed bytes.fromhex to take a str argument, as the docstring promises.
Added str8.fromhex (untested so far).

(We should also kill the other PyString_ encode/decode APIs, but they
still have some users.)

about whether it's testing str8 or str...  The stuff that matters is already
tested in test_unicode.py anyway.

Add a bytes iterator (copied from stringobject.c and reindented :-).
I (Guido) added a small change to _abcoll.py to remove the registration
of bytes as a virtual subtype of Iterator -- the presence of __iter__
will handle that now.

Move most of the messiness with truncate() on Windows into _fileio.c.
Still keep the flush() call in io.py though.

is larger than what can fit into a long (4 bytes).  Hopefully this will
fix more problems than it creates.  There are many, many compile warnings
on Win64.  Each of these should be investigated to determine if they
are real problems or not.  Many of these presumably affect the trunk too.

bytes type.

The patch fixes some of the problems on Windows. It doesn't introduce
addition problems on Linux.

The patch fixes the output for profile and cProfile. Another patch from
Alexandre and me added additional calls to the UTF-8 codec.

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...

and os.tmpfile().

Also remove an unnecessary incref/decref for `name'.

(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.)

issues with <ctype.h> on various platforms.  We no longer use <ctype.h>.

Added unittest for calling a function with paramflags.

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.

Fix failing unittests for time and strptime on German and probably other
localized Windows installations.

characters as mapping keys and invalid mapping keys are recognized
and raise an error.

Add md5module.c and sha1module.c to the project files,
and in some cases bytes_methods.c and related .h files.

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.