module has to deal with "class" HTML-as-deployed as well as XHTML, so we
cannot be as strict as XHTML allows.

This closes SF bug #453059, but uses a different fix than suggested in
the bug comments.

a module.

Add test case to cover multiple future statements on separate lines of
a module.

Check return value from future_parse() in for loop for file_input to
accomodate multiple future statements on separate lines.

Add several comments explaining how the code works.

Remove out-dated XXX comment.

pass these tests.

This closes SF patch #452836.

description.

This fixes SF bug #453111.

Oops, these compatibility modules were missing. Which went unnoticed because their companions had been put in the wrong place.

in stead of in Carbon. Fixed.

like normal Python. toolbox modules are now in the Carbon package
in :Mac:Lib, with a workaround flat namespace in :Mac:Lib:lib-compat.
Other dynamic modules are in :Lib:lib-dynload. :Mac:Lib:lib-toolbox and
:Mac:Plugins are gone.

Dynamic modules are now put in :Lib:lib-dynload by default. For the toolbox modules this is overridden to put them in :Mac:Lib:Carbon.

Compatibility modules. lib-compat is on the default sys.path for MacPython 2.2, and each of these modules imports * from its namesake in the Carbon package.

the best of names right now (because QuickTime, for instance, is part of
its own framekwork in OSX terminology, and because all these modules also
work on pre-Carbon MacOS) but in a year or so it will be:-).

Moved here from lib-toolbox, where they should never have been in the first place (all the other stuff there wa generated with bgen).

like normal Python. toolbox modules are now in the Carbon package
in :Mac:Lib, with a workaround flat namespace in :Mac:Lib:lib-compat.
Other dynamic modules are in :Lib:lib-dynload. :Mac:Lib:lib-toolbox and
:Mac:Plugins are gone.

Carbon and its workaround.

longer supported) and updated MacOSX notes.

they were only in the repository for people building MacPython from
CVS (the .cmp project files are in a MacPython source
distribution). The process to regenerate them is now easier (and
documented!) so these shouldn't be needed anymore.

And eventually they should all be built by setup.py anyway.

code.  grrr...

reported by Greg Ball on python-dev.

443614.  I will submit a new feature request and patch to threading.py and
libthreading.tex to address the bounded semaphore issue.

company info in resource files; change installer strings to match.
This belongs in the release branch too, of course.

   This patch attempts to do to cPickle what Guido did
   for pickle.py v 1.50. That is: save_global tries
   importing the module, and fetching the name from the
   module. If that fails, or the returned object is not
   the same one we started with, it raises a
   PicklingError. (All this so pickling a lambda will
   fail at save time, rather than load time).

it may depend on.  It's really annoying that thread.o doesn't get
rebuilt when the .h file is changed! :-)

The dependency is on *all* the Python/thread_*.h files -- that should
be sufficient and rarely cause unneeded recompilations.