fix the hangs on Win98SE when starting IDLE via "python" from a DOS box,
but did appear to make them harder to provoke. I closed that bug report
as being hopeless (and if someone wants to open it again, don't dare
assign it to me again <0.1 wink>).
Tools/idle, in both source and destination. (There are still problems
when running the IDLE icon, but they don't seem to have to do with the
installer.)
This file isn't meant to be executed, it's data input for test_tokenize.py.
The problem with the .py extension is that it uses "non-standard"
indentation, and it's good to test that, but reindent.py keeps wanting
to fix it. But fixing the indentation causes the expected-output file to
change, since exact line and column numbers are part of the
tokenize.tokenize() output getting tested.
After removing that, two testers on machines where C: is not the system
drive reported that the installer suggested their system drive instead
of C:, and that's what they wanted it to do.
PC/python_nt.rc sets up the DLL version resource (displayed when you
right-click on the DLL and select Properties).
PCbuld/python20.wse sets up the installer version resource (displayed
when you right-click on the installer .exe and select Properties). Turns
out this one hadn't been updated since 2001 <frown>!
Added the logging package. In the meantime, Neal Norwitz added a
test_logging.py to the std test suite, which would have caught this
oversight in the Windows installer.
- new import hooks in import.c, exposed in the sys module
- new module called 'zipimport'
- various changes to allow bootstrapping from zip files
I hope I didn't break the Windows build (or anything else for that
matter), but then again, it's been sitting on sf long enough...
Regarding the latest discussions on python-dev: zipimport sets
pkg.__path__ as specified in PEP 273, and likewise, sys.path item such as
/path/to/Archive.zip/subdir/ are supported again.
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.
GUI inserting those once before shortly after I started using it, but
don't know what triggers it -- presumably something in the "expert" view
(which is, suitably enough, unsuited to experts <wink>).
plain unprivileged User acct:
+ Had to duplicate Wise's Uninstal.wse script, in order to change the line
at its end that unconditionally tries to write uninstall info under HKLM.
This is our new file Uninstal.wse, which must be included by python20.wse
instead of using Wise's version.
+ In every other case we write to HKLM, also write to HKCU instead (we
were already doing that in *most* places, but not quite all).
+ If the user doesn't have admin privs, the DLLs we usually write to the
system dir are written to the root of the Python installation instead.
That's python22.dll, plus the two MSVC runtime DLLs.
+ Added a new component "Register file extensions". Registering .py etc
is done under HKEY_CLASSES_ROOT, and that also requires admin privs;
i.e., AFAICT it's impossible for an unprivileged user to accomplish this.
In the component selection dialog, if the user doesn't have admin privs
I gray out this new component so the user knows they aren't getting file
extensions.
After all that, Python installs, the Start Menu entries are OK, it runs
its test suite to completion, and the uninstaller works too. Only known
problem so far is that the integration with Win2K's Add/Remove subsystem
isn't quite right yet in this irritating case.
1. Only .py files were getting installed.
2. Empty CVS directories were getting created.
Both were due to trying to get away with "recursively copy *.py" one-
liner scripting.
Got rid of useless "Welcome" screen.
Folded Tcl/Tk into the main Python component.
Bug introduced during upgrade: Start Menu entries didn't work if
installation was to a path with an embedded space, because the
enclosing quotes somehow got dropped on the cmdline args. Repaired.
Years of wizard-generated code blocks left this script hard to read.
Added many more comments, blank lines, and rearranged related code
into related blocks where they had drifted apart.
Added %_PYMAJOR_% and %_PYMINOR_% compiler vrbls, and reworked script
items to use them as appropriate. This should slash the amount of
hand-fiddling needed when version numbers change. Indeed, in the
body of the script, only the first line should need changing now.
Deleted unreferenced wizard-generated compiler vrbls.
"relative paths" option is enabled, 8.1 rewrites *every* path to be
relative to PCbuild (the dir containing the .wse script), even absolute
paths you type in by hand, paths to the Wise installation itself, and even
paths to the Windows directories (sheesh). Only way to stop it is to
start a path with a variable reference, and we screwed ourselves before
by not using the predefined %_WISE_% vrbl to point to the Wise
installation. Repaired that old, repeated and well-hidden mistake.
Also:
+ Got rid of the %_SRC_% vrbl (such paths always relative to PCBuild now).
+ Changed the %_DOC_% vrbl to prompt for the location of the unzipped
HTML files (defaults to ..\html, cuz that's where I put them, but I
expect I'll change that later cuz I always hated mixing the generated
docs into the CVS tree ... Guido, if you're reading this, where did you
unpack the docs when building a Windows installer? Happy to oblige.).
+ Stopped the generated installer from filling up the entire screen (got
rid of the massive blue background gradient -- new option).
+ Added the helpful app publisher and app URL registry entries that Win2K
displays in its version of Add/Remove.
the old script without any complaints, didn't demand any manual changes,
and built a working installer from it that acts very much like the old one.
It did add a few script items, and changed one, so checking it in now
before I break everything again.
As the bug report notes, the Windows installer creates a useless pydoc
file in the base directory. Changed the installer to rename it pydoc.pyw
instead.
This involves changing the zlib build process to build zlib itself from sources, then use that library. Also updated are the comments to reflect the new official home of zlib, and add Windows specific notes regarding the build process.
Tim Peters
Guido van Rossum
Mark Hammond
Raymond Hettinger
Martin v. Löwis
Just van Rossum
Thomas Wouters