writing the crc to file on the "PPC64 Debian trunk" buildbot
when running test_tarfile.
This is again a case where the native zlib crc is an unsigned
32-bit int, but the Python wrapper implicitly casts it to
signed C long, so that "the sign bit looks different" on
different platforms.
buildbot (& possibly other 64-bit boxes) during test_gzip.
The native zlib crc32 function returns an unsigned 32-bit integer,
which the Python wrapper implicitly casts to C long. Therefore the
same crc can "look negative" on a 32-bit box but "look positive" on
a 64-bit box. This patch papers over that platform difference when
writing the crc to file.
It may be better to change the Python wrapper, either to make
the result "look positive" on all platforms (which means it may
have to return a Python long at times on a 32-bit box), or to
keep the sign the same across boxes. But that would be a visible
change in what users see, while the current hack changes no
visible behavior (well, apart from stopping the struct deprecation
warning).
Note that the module-level write32() function is no longer used.
Patch by Douglas Greiman.
The test_run_abort() testcase produces a core file on Unix systems,
even though the test is successful. This can be confusing or alarming
to someone who runs 'make test' and then finds that the Python
interpreter apparently crashed.
warning on Windows.
Afraid I can't detect a pattern to when the pack formats decide
to use a signed or unsigned format code -- appears nearly
arbitrary to my eyes. So I left all the pack formats alone and
changed the special-case data values instead.
warnings on Win32.
Also added an XXX about the line:
pos3 = self.fp.tell()
`pos3` is never referenced, and I have no idea what the code
intended to do instead.
These problems may mask more important, real problems.
One or both methods are known to fail on: Solaris, OpenBSD, Debian, Ubuntu.
They pass on Windows and some Linux boxes.
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
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).
inspect.py, and pydoc.py. Specifically, this allows for querying the type of
an object against these built-in C types and more importantly, for getting
their docstrings printed in the interactive interpreter's help() function.
This patch includes a new built-in module called _types which provides
definitions of getset and member descriptors for use by the types.py module.
These types are exposed as types.GetSetDescriptorType and
types.MemberDescriptorType. Query functions are provided as
inspect.isgetsetdescriptor() and inspect.ismemberdescriptor(). The
implementations of these are robust enough to work with Python implementations
other than CPython, which may not have these fundamental types.
The patch also includes documentation and test suite updates.
I commit these changes now under these guiding principles:
1. Silence is assent. The release manager has not said "no", and of the few
people that cared enough to respond to the thread, the worst vote was "0".
2. It's easier to ask for forgiveness than permission.
3. It's so dang easy to revert stuff in svn, that you could view this as a
forcing function. :)
Windows build patches will follow.
When a node number disagrees, keep track of all sources & the
node numbers they reported, and stick all that in the error message.
Changed all callers to supply a non-empty "source" argument; made
the "source" argument non-optional.
On my box, test_uuid still fails, but with the less confusing output:
AssertionError: different sources disagree on node:
from source 'getnode1', node was 00038a000015
from source 'getnode2', node was 00038a000015
from source 'ipconfig', node was 001111b2b7bf
Only the last one appears to be correct; e.g.,
C:\Code\python\PCbuild>getmac
Physical Address Transport Name
=================== ==========================================================
00-11-11-B2-B7-BF \Device\Tcpip_{190FB163-5AFD-4483-86A1-2FE16AC61FF1}
62-A1-AC-6C-FD-BE \Device\Tcpip_{8F77DF5A-EA3D-4F1D-975E-D472CEE6438A}
E2-1F-01-C6-5D-88 \Device\Tcpip_{CD18F76B-2EF3-409F-9B8A-6481EE70A1E4}
I can't find anything on my box with MAC 00-03-8a-00-00-15, and am
not clear on where that comes from.
Fix the DllGetClassObject and DllCanUnloadNow so that they forward the
call to the comtypes.server.inprocserver module.
The latter was never documented, never used by published code, and
didn't work anyway, so I think it does not deserve a NEWS entry (but I
might be wrong).
it into email 4.0. Specifically, in Message.get_content_charset(), handle RFC
2231 headers that contain an encoding not known to Python, or a character in
the data that isn't in the charset encoding. Also forward port the
appropriate unit tests.
