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.

class, I came up with an even simpler solution: raise the error in
__getattr__().

right way").  Fiddle __future__.py to use them.

Jeremy's pyassem.py may also want to use them (by-hand duplication of
magic numbers is brittle), but leaving that to his judgment.

Beef up __future__'s test to verify the exported feature names appear
correct.

Change to get/set/del slice operations so that if the object doesn't
support slicing, *or* if either of the slice arguments is not an int
or long, we construct a slice object and call the get/set/del item
operation instead.  This makes it possible to design classes that
support slice arguments of non-integral types.

For the HTTPS class (when available), ensure that the x509 certificate data
gets passed through to the HTTPSConnection class. Create a new
HTTPS.__init__ to do this, and refactor the HTTP.__init__ into a new _setup
method for both init's to call.

Note: this is solved differently from the patch, which advocated a new
**x509 parameter on the base HTTPConnection class. But that would open
HTTPConnection to arbitrary (ignored) parameters, so was not as desirable.

Entries taken from the standard Debian mime.types file.

A few enhancements are pending, but this should work reliably.

This breaks software that excepts a socket.error but not an
AttributeError.

Change several sections to subsections (part of the manual -> howto
transformation).

Flesh out discussion of assignment nodes (and delete statements).

Add an example of manipulating AST objects at a >>> prompt

somewhat less horrid hack <wink>:  if a module does
    from __future__ import X
then the module dict D is left in a state such that (viewing X as a
string)
    D[X] is getattr(__future__, X)
So by examining D for all the names of future features, and making that
test for each, we can make a darned good guess as to which future-features
were imported by the module.  The appropriate flags are then sucked out
of the __future__ module, and passed on to compile()'s new optional
arguments (PEP 264).

Also gave doctest a meaningful __all__, removed the history of changes
(CVS serves that purpose now), and removed the __version__ vrbl (similarly;
before CVS, it was a reasonable clue, but not anymore).

Fix Module() handler to avoid including the doc string in the AST

builtin_eval wasn't merging in the compiler flags from the current frame;
I suppose we never noticed this before because future division is the
first future-feature that can affect expressions (nested_scopes and
generators had only statement-level effects).

Bill Fancher found this one.

    #449043 supporting __future__ in simulated shells
which implements PEP 264.

interpretation of negative indices, since neither the sq_*item slots
nor the slot_ wrappers do this.  (Slices are a different story, there
the size wrapping is done too early.)

CO_FUTURE_DIVISION flag.  Redid this to use Jeremy's PyCF_MASK #define
instead, so we dont have to remember to fiddle individual feature names
here again.

pythonrun.h:  Also #define a PyCF_MASK_OBSOLETE mask.  This isn't used
yet, but will be as part of the PEP 264 implementation (compile() mustn't
raise an error just because old code uses a flag name that's become
obsolete; a warning may be appropriate, but not an error; so compile() has
to know about obsolete flags too, but nobody is going to remember to
update compile() with individual obsolete flag names across releases either
-- i.e., this is the flip side of PyEval_MergeCompilerFlags's oversight).

Classes that don't use __slots__ have a __weakref__ member added in
the same way as __dict__ is added (i.e. only if the base didn't
already have one).  Classes using __slots__ can enable weak
referenceability by adding '__weakref__' to the __slots__ list.

Renamed the __weaklistoffset__ class member to __weakrefoffset__ --
it's not always a list, it seems.  (Is tp_weaklistoffset a historical
misnomer, or do I misunderstand this?)