whether this is a correct thing to do:
+ There are linker warnings (see PCbuild\readme.txt).
+ test_bsddb passes, in both release and debug builds now.
+ test_bsddb3 has several failures, but it did before too.
Also made pythoncore a dependency of the _bsddb project, updated
build instructions, added database conversion XXX to NEWS, and fiddled
the Windows installer accordingly.
+ News blurb, but as much XXX as news.
+ Updated installer (install the new bsddb package, and the Berkeley DLL;
still don't know how to fold that into _bsddb.pyd).
+ Fleshed out build instructions.
+ Debug Python still blows up.
The bsddb subproject is gone.
The _bsddb subproject is new.
There are problems here, but I'm out of time to work on this now. If
anyone can address an XXX comment or two in readme.txt, please do!
running IDLE, and since I'm not a Tcl Guy I'm not sure what else to do.
Up to you! See XXX comments in PCbuild\readme.txt for cautions.
Also repaired typos in the new bz2-for-Windows instructions.
CAUTION: The Python test still has many failures, but I'm out of time
for this now (already took much longer than hoped to get this far).
The base bz2 library does pass its own tests (see next).
CAUTION: People building on Windows have to download and build tne
bz2 compression libraries now. See PCbuild\readme.txt for complete
instructions.
These built-in functions are replaced by their (now callable) type:
slice()
buffer()
and these types can also be called (but have no built-in named
function named after them)
classobj (type name used to be "class")
code
function
instance
instancemethod (type name used to be "instance method")
The module "new" has been replaced with a small backward compatibility
placeholder in Python.
A large portion of the patch simply removes the new module from
various platform-specific build recipes. The following binary Mac
project files still have references to it:
Mac/Build/PythonCore.mcp
Mac/Build/PythonStandSmall.mcp
Mac/Build/PythonStandalone.mcp
[I've tweaked the code layout and the doc strings here and there, and
added a comment to types.py about StringTypes vs. basestring. --Guido]
option. It was the cause of at least one way UNWISE.EXE could vanish
(install a python; uninstall it; install it again; reboot the machine;
abracadabra the uinstaller is gone).
Bugfix candidate, but I'll backport it myself.
Also move all _PyMalloc_XXX entry points into obmalloc.c.
The Windows build works fine.
The Unix build is changed here (Makefile.pre.in), but not tested.
No other platform's build process has been fiddled.
I'm guessing at this, pending more info from the bug submitter. Wise
changed how the %GROUP% vrbl got defined between versions 5.0a (used
before Python 2.2) and 8.14, to hold the full path to Start Menu group
instead of just the group name. If I'm guessing correctly, the info
the bug report is complaining about is in one of the registry keys
we set up that neither Windows nor Python cares about. We did store
a full path there in 2.2b1 instead of just the group name; the patch cuts
it back to just the name again.