caused by a self._input.readline() call that wasn't checking for the
NeedsMoreData marker.
msg_43.txt contains a message that illustrates the problem, when
email.message_from_*() is called. That interface uses the Parser API, which
splits reads into 8192 byte chunks. It so happens that for the test message,
the 8192 chunk falls inside a message/delivery-status, which is where in the
FeedParser the readline() call was that didn't check for NeedsMoreData.
I also added an assert to unreadline() so it'll be more evident if an attempt
to push back NeedsMoreData ever happens again.
Bump the email package version number.
in a newline, and it's an end boundary, the FeedParser wasn't recognizing it
as such. Tweak the regexp to make the ending linesep optional.
For grins, clear self._partial when closing the BufferedSubFile.
Added a test case.
(http://www.cygwin.com/faq/faq_3.html#SEC41).
Also check whether onerror has actually been called so this test will
fail on assertion instead of on trying to chmod a non-existent file.
button) caused IDLE to fail on restart (no new keyset was created in
config-keys.cfg). Also true for Theme/highlights. Python Bug 1064535.
M configDialog.py
__getitem__() methods: compute only the new spellings needed to satisfy
the given indexing object. This is purely an optimization (it should
have no effect on visible semantics).
regrtest.py: skip rgbimg and imageop as they are not built on 64-bit systems.
_tkinter.c: replace %.8x with %p for printing pointers.
setup.py: add lib64 into the library directories.
showing that doctest's pdb.set_trace() support was dramatically broken.
doctest.py _OutputRedirectingPdb.trace_dispatch(): Return a local trace
function instead of (implicitly) None. Else interaction with pdb was
bizarre, noticing only 'call' events. Amazingly, the existing set_trace()
tests didn't care.
reliably on WinME with FAT32.
* Native speaker rewrite of the comment block.
* Removed unnecessary backslashes from the multi-line function defintions.
In cyclic gc, clear weakrefs to unreachable objects before allowing any
Python code (weakref callbacks or __del__ methods) to run.
This is a critical bugfix, affecting all versions of Python since weakrefs
were introduced. I'll backport to 2.3.
exposed in header files. Fixed a few comments in these headers.
As we might have expected, writing down invariants systematically exposed a
(minor) bug. In this case, function objects have a writeable func_code
attribute, which could be set to code objects with the wrong number of
free variables. Calling the resulting function segfaulted the interpreter.
Added a corresponding test.
of the year, and day of the week. Was not taking into consideration properly
the issue of when %U is used for the week of the year but the year starts on
Monday.
Closes bug #1045381 again.
(Contributed by Facundo Batista.)
Code simplification by eliminating the unnecessary and error-prone
convolutions for the previously weird sign convention in _WorkRep().
Makes the code more understandable, more reliable, and a bit faster.
The underlying bug still exists, but also existed in 2.3.4:
import.c's load_source_module() returns NULL if
PyOS_GetLastModificationTime() returns -1, but
PyOS_GetLastModificationTime() doesn't set any exception when it returns
-1, and neither does load_source_module() when it gets back -1. This
leads to "SystemError: NULL result without error in PyObject_Call"
on an import that fails in this way.
- Added a chunk of plist data as generated by Cocoa's NSDictionary and
verify we output the same (including formatting)
- Changed the "literal" plist code to match the raw test data
Peepholer could be fooled into misidentifying a tuple_of_constants.
Added code to count consecutive occurrences of LOAD_CONST.
Use the count to weed out the misidentified cases.
Added a unittest.
the indentation of a comment block to be ignored when reformatting the
block, leading to overly long reformatted lines (too wide by an amount
equal to the indentation width). Looks like a typo in the original
patch, a 1-character repair.
Turns out the mysterious "expected output" file contained exactly N dots,
because test_poll() has a loop that *usually* went around N times,
printing one dot on each loop trip. But there's no guarantee of that,
because the exact value of N depended on the vagaries of scheduling
time.sleep()s across two different processes. So stopped printing dots,
and got rid of the expected output file. Add a loop counter instead,
and verify that the loop goes around at least a couple of times. Also
cut the minimum time needed for this test from 4 seconds to 1.
tester that a DOS box is expected to flash. Slash the sleep from 2
seconds to a quarter second (why would we want to wait 2 seconds just
to stare at a DOS box?).
what this is trying to do. If it's necessary for it to create > 1000
processes, it should be controlled by a new resource and not run by
default on Windows.
display a test's docstring as "the name" of the test. So changed most
test docstrings to comments, and removed the clearly useless ones. Now
unittest reports the actual names of the test methods.
Bug fixes:
* Use fresh copy of globals/locals so the script being debugged can't access
the pdb namespace (e.g.: p line_prefix will no longer work).
* Remove pdb.py's path from sys.path. Having it in there is normally not a
problem, but it could prove irritating when messing with PYTHONPATH or
invoking pdb via /usr/bin/pdf.
* You can now set a breakpoint on the script being debugged, even if the script
doesn't end with a '.py' extension. Also, setting breakpoints with absolute
paths now works reliably.
Enhancements:
* Go directly to the first line of the script.
* Enter post-mortem debugging if the script being debugged doesn't catch an
exception.
* Restart the script being debugged and preserve debugger state when the script
being debugged exits.
Cleanup:
* Moved the __main__ method into a main() function.
* Kill the (undocumented, not in __all__) mainmodule/mainpyfile globals, add a
mainpyfile attribute to pdb.
Thanks Ilya Sandler for the patch!
popen2.popen2/3/4 functions can be a sequence. All texts are a variation on the
following:
On \UNIX, \var{cmd} may be a sequence, in which case arguments will be passed
directly to the program without shell intervention (as with
\function{os.spawnv()}). If \var{cmd} is a string it will be passed to the shell
(as with \function{os.system()}).
capturing_preamble but we found a StartBoundaryNotFoundDefect, we need to
consume all lines from the current position to the EOF, which we'll set as the
epilogue of the current message. If we're not at EOF when we return from
here, the outer message's capturing_preamble assertion will fail.
calling .lower() on it. This fixes the problem described in SF patch # 866982
where in the tr_TR.ISO-8859-9 locale, 'I'.lower() isn't 'i'. unicodes are
locale insensitive.
The shutils.rmtree() implementation uses an excessive amount of memory when
deleting large directory hierarchies. Before actually deleting any files, it
builds up a list of (function, filename) tuples for all the files that it is
going to remove.
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.
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())
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.)