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.
Python warning which can be catched by means of the Python warning
framework.
It also adds two new APIs which hopefully make it easier for Python
to switch to buffer overflow safe [v]snprintf() APIs for error
reporting et al. The two new APIs are PyOS_snprintf() and
PyOS_vsnprintf() and work just like the standard ones in many
C libs. On platforms which have snprintf(), the native APIs are used,
on all other an emulation with snprintf() tries to do its best.
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.
Fix suggested by Michael Hudson: Raise TypeError if attribute name
passed to getattr() is not a string or Unicode. There is some
unfortunate duplication of code between builtin_getattr() and
PyObject_GetAttr(), but it appears to be unavoidable.
And remove all the extern decls in the middle of .c files.
Apparently, it was excluded from the header file because it is
intended for internal use by the interpreter. It's still intended for
internal use and documented as such in the header file.
If pyexpat is not available and more than one attempt is made to load
an expat-based xml parser, an empty xml.parser.expat module will be
created. This empty module will confuse xml.sax.expatreader into
thinking that pyexpat is available.
The ugly fix is to verify that the expat module actually defines the
names that are imported from pyexpat.
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.