cPickle cannot be imported. This was necessary because my last mass
checkin broke cPickle and I don't feel like debugging it right now;
but it seems a good idea in general not to require cPickle when
pickle.py is also there. A few unrelated fixes for issues while
debigging various test failures.
setup.py: disable building of cPickle until I've fixed it
Objects/...
genobject.c: disallow raising string exceptions
Lib/...
Cookie.py: fix doctest not to fail if cPickle is missing
ctypes/macholib/dyld.py: fix relative imports
sqlite3/__init__.py: fix relative import
xml/dom/__init__.py: fix relative import
Lib/test/...
regrtest.py: reduce list of skipped items on darwin
test_generators.py: don't test string exceptions; test throw() errors
test_traceback.py: don't test string exceptions
pickletester.py: don't fail if cPickle is missing
test_datetime.py: don't fail if cPickle is missing
test_descr.py: don't fail if cPickle is missing (still some other failures)
test_exceptions.py: don't fail if cPickle is missing
test_re.py: don't fail if cPickle is missing
test_array.py: use pickle, not cPickle
test_bool.py: don't fail if cPickle is missing
test_deque.py: use pickle, not cPickle
test_logging.py: use pickle, not cPickle
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())
(Code contributed by Jiwon Seo.)
The documentation portion of the patch is being re-worked and will be
checked-in soon. Likewise, PEP 289 will be updated to reflect Guido's
rationale for the design decisions on binding behavior (as described in
in his patch comments and in discussions on python-dev).
The test file, test_genexps.py, is written in doctest format and is
meant to exercise all aspects of the the patch. Further additions are
welcome from everyone. Please stress test this new feature as much as
possible before the alpha release.
same method that implements __setitem__ also implements __delitem__.
Also, there were several good use cases (removing items from a queue
and implementing Forth style stack ops).
__getitem__() and __setitem__().
Simplifies the API, reduces the code size, adds flexibility, and makes
deques work with bisect.bisect(), random.shuffle(), and random.sample().
* Add doctests for the examples in the library reference.
* Add two methods, left() and right(), modeled after deques in C++ STL.
* Apply the new method to asynchat.py.
* Add comparison operators to make deques more substitutable for lists.
* Replace the LookupErrors with IndexErrors to more closely match lists.
