The failure definitely seems timing related.  This change *seems* to work.
Since the failure isn't doesn't occur consistently, it's hard to tell.

Running these tests on Solaris in this order:
	test_urllibnet test_operator test_cgi \
	test_isinstance test_future test_ast test_logging

generally caused a failure (about 50% of the time) before the sleep.
I couldn't provoke the failure with the sleep.

This should really be cleaned up by using threading.Events or something
so it is not timing dependent and doesn't hang forever on failure.

  test_codecmaps_tw test_importhooks test_socket_ssl

I don't completely understand the cause, but there's a lot of import magic
going on and this is the smallest change which fixes the problem.

Actually define Py_RefTotal as a Py_ssize_t.

I tried to handle Win64 properly, but please review.

One place it wasn't necessary since mod was already checked.
Inline the check that mod != NULL for the other use.

Add note to NEWS.

- Do some minor code clean-ups.

testing line ending compatibility.

for it to claim it has mime-type application/octet-stream.

want to wait forever if we don't receive the last message.  But we also
don't want the test to fail if we shutdown too quickly.  I can't reliably
reproduce this failure, so I'm kinda guessing this is the problem.
We'll see if this band-aid helps.

Add it back.

be removed in 2.x.

 - regenerate ast.py
 - add future flags for absolute-import and with-statement so they
   (hopefully) properly get set in code-object flags
 - try out if/else expressions in actual code for the hell of it.

Seems to generate the same kind of bytecode as the normal compiler.

PyArena_New(); unsure what the intent is.

but without a specified encoding: decoding_fgets() (and decoding_feof()) can
return NULL and fiddle with the 'tok' struct, making tok->buf NULL. This is
okay in the other cases of calls to decoding_*(), it seems, but not in this
one.

This should get a test added, somewhere, but the testsuite doesn't seem to
test encoding anywhere (although plenty of tests use it.)

It seems to me that decoding errors in other places in the code (like at the
start of a token, instead of in the middle of one) make the code end up
adding small integers to NULL pointers, but happen to check for error states
before using the calculated new pointers. I haven't been able to trigger any
other crashes, in any case.

I would nominate this file for a comlete rewrite for Py3k. The whole
decoding trick is too bolted-on for my tastes.

(Should 'code' be cast to the right pointer type?)