Is the explanation of the 'stacklevel' parameter clear? Please feel free
to edit it.
I don't have LaTeX installed on this machine, so haven't verified that the
markup is correct. Will check tonight, or maybe the automatic doc build will
tell me.
The information about supporting weakrefs with types defined in C extensions
is moved to the Extending & Embedding manual. Py_TPFLAGS_HAVE_WEAKREFS is
no longer mentioned since it is part of Py_TPFLAGS_DEFAULT.
We want to encourage users to write open() when opening a file, but
open() was described with a single paragraph and
'file' had lots of explanation of the mode and bufsize arguments.
I've shrunk the description of 'file' to cross-reference to the 'File
objects' section, and to open() for an explanation of the arguments.
open() now has all the paragraphs about the mode string. The bufsize
argument was moved up so that it isn't buried at the end; now there's
1 paragraph on mode, 1 on bufsize, and then 3 more on mode. Various
other edits and rearrangements were made in the process.
It's probably best to read the final text and not to try to make sense
of the diffs.
41667, 41668 - initial switch to xmlcore
47044 - mention of xmlcore in What's New
50687 - mention of xmlcore in the library reference
re-apply xmlcore changes to xml:
41674 - line ending changes (re-applied manually), directory props
41677 - add cElementTree wrapper
41678 - PSF licensing for etree
41812 - whitespace normalization
42724 - fix svn:eol-style settings
43681, 43682 - remove Python version-compatibility cruft from minidom
46773 - fix encoding of \r\n\t in attr values in saxutils
47269 - added XMLParser alias for cElementTree compatibility
additional tests were added in Lib/test/test_sax.py that failed with
the xmlcore changes; these relate to SF bugs #1511497, #1513611
The constructor docs referred the reader to the add_data() method's docs,
but they weren't very helpful. I've simply copied an earlier explanation
of 'data' that's more useful.
with PEP 302. This was fixed by adding an ``imp.NullImporter`` type that is
used in ``sys.path_importer_cache`` to cache non-directory paths and avoid
excessive filesystem operations during imports.
concept, and that different ways of trying to find "the
hardware address" may return different results. Certainly
true on both of my Windows boxes, and in different ways
(see whining on python-dev).