Barry Warsaw [Sun, 3 Oct 2004 03:16:19 +0000 (03:16 +0000)]
Big email 3.0 API changes, with updated unit tests and documentation.
Briefly (from the NEWS file):
- Updates for the email package:
+ All deprecated APIs that in email 2.x issued warnings have been removed:
_encoder argument to the MIMEText constructor, Message.add_payload(),
Utils.dump_address_pair(), Utils.decode(), Utils.encode()
+ New deprecations: Generator.__call__(), Message.get_type(),
Message.get_main_type(), Message.get_subtype(), the 'strict' argument to
the Parser constructor. These will be removed in email 3.1.
+ Support for Python earlier than 2.3 has been removed (see PEP 291).
+ All defect classes have been renamed to end in 'Defect'.
+ Some FeedParser fixes; also a MultipartInvariantViolationDefect will be
added to messages that claim to be multipart but really aren't.
+ Updates to documentation.
Armin Rigo [Sat, 2 Oct 2004 13:59:34 +0000 (13:59 +0000)]
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
Just van Rossum [Sat, 2 Oct 2004 08:40:47 +0000 (08:40 +0000)]
Which reminds me, I've had a much improved plistlib.py lying around for
ages. The main improvements are:
- a much more convenient API: readPlist() and writePlist()
- support non-dict top-level objects
* Elaborate on the invariant comments and make them more precise.
* Change the centering by one to make it possible to test the module
with BLOCKLEN's as low as two. Testing small blocks makes end-point
errors surface more readily.
Tim Peters [Fri, 1 Oct 2004 02:01:04 +0000 (02:01 +0000)]
deque_traverse(): If the deque had one block, and its rightindex was
BLOCKLEN-1, this assert-failed in a debug build, or went wild with a
NULL pointer in a release build. Reported on c.l.py by Stefan Behnel.
Expand scope to include general mapping protocol tests.
Many of these tests are redundant, but this will ensure
that the mapping protocols all stay in sync.
Also, added a test for dictionary subclasses.
Improve error message for augmented assignments to genexps or listcomps.
Rather than introduce new logic, took the approach of making the message
itself more general.
Tim Peters [Tue, 28 Sep 2004 16:12:50 +0000 (16:12 +0000)]
A number of list examples used 66.6, but I doubt there's any box on which
repr(66.6) == "66.6", so doubt that the claimed output has ever been seen.
Changed it to 66.25 everywhere, and manually verified that the new claimed
output is correct.
Edward Loper [Tue, 28 Sep 2004 05:50:57 +0000 (05:50 +0000)]
Reverted the addition of a NORMALIZE_NUMBERS option, per Tim Peter's
request. Tim says that "correct 'fuzzy' comparison of floats cannot
be automated." (The motivation behind adding the new option
was verifying interactive examples in Python's latex documentation;
several such examples use numbers that don't print consistently on
different platforms.)
Edward Loper [Tue, 28 Sep 2004 04:29:57 +0000 (04:29 +0000)]
Added a new NORMALIZE_NUMBERS option, which causes number literals in
the expected output to match corresponding number literals in the
actual output if their values are equal (to ten digits of precision).
Checkin Tim's fix to an error discussed on python-dev.
Also, add a testcase.
Formerly, the list_extend() code used several local variables to remember
its state across iterations. Since an iteration could call arbitrary
Python code, it was possible for the list state to be changed. The new
code uses dynamic structure references instead of C locals. So, they
are always up-to-date.
After list_resize() is called, its size has been updated but the new
cells are filled with NULLs. These needed to be filled before arbitrary
iteration code was called; otherwise, that code could attempt to modify
a list that was in a semi-invalid state. The solution was to change
the ob->size field back to a value reflecting the actual number of valid
cells.
Tim Peters [Sun, 26 Sep 2004 01:24:23 +0000 (01:24 +0000)]
Removed two undocumented unittest support classes, and one undocumented
unittest support function, from the public interface. If they're not
documented, they shouldn't be public.
Tim Peters [Sat, 25 Sep 2004 00:49:53 +0000 (00:49 +0000)]
Beef up the section on testfile(), giving a complete example in
reStructuredText format. Remove words describing the return value of
testmod() and testfile() in the intro sections, since it's never
useful in such simple cases.
Neil Schemenauer [Fri, 24 Sep 2004 19:17:26 +0000 (19:17 +0000)]
Ensure negative offsets cannot be passed to buffer(). When composing
buffers, compute the new buffer size based on the old buffer size.
Fixes SF bug #1034242.