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.
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.
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.
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.
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>).
