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.
not disabled file-extension registration, arrange for .py and .pyw files
to have an "Edit with IDLE" context (right-click) menu entry, selecting
which executes IDLE w/ the -e switch followed by the selected file's path.
IDLE and pydoc into a separate component. That's almost as big as the
rest of Python (excl. docs and test suite) combined.
Pop up a confimation box if they choose to install at least one of
{Tcl/Tk/IDLE/pydoc, Tools, Test suite} but do not choose to install
Python -- doesn't make much sense, so ask whether that's really what they
want.
LettError, Erik van Blokland, http://www.letterror.com/
the Python Windows installer finally has an attractive Pythonic bitmap
to delight the senses and dampen the fears of the millions and millions of
eager new Windows users anticipating their first Python programming joy.
Always knew Mac users secretly wanted to switch to Windows <wink>.
In the Wise installer's "Advanced Options" dialog, substitute in the
actual name of "the system directory" -- this is clearer, and especially
for people reading this dialog who aren't me <wink>.
mistake).
+ Arrange for Win2K Add/Remove to show a Python icon.
I think this "does it" -- a full install/uninstall can now be done on a
Win2K box from an ordinary (not Admin, not Power User) user acct, incl.
file extension registration, Start Menu entries, and full Add/Remove.
been overwriting them even if they have the same version, not just if
they're an older version (and our installers have always done this).
+ Added an "Advanced Options" subdialog to "Select Components". Allows
to do a non-admin install even if you have Administrator rights, and
to skip registering file extensions and/or creating Start Menu
shortcuts. Since so far these installers have been tested only by me,
and Win2K has been full of surprises, I want those options available
out in the field.
Lots of web searching turned up what should have been obvious: Because
Windows Installer is a native Win2K service, it can run at a higher
privilege level than the user invoking it. So MSI installs don't bash
into these permission gotchas on Win2K, but Wise 8.1 does (it's just
another app to Win2K, and we're not alone in wrestling with this; but,
like changing int division in Python, Win2K is doing a right thing <wink>).
Can't test it until getting to a Win2K box, because the non-Admin way
of setting file associations on Win2K doesn't work on any other flavor
of Windows (and other flavors of Windows never need Admin privs to
do it the old way).
+ Consequently got rid of the "Register file associations" Component and
associated GUI.
+ Added a line to the summary saying whether or not this is an Admin-level
install (I fear that will be an important clue someday).
+ Minor fiddling to the summary to reduce the # of lines. Added a
horizontal scrollbar in case the install path is very long.
+ Reworked the way the Main and Tools components share pydoc.pyw; cleaner
and simpler.
and install the Python and MS runtime DLLs into the Python dir instead of
a system dir.
Initial value is taken from new compiler vrbl _DOADMIN_ (default true),
and forced to false if the user doesn't have admin privs.
This makes it possible to *test* non-admin installs on machines where the
distinction doesn't exist (like my home box), via just changing _DOADMIN_.
It may also be useful for users who don't *want* an installer to
scribble into their system dir (for example, me(! most days)), but that
would require adding more GUI to let them get at it.
+ Fiddle vrbls so Win2K add/remove can display version w/o future manual
script fiddling.
+ Break apart the mysterious wizard-generated Win2K "Edit 3 Registry Keys"
script items by hand into 3 separate items, so you can see what the heck
they're doing in the script view.
+ pydoc.pyw was a problem: it's installed by both the Main and Tools
components. So when both were selected, the second time it got
installed Wise figured it was overwriting a pre-existing version, and
made a backup copy in BACKUP. A rollback-uninstall then restored that,
leaving the Tools/Scripts/ directory non-empty, and so Wise couldn't
remove that directory (or any above it). Fixed by installing pydoc.pyw
at most once.
+ Rearranged and commented the "register file extensions" section, because
it was confusing and needs more work: turns out it's not true that
Win2K requires Admin privs to register file extensions, BUT, if you
don't have Admin privs, Win2K requires a new way to register file
extensions, and a way that doesn't blow up but doesn't do any good either
on earlier Windows flavors. I think I know how to get this done, but am
too depressed to do it right now <0.7 wink>.
+ Ditto pydoc.
(IMO, both should have been done long ago -- simply didn't occur to
me before)
+ Build the summary text into a vrbl instead of a temp file. Doh! Less
fiddling, and should avoid another class of Win2K permission problems.
Bug: the "auto vertical scrollbar" control on the summary page doesn't
work (never creates a scrollbar, no matter how much text). So forced a
vertical scrollbar there.
summary of the preceding choices. No idea if this is "the right way" to
do it, but it's exactly painful enough to make me suspect it's the only
way <wink>.
delete the Tools and Lib directories at uninstall time. However,
under the old version of Wise, they didn't actually do anything. Under
the new version, they work as advertised, and even delete files users
added.
Got rid of those, and replaced them with similar uninstall cmds that
get rid of all .pyc and .pyo files (whether or not the installer created
them). This works nicely! It still tears down the directory structure,
except for those directories needed to get to any non-.pyc/o file(s) the
user may have added.
turns out the canned new "backup directory" dialog put its "back" and
"next" buttons at a different relative horizontal position than all the
other canned dialogs. This explains why you had to keep moving the
mouse around if you wanted to do a straight all-default install -- the
Next button kept moving around. Now the back/next buttons are in exactly
the same place on all dialogs, and you can click straight thru to the end.
about installing into a pre-existing directory *unless* you hit the
Browse button first. At least while testing, this screwed me repeatedly.
Plus I really liked the Inno Setup scheme of giving you a list box in
its "select directory" dialog without needing a distinct browse button
to ask for that.
So I redid this dialog from scratch: now gives a list box at once, the
browse button is gone, it asks for confirmation if the directory already
exists, and, since this is the first dialog in the set now, also removed
its "Back" button.
Tim Peters
Mark Hammond
Guido van Rossum
Martin v. Löwis