M Bindings.py
M EditorWindow.py
M PyShell.py
M config-keys.def
M configHandler.py
M help.txt
1. Annotate the shell window with last restart boundary upon restart.
2. Provide a shell menu entry and hot key (F6) to jump to the last
restart boundary.
3. Add a new shell menu feature to restart the shell.
4. Update the help menu to add these features.
5. Update the help menu to put text in same order as the menus.
6. Correct a capitalization inconsistency on the Edit menu: Expand Word
7. Rename the "Debug" menu to be "Shell": it's doing more now.
8. Rearrange the "Shell" menu to make the StackViewer entries adjacent.
9. Add a get_geometry method to EditorWindow, which may be of use in
making window positions persisent.
10. Make <ctrl-v> the "Classic Windows" paste key.
11. Restore decorum on the Help menu by removing "Advice". As Guido said,
things will never be the same. Thanks, David!
Refactor code in PyCFunction_Call giving a modest (tiny) speed boost,
a slight improvement in semantics (now detects invalid flag combinations),
and (arguably) improved clarity (making it blindingly clear which flag
combinations are allowed). All this comes at a cost of a few lines of
code duplication.
* Folded test for METH_KEYWORDS into the switch/case.
* Deferred testing for an empty dictionary until when and where needed.
* Make a similar deferral for filling the "size" variable.
* Inverted the dictionary test so that the common case falls though
instead of making a jump.
Lesson learned: kids should not be allowed to use API's starting
with an underscore :-/
zipimport in 2.3a1 is even more broken than I thought: I attemped
to _PyString_Resize a string created by PyString_FromStringAndSize,
which fails for strings with length 0 or 1 since the latter returns
an interned string in those cases. This would cause a SystemError
with empty source files (and no matching pyc) in the zip archive.
I rewrote the offending code to simply allocate a new buffer and
avoid _PyString_Resize altogether.
Added a test that would've caught the problem.
because the test file, msg_26.txt which has \r\n line endings, was
getting munged by cvs, which knows to do line ending conversions for
text files. But we want \r\n to be preserved on all platforms, so we
cvs admin'd the file to be -kb (binary), which means we have to open
the file in binary mode to preserve these line ends. Hopefully this
will be the end of the thrashing on this issue (but probably not).
Test passes on *nix now, and Tim confirms it passes on Windows. We'll
leave it to Jack to test MacOS.
(or None) now. In 2.3a1 they could also return an int or long, but that
was an unhelpfully redundant leftover from an earlier version wherein
they couldn't return a timedelta. TOOWTDI.
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>!
On Windows, it was very common to get microsecond values (out of
.today() and .now()) of the form 480999, i.e. with three trailing
nines. The platform precision is .001 seconds, and fp rounding
errors account for the rest. Under the covers, that 480999 started
life as the fractional part of a timestamp, like .4809999978.
Rounding that times 1e6 cures the irritation.
Confession: the platform precision isn't really .001 seconds. It's
usually worse. What actually happens is that MS rounds a cruder value
to a multiple of .001, and that suffers its own rounding errors.
A tiny bit of refactoring added a new internal utility to round
doubles.
Skip Montanaro
Raymond Hettinger
Kurt B. Kaiser
Neal Norwitz
Martin v. Löwis
Tim Peters
Greg Ward
Walter Dörwald
Andrew M. Kuchling
Guido van Rossum
Just van Rossum
Michael W. Hudson
David Goodger
Barry Warsaw