Jeremy Hylton [Sun, 29 Jun 2003 17:55:05 +0000 (17:55 +0000)]
Fix sf bug 666219: assertion error in httplib.
The obvious way for this assertion to fail is if the LineAndFileWrapper constructor is called when an empty line. Raise a BadStatusError before the call.
The test seems to expect that if time.daylight is true, then the
is_dst field of the tm structure will be 1 too. But this isn't
the case, since daylight is true if the timezone does DST, *not*
if DST is in effect.
Tim Peters [Sun, 29 Jun 2003 05:30:48 +0000 (05:30 +0000)]
Some nifty doctest extensions from Jim Fulton, currently used in Zope3.
I won't have time to write real docs, but spent a lot of time adding
comments to his code and fleshing out the exported functions' docstrings.
There's probably opportunity to consolidate how docstrings get extracted
too, and the new code for that is probably better than the old code for
that (which strained mightily to recover from 2.2's new class/type
gimmicks).
Guido van Rossum [Sat, 28 Jun 2003 21:53:52 +0000 (21:53 +0000)]
Add PyThreadState_SetAsyncExc(long, PyObject *).
A new API (only accessible from C) to interrupt a thread by sending it
an exception. This is not always effective, but might help some people.
Requested by Just van Rossum and Alex Martelli. It is intentional
that you have to write your own C extension to call it from Python.
Jim Fulton [Sat, 28 Jun 2003 11:53:29 +0000 (11:53 +0000)]
Changed the assignment of PyType_GenericNew to tp_new slot. Now do
this in module initialization before calling PyType_Ready. (Sorry
Tim.) This is necessary to compile on cygwin. AFAIK, we support
cygwin. If so, then we need to write extentions this way.
Jim Fulton [Sat, 28 Jun 2003 11:53:12 +0000 (11:53 +0000)]
Changed the assignment of PyType_GenericNew to tp_new slot. Now do
this in module initialization before calling PyType_Ready. (Sorry
Tim.) This is necessary to compile on cygwin. AFAIK, we support
cygwin. If so, then we need to write extentions this way.
Fixed bug in implementation of tp_init function. It should be an int
function, not a PyObject *.
SF patch #761519: Fixes for bugs 760703 and 757821
SF bug #760703: SocketHandler and LogRecord don't work well together
SF bug #757821: logging module docs
Applied Vinay Sajip's patch with a few minor fixups and a NEWS item.
Patched __init__.py - added new function
makeLogRecord (for bug report 760703).
Patched handlers.py - updated some docstrings and
deleted some old commented-out code.
Patched test_logging.py to make use of makeLogRecord.
Patched liblogging.tex to fill documentation gaps (both
760703 and bug 757821).
Tim Peters [Fri, 27 Jun 2003 20:48:05 +0000 (20:48 +0000)]
A hack to ease compatibility with pre-2.3 Pythons: by default, doctest
now accepts "True" when a test expects "1", and similarly for "False"
versus "0". This is un-doctest-like, but on balance makes it much
more pleasant to write doctests that pass under 2.2 and 2.3. I expect
it to go away again, when 2.2 is forgotten. In the meantime, there's
a new doctest module constant that can be passed to a new optional
argument, if you want to turn this behavior off.
Note that this substitution is very simple-minded: the expected and
actual outputs have to consist of single tokens. No attempt is made,
e.g., to accept [True, False] when a test expects [1, 0]. This is a
simple hack for simple tests, and I intend to keep it that way.
Fred Drake [Fri, 27 Jun 2003 18:26:01 +0000 (18:26 +0000)]
Don't assume the name of the table of contents will be contents.html;
that won't be right when mkhowto is called with --numeric (as it is
for the Python Tutorial). Save the actual name we use when we build
the table of contents, then use that in the page head metadata. The
node2label.pl script will munge this properly when --numeric isn't
given, so this works in both cases.
Closes SF bug #761830.
Jeremy Hylton [Fri, 27 Jun 2003 16:13:17 +0000 (16:13 +0000)]
Fix several bugs in handling of exceptions with trace function enabled.
If the callback raised an exception but did not set curexc_traceback,
the trace function was called with PyTrace_RETURN. That is, the trace
function was called with an exception set. The main loop detected the
exception when the trace function returned; it complained and disabled
tracing.
Fix the logic error so that PyTrace_RETURN only occurs if the callback
returned normally.
The trace function must be called for exceptions, too. So we had
to add new functionality to call with PyTrace_EXCEPTION. (Leads to a
rather ugly ifdef / else block that contains only a '}'.)
Reverse the logic and name of NOFIX_TRACE to FIX_TRACE.
SF bug #761337: datetime.strftime fails on trivial format string
The interning of short strings violates the refcnt==1 assumption for
_PyString_Resize().
A simple fix is to boost the initial value of "totalnew" by 1.
Combined with an NULL argument to PyString_FromStringAndSize(),
this assures that resulting format string is not interned.
This will remain true even if the implementation of
PyString_FromStringAndSize() changes because only the uninitialized
strings that can be interned are those of zero length.
Jeremy Hylton [Thu, 26 Jun 2003 23:20:20 +0000 (23:20 +0000)]
Don't call constructor() from pickle().
The constructor() call only made sense when it registered the
constructor as safe for unpickling. We should probably remove the
module-global function, but need to worry about backwards
compatibility.
Greg Stein [Tue, 24 Jun 2003 06:35:19 +0000 (06:35 +0000)]
Deal with a couple XXX comments which asked questions.
In response to "shouldn't the client close the file?", the answer is
"no". The original design behind HTTPConnection is that the client did
not have to worry about it. The response would close itself when you
read the last of the data from it. This closing also dealt with
allowing the connection to perform another request/response (if it was
a persistent connection).
However... the auto-close behavior broke compatibility with the
classic httplib.HTTP class' behavior when a zero-length response body
was present. In that situation, the HTTPResponse object was
auto-closing it since there was no data present, and for an HTTP/1.0
connection-close socket (or an HTTP/0.9 request) connection, that also
ended up closing the socket. When an httplib.HTTP user went to read
the socket... boom. A patch to correct the auto-close (for compat with
old httplib users) was added in rev 1.22.
But for non-zero-length *chunked* bodies, we should keep the
auto-close behavior. The library user is not reading the socket (they
can't cuz of the chunked response we just got done handling), so they
should be immune to the response closing the socket. In fact, I would
like to see (one day) the auto-close restored, and the HTTP subclass
would simply have a flag to disable that behavior (for back-compat
purposes).