Barry Warsaw [Mon, 14 Oct 2002 18:15:35 +0000 (18:15 +0000)]
I'd forgotten that tcsh was the default for 10.1, but SF's 10.1 system
uses bash and so does my 10.2 system. "limit stacksize 2048" is the
right invocation for tcsh/csh.
Barry Warsaw [Mon, 14 Oct 2002 18:04:39 +0000 (18:04 +0000)]
There was a typo in the MacOSX section regarding the stacksize issue.
There's no limit command near as I can tell. Should be the bash
builtin ulimit command.
Barry Warsaw [Mon, 14 Oct 2002 16:52:41 +0000 (16:52 +0000)]
append(): Fixing the test for convertability after consultation with
Ben. If s is a byte string, make sure it can be converted to unicode
with the input codec, and from unicode with the output codec, or raise
a UnicodeError exception early. Skip this test (and the unicode->byte
string conversion) when the charset is our faux 8bit raw charset.
Barry Warsaw [Mon, 14 Oct 2002 15:13:17 +0000 (15:13 +0000)]
__init__(): Fix an invariant, that the charset item in a chunk tuple
must be a Charset instance, not a string. The bug here was that
self._charset wasn't being converted to a Charset instance so later
.append() calls which used the default charset would break.
_split(): If the charset of the chunk is '8bit', return the chunk
unchanged. We can't safely split it, so this is the avenue of least
harm.
Barry Warsaw [Sun, 13 Oct 2002 04:06:28 +0000 (04:06 +0000)]
_encode_chunks(), encode(): Don't modify self._chunks. As Ben says:
Also, it fixes a really egregious error in Header.encode() (really
in Header._encode_chunks()) that could cause a header to grow and
grow each time encode() was called if output_codec was different
from input_codec.
Guido van Rossum [Fri, 11 Oct 2002 20:37:24 +0000 (20:37 +0000)]
PyObject_Init[Var] is almost always called from the PyObject_NEW[_VAR]
macros. The 'op' argument is then the result from PyObject_MALLOC,
and that can of course be NULL. In that case, PyObject_Init[Var]
would raise a SystemError with "NULL object passed to
PyObject_Init[Var]". But there's nothing the caller of the macro can
do about this. So PyObject_Init[Var] should call just PyErr_NoMemory.
Tim Peters [Fri, 11 Oct 2002 18:25:52 +0000 (18:25 +0000)]
The MS resource compiler simply cannot be convinced to do arithmetic
correctly. So field3.py is a Python program that can. This injects
another manual step into the Python release process for Windows; so
it goes.
Guido van Rossum [Fri, 11 Oct 2002 00:43:48 +0000 (00:43 +0000)]
Fix a nasty endcase reported by Armin Rigo in SF bug 618623:
'%2147483647d' % -123 segfaults. This was because an integer overflow
in a comparison caused the string resize to be skipped. After fixing
the overflow, this could call _PyString_Resize() with a negative size,
so I (1) test for that and raise MemoryError instead; (2) also added a
test for negative newsize to _PyString_Resize(), raising SystemError
as for all bad arguments.
An identical bug existed in unicodeobject.c, of course.
Barry Warsaw [Thu, 10 Oct 2002 15:11:20 +0000 (15:11 +0000)]
__init__(): RFC 2046 $4.1.2 says charsets are not case sensitive.
Coerce the argument to lower case. Also, since body encodings can't
be SHORTEST, default the CHARSETS failobj's second item to BASE64.
Guido van Rossum [Thu, 10 Oct 2002 15:04:04 +0000 (15:04 +0000)]
Add .PHONY targets, to declare targets that aren't real files.
Immediate benefit: when you use "make -t" to avoid a global recompile
after a trivial header file touchup, Make will no longer create files
named all, oldsharedmods, and sharedmods.
(Not sure if I tracked down all such targets. Not sure if I care.)
Skip Montanaro [Wed, 9 Oct 2002 21:37:18 +0000 (21:37 +0000)]
MacOSX linker doesn't understand -R flag at all, no matter how you feed it
the flag. Punt and return a -L flag instead (returning "" gums up the
command to be forked).
GNU readline() mistakenly sets the LC_CTYPE locale.
This is evil. Only the user or the app's main() should do this!
We must save and restore the locale around the rl_initialize() call.
The string formatting code has a test to switch to Unicode when %s
sees a Unicode argument. Unfortunately this test was also executed
for %r, because %s and %r share almost all of their code. This meant
that, if u is a unicode object while repr(u) is an 8-bit string
containing ASCII characters, '%r' % u is a *unicode* string containing
only ASCII characters!
Fixed by executing the test only for %s.
Also fixed an error message -- %s argument has non-string str()
doesn't make sense for %r, so the error message now differentiates
between %s and %r.
Add special consideration for rlcompleter. As a side effect of
initializing GNU readline, setlocale(LC_CTYPE, "") is called, which
changes the <ctype.h> macros to use the "default" locale (which isn't
the *initial* locale -- the initial locale is the "C" locale in which
only ASCII characters are printable). When the default locale is e.g.
Latin-1, the repr() of string objects can include 8-bit characters
with the high bit set; I believe this is due to the recent
PRINT_MULTIBYTE_STRING changes to stringobject.c. This in turn screws
up test_pyexpat and test_rotor, which depend on the repr() of 8-bit
strings with high bit characters.
The solution (for now) is to force the LC_CTYPE locale to "C" after
importing rlcompleter. This is the locale required by the test suite
anyway.
Tim Peters [Wed, 9 Oct 2002 07:56:04 +0000 (07:56 +0000)]
Don't try to access sys.getwindowsversion unless it exists (ntpath is
imported on systems other than Windows, and in particular is imported
by test___all__; the compile farm reported that all Linux tests failed
due to this; isn't anyone in PythonDevLand running CVS on Linux?!).
Tim Peters [Wed, 9 Oct 2002 01:07:11 +0000 (01:07 +0000)]
Logic for determining whether skipping test_pep277 is expected: whether
ths "should be" skipped depends on os.path.supports_unicode_filenames,
not really on the platform. Fiddled the expected-skip constructor
appropriately.
Tim Peters [Tue, 8 Oct 2002 21:01:07 +0000 (21:01 +0000)]
The
list(xrange(sys.maxint / 4))
test. Changed 4 to 2.
The belief is that this test intended to trigger a bit of code in
listobject.c's NRESIZE macro that's looking for arithmetic overflow. As
written, it doesn't achieve that, though, and leaves it up to the platform
realloc() as to whether it wants to allocate 2 gigabytes. Some platforms
say "sure!", although they don't appear to mean it, and disaster ensues.
Changing 4 to 2 (just barely) manages to trigger the arithmetic overflow
test instead, leaving the platform realloc() out of it.
Mark Hammond [Tue, 8 Oct 2002 02:44:31 +0000 (02:44 +0000)]
Add os.path.supports_unicode_filenames for all platforms,
sys.getwindowsversion() on Windows (new enahanced Tim-proof <wink>
version), and fix test_pep277.py in a few minor ways.
Including doc and NEWS entries.
Barry Warsaw [Mon, 7 Oct 2002 17:27:55 +0000 (17:27 +0000)]
openfile(): Go back to opening the files in text mode. This undoes
the change in revision 1.11 (test_email.py) in response to SF bug
#609988. We now think that was the wrong fix and that WinZip was the
real culprit there.
Barry Warsaw [Mon, 7 Oct 2002 17:27:35 +0000 (17:27 +0000)]
_parsebody(): Use get_content_type() instead of the deprecated
get_type(). Also, one of the regular expressions is constant so might
as well make it a module global. And, when splitting up digests,
handle lineseps that are longer than 1 character in length
(e.g. \r\n).
Fred Drake [Mon, 7 Oct 2002 16:28:38 +0000 (16:28 +0000)]
Modified presentation of the grammar for calls to be easier to read
for both HTML and typeset renderings. Corresponds to revision
1.53.4.8 on the r22-maint branch.
Add test_pep277 to the expected skips on Linux. (This test seems to
be skipped everywhere except on Windows NT and descendants, but I'm
only going to add it to the skip list for the platform I can test.)
Tim Peters [Sat, 5 Oct 2002 17:54:56 +0000 (17:54 +0000)]
This test fails on Win98, which is fine, but when it failed it left
a junk directory behind that caused 4 other tests to fail later. Now
it cleans up after itself, and the 4 bogus later failures don't happen.