Replaced outcomes from native Tcl/Tk tests. Maybe the diffs are legit,
maybe not. I noticed that the Tcl results I'm replacing here claimed
both that there were no failures, and that one file had tests with
failures, so I wasn't inclined to trust them <wink>.
removed the comment saying they don't work, and changed the build step
to run them. If they're failing for someone else, please give details
about what failed.
* Install the unittests, docs, newsitem, include file, and makefile update.
* Exercise the new functions whereever sets.py was being used.
Includes the docs for libfuncs.tex. Separate docs for the types are
forthcoming.
change the version number is no longer required.
Instead, a make_versioninfo.exe is compiled, which spits out an
include file for python_nt.rc.
Will backport to 2.3
The fix is confined to the Windows installer.
Not a bugfix candidate: the need for the new -n switch added here was
introduced by moving to the idlefork IDLE (so this change isn't needed
or helpful before 2.3).
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.
Martin v. Löwis
Tim Peters
Hye-Shik Chang
Anthony Baxter
Thomas Heller
Guido van Rossum
Jeremy Hylton
Mark Hammond
Raymond Hettinger
Kurt B. Kaiser
Just van Rossum