Wasn't built on Windows; not in config.c either.
    Module init function missing DL_EXPORT magic.
    test_xreadline output file obviously wrong (started w/ "test_xrl").
    test program very unclear about what was expected.

documentation was written by Jeff Epler (thanks!).

Resurrected Small Carbon Python as a target in PythonStandSmall. Still no GUSI, though, so no socket/select/threads.

Carbon defines {Get,Set}ControlDataHandle, so unfortunately our variants on {Get,Set}ControlData have gotten an underscore: GetControlData_Handle, etc.

Carbon defines {Get,Set}ControlDataHandle, so unfortunately our variants on {Get,Set}ControlData have gotten an underscore: GetControlData_Handle, etc. This is an incompatible change:-(

Various tweaks to make it everything build and compile again under carbon. Mainly greylisted functions.

to the Global Module Index for a set of documents.  This is used to include
a reference to the global index from the per-document module indexes, so
that it is just a little easier to find.

(Someone suggested this, but I do not remember who.  Please let me know if
it was you -- thanks!)

the xreadlines module and lets it do its thing.)

changes for safety and tuning.

Clarify the handling of characters following backslashes in raw strings.

Moved the mutex docs to be adjacent to the sched docs, since these are
meant to be used together (if they are used at all!).

   os.pathsep

    encounters a string with an unmatched quote, by adding a check for
    EOF in the 'quotes' state.

#127718: '@' and '`' seem to be confused.

a fallback for TELL64.  Fixes SF Bug #128119.

including "tmpfile" in the posix_methods[] array is wrong -- should be
HAVE_TMPFILE, not HAVE_TMPNAM.

requiring the whole option to be typed out.

This closes SF bug #126863.

the constructor.

                  Unicode); raise TypeError if not.

This closes SF bug #126866.

Tim discovered another "bug" in my get_line() code: while the comments
said that n<0 was invalid, it was in fact still called with n<0 (when
PyFile_GetLine() was called with n<0).  In that case fortunately
executed the same code as for n==0.

Changed the comment to admit this fact, and changed Tim's MS speed
hack code to use 'n <= 0' as the criteria for the speed hack.

code duplication is to let us get away without a realloc whenever possible;
boosted the init buf size (the cutoff at which we *can* get away without
a realloc) from 100 to 200 so that more files can enjoy this boost; and
allowed other threads to run in all cases.  The last two cost something,
but not significantly:  in my fat test case, less than a 1% slowdown total.
Since my test case has a great many short lines, that's probably the worst
slowdown, too.  While the logic barely changed, there were lots of edits.
This also gets rid of the reference to fp->_cnt, so the last platform
assumption being made here is that fgets doesn't overwrite bytes
capriciously (== beyond the terminating null byte it must write).

variant that never needs to "search from the right".
Also fixed unlikely memory leak in get_line, if string size overflows INTMAX.
Also new std test test_bufio to make sure .readline() works.

realized that this behavior is already present in PyFile_GetLine(),
which is the only place that needs it.  A little refactoring of that
function made get_line_raw() redundant.