2.3, support for source code encodings, so it shouldn't be backported
(no matter how attractive the checkin msg sounded).
Please, try to *use* IDLE before committing changes!
The test for re.engine was misfiring because re.engine is no longer
defined and the default was "pre" instead of "sre". Give up on 1.5.2
compatibility, hardcode the sre solution. However, this XXX comment
still applies, AFAIK:
# XXX This code depends on internals of the regular expression
# engine! There's no standard API to do a substitution when you
# have already found the match. One should be added.
revision 1.4 of CallTipWindow.py
SF bug 546078: IDLE calltips cause application error.
Assorted crashes on Windows and Linux when trying to display a very
long calltip, most likely a Tk bug. Wormed around by clamping the
calltip display to a maximum of 79 characters (why 79? why not ...).
Bugfix candidate, for all Python releases.
Provisional fix for writefile() [SF bug # 541730].
The problem was that an exception can occur in the text.get() call or
in the write() call, when the text buffer contains non-ASCII
characters. This causes the previous contents of the file to be lost.
The provisional fix is to call str(self.text.get(...)) *before*
opening the file, so that if the exception occurs, we never open the
file.
Two orthogonal better solutions have to wait for policy decisions:
1. We could try to encode the data as Latin-1 or as UTF-8; but that
would require IDLE to grow a notion of file encoding which requires
more thought.
2. We could make backups before overwriting a file. This requires
more thought because it needs to be fast and cross-platform and
configurable.
Original patches were:
python/dist/src/Tools/idle/IOBinding.py:1.6
introspection incompatibility, but in fact it's just that calltips
always gave up on a docstring that started with a newline (but
didn't realize they were giving up <wink>).
