find $(srcdir)/Lib -name '*.py[co]' -print | xargs rm -f
to remove all .py[co] files before testing, rather than just those in
the Lib/test directory. "find" is used all over the Makefile so I
suppose it's safe; how about xargs?
Handle <... at 001B6378> like <... at 0x120f80> (%p is platform-dependent).
Fix RCS version tag handling.
Move __main__ behaviour into a function, pydoc.cli().
described in PEP 227.
symtable_check_unoptimized() warns about import * and exec with "in"
when it is used in a function that contains a nested function with
free variables. Warnings are issued unless nested scopes are in
effect, in which case these are SyntaxErrors.
symtable_check_shadow() warns about assignments in a function scope
that shadow free variables defined in a nested scope. This will
always generate a warning -- and will behave differently with nested
scopes than without.
Restore full checking for free vars in children, even when nested
scopes are not enabled. This is needed to support warnings for
shadowing.
Change symtable_warn() to return an int-- the return value of
PyErr_WarnExplicit.
Sundry cleanup: Remove commented out code. Break long lines.
global after assign / use.
Note: I'm not updating the PyErr_Warn() call for import * / exec
combined with a function, because I can't trigger it with an example.
Jeremy, just follow the example of the call to PyErr_WarnExplicit()
that I *did* include.
to the class namespace.
Allow FTP.close() to be called more than once without tossing cookies.
(This seems to be a fairly common idiom for .close() methods, so let's
try to be consistent.)
warn_explicit(message, category, filename, lineno, module, registry)
The regular warn() call calculates a bunch of values and calls
warn_explicit() with these.
This will be used to issue better syntax warnings.
this just copies the __name__=='__main__' logic from pydoc.py.
?!ng can decide whether he wants to create a main() in pydoc, or rip
it out of pydoc.py completely.
header and central directory structures, and use them as appropriate.
The point being to make it easier to tell what is getting pulled out
where; magic numbers are evil!
Change the computation of the ZipInfo.file_offset field to use the
length of the relevant "extra" field -- there are two different ones,
and the wrong one had been used. ;-(
This closes SF tracker patch #403276, but more verbosely than the
proposed patch.
