[ 587993 ] SET_LINENO killer
Remove SET_LINENO. Tracing is now supported by inspecting co_lnotab.
Many sundry changes to document and adapt to this change.
where it was: it is really a configuration file, not a normal module.
By moving it into Mac/Lib we can now also store the location of bgen
itself in there, which is needed because bgen isn't installed.
* globaltrace_lt - handle case where inspect.getmodulename doesn't return
anything useful
* localtrace_trace - handle case where inspect.getframeinfo doesn't return
any context info
I think both of the last two are caused by exec'd or eval'd code
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.
The staticforward define was needed to support certain broken C
compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the
static keyword when it was used with a forward declaration of a static
initialized structure. Standard C allows the forward declaration with
static, and we've decided to stop catering to broken C compilers. (In
fact, we expect that the compilers are all fixed eight years later.)
I'm leaving staticforward and statichere defined in object.h as
static. This is only for backwards compatibility with C extensions
that might still use it.
XXX I haven't updated the documentation.
1. BUGFIX: In function makefile(), strip blanks from the nodename.
This is necesary to match the behavior of parser.makeref() and
parser.do_node().
2. BUGFIX fixed KeyError in end_ifset (well, I may have just made
it go away, rather than fix it)
3. BUGFIX allow @menu and menu items inside @ifset or @ifclear
4. Support added for:
@uref URL reference
@image image file reference (see note below)
@multitable output an HTML table
@vtable
5. Partial support for accents, to match MAKEINFO output
6. I added a new command-line option, '-H basename', to specify
HTML Help output. This will cause three files to be created
in the current directory:
`basename`.hhp HTML Help Workshop project file
`basename`.hhc Contents file for the project
`basename`.hhk Index file for the project
When fed into HTML Help Workshop, the resulting file will be
named `basename`.chm.
7. A new class, HTMLHelp, to accomplish item 6.
8. Various calls to HTMLHelp functions.
A NOTE ON IMAGES: Just as 'outputdirectory' must exist before
running this program, all referenced images must already exist
in outputdirectory.
FLD: wrapped some long lines.
Not sure this is better in all cases.
parse(): Fixed a bug in the output; the dict is referred to in the
code as `countries' not `country'. Also added no-case-fold for the
string "U.S." since the Virgin Islands name no longer wraps those in
parentheses.
main(): Fixed the argument parsing to agree with the docstring, i.e.
--outputdict instead of --output.
In the module docstring:
- updated my email address
- we don't need to explain about Python 1.5 regexps <wink>
We also don't need to wrap the import of re with a try/except.
Other style fixes:
- untabification
- revert back to <> style everywhere (and consistently)
This patch replaces string module functions with string
methods in the Tools/world/world scripts.
It also updates two outdated URLs and the countrycodes
dictionary.
It fixes a bug where result of string.find() was checked
for truth instead of compared with -1.
It also replaces <> with != in two spots.
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.
pymalloc, apparently. Fixed, but this means all bgen-generated modules will
have to be re-generated.
I hope (and expect) that the pymalloc fixes aren't bugfix candidates, because
if they are this is one too.
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.
Raymond Hettinger