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.
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>).
found a bug here. Here's the deal:
Class PyShell derives from class OutputWindow. Method PyShell.close()
wants to invoke its parent method, but because PyShell long ago was
inherited from class PyShellEditorWindow, it invokes
PyShelEditorWindow.close(self). Now, class PyShellEditorWindow itself
derives from class OutputWindow, and inherits the close() method from
there without overriding it. Under the old rules,
PyShellEditorWindow.close would return an unbound method restricted to
the class that defined the implementation of close(), which was
OutputWindow.close. Under the new rules, the unbound method is
restricted to the class whose method was requested, that is
PyShellEditorWindow, and this was correctly trapped as an error.
rather than the idle.py script. This has advantages and
disadvantages; the biggest advantage being that we can more easily
have an alternative main program.
Was getting mystery
ModifiedInterpreter instance has no attribute 'save_warnings_filters'
errors at odd times (for sure in a fresh IDLE, fresh file, then Run Script).
parsing functions in support of auto-indent weren't expecting Unicode
strings, but text.get() can now return them (although it remains muddy as
to exactly when or why that can happen). Fixed that with a Big Hammer.
subset of Win32 ShellExecute's functionality. Guido wants this because
IDLE's Help -> Docs function currently crashes his machine because of a
conflict between his version of Norton AntiVirus (6.10.20) and MS's
_popen. Docs for startfile are being mailed to Fred (or just read the
docstring -- it tells the whole story).
Changed webbrowser.py to use os.startfile instead of os.popen on Windows.
Changed IDLE's EditorWindow.py to pass an absolute path for the docs
(hardcoding ShellExecute's "directory" arg to "." as used to be done let
IDLE work, but made the startfile command exceedingly obscure for other
uses -- the MS docs are terrible, of course, & still not sure I
understand it).
Note that Windows Python must link with shell32.lib now! That's where
ShellExecute lives.
The cause was that the replace code necessarily used a PCRE internal
function to to template expansion.
The fix changes the code to use an SRE internal if SRE is used, and a
PCRE internal if SRE is used; in a way that should work with 1.5.2.
The solution can be sped up tremendously under the assumption that the
choice between sre and pre is not changed during the execution of the
program; especially replace-all will be slow.
But I'll leave that to someone else.
created. This allows the application-specific Tkinter
initialization to be executed if present. Also pass an explicit
className parameter to the Tk() constructor.
This closes SourceForge bug #110618.