the patch or forgot about it -- this is easier than reminding him).

HTML generation; the machinery was there but no option to set it was
defined.

Simplify some of the path-math since we can assume a recent version of
Python.

In test_poll1(), unregister file descriptors as they're closed,
    and also close the read end of the pipe
In test_poll2(), make the code assume less about the combinations of flag
    bits that will be returned

Makefile.deps.

figures out old (a.out) and newer (ELF) systems, similar to NetBSD.

(I'm assuming this is also by tg@FreeBSD.org.)

Our (FreeBSD's) security officer doesn't like
group-writable directories and sent a patch;
don't install *.orig.

-- tg@FreeBSD.org

This helps on 4.4BSD-based systems.

of extended print.  If the file object being printed to is None, then
sys.stdout is used.

Changed 'core.setup()' so it sets them to reasonable defaults.
Tweaked how the "usage" string is generated: 'core' now provides
  'gen_usage()', which is used instead of 'USAGE'.
Modified "build_py" and "sdist" commands to refer to
  'self.distribution.script_name' rather than 'sys.argv[0]'.

with success.  also, check return values from the mark functions.

this addresses (but doesn't really solve) bug #112693, and low-memory
problems reported by jack jansen.

Fix bad operator precedence: should be "(metadata or '') + '\n'".

how 'import' was called with a compiletime mechanism: create either a tuple
of the import arguments, or None (in the case of a normal import), add it to
the code-block constants, and load it onto the stack before calling
IMPORT_NAME.

mean; the same as 'from mod import submod as s'.

PyRun_FileEx().  These are the same as their non-Ex counterparts but
have an extra argument, a flag telling them to close the file when
done.

Then this is used by Py_Main() and execfile() to close the file after
it is parsed but before it is executed.

Adding APIs seems strange given the feature freeze but it's the only
way I see to close the bug report without incompatible changes.

[ Bug #110616 ] source file stays open after parsing is done (PR#209)

couple of potential stack overflows, including bug #110615.

closes patch #101238

fork.  This solves the test_fork1 problem.  (ceval.c, signalmodule.c,
intrcheck.c)

SourceForge: [ Patch #101226 ] make threading fork-safe

Again due to the duplicate copies of test_support, the checked-in
"expected output" file actually contains verbose-mode output.

subtle breakage on Windows (the test is skipped here, but the TestSkipped
exception wasn't recognized as such, because of duplicate copies of
test_support got loaded; so the test looks like a failure under Windows
instead of a skip).
Repaired the import, but

        THIS TEST *WILL* FAIL ON OTHER SYSTEMS NOW!

Again due to the duplicate copies of test_support, the checked-in
"expected output" file actually contains verbose-mode output.  I can't
generate the *correct* non-verbose output on my system.  So, somebody
please do that.

Windows "inconsistent linkage" warnings at the same time.  I agree
with Mark Hammond that the whole DL_IMPORT/DL_EXPORT macro system
needs an overhaul; this is just an expedient hack until then.

The known bug (bogus error message when an empty file is
extracted) is fixed.

Other changes:

- The target-compile and target-optimize flags of bdist_wininst
  are gone. It is no longer possible to compile the python
  files during installation.
- The zlib module is no longer required or used by bdist_wininst.

- I moved the decompression/extraction code into a separate
  file (extract.c).

- The installer stub is now compressed by UPX (see
  http://upx.tsx.org/). This reduces the size of the exe
  (and thus the overhead of the final installer program)
  from 40 kB to 16 kB.

- The installer displays a more uptodate user wizard-like
  user interface, also containing a graphic: Just's Python Powered logo.
  (I could not convince myself to use one of the BeOpen logos).
- The installation progress bar now moves correctly.

don't assign None to any attributes of the Extension object.

Add some test cases.

file.writelines() now tries to emulate the behaviour of file.write()
as closely as possible. Due to the problems with releasing the
interpreter lock the solution isn't exactly optimal, but still better
than not supporting the file.write() semantics at all.

to be extended somewhat -- right now it only tests the .writelines()
method.