[Python-3000] Release Countdown

[Jim Jewett]

On 8/31/07, Guido van Rossum <guido at python.org> wrote:

> > >>>> For me on OS X, I'm still getting a failure in test_plistlib and an

> No worry, I cracked it, just in time before the release.

Seeing the recent changes to plistlib does make me think that bytes is
more awkward than it should be.  The changes I would suggest:

(1)  Allow bytes methods to take a literal string (which will
obviously be in the source file's encoding).

Needing to change

    for line in data.asBase64(maxlinelength).split("\n"):
to
    for line in data.asBase64(maxlinelength).split(b"\n"):

(even when I know the "integers" represent ASCII letters) is exactly
the sort of type-checking that annoys me in Java.

http://svn.python.org/view/python/branches/py3k/Lib/plat-mac/plistlib.py?rev=57844&r1=57744&r2=57844


(2)  There really ought to be an immutable bytes type, and the literal
(or at least a literal, if capitalization matters) ought to be the
immutable.

PLISTHEADER = b"""\
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD
PLIST 1.0//EN" "http://www.apple.com/DTDs/
PropertyList-1.0.dtd">
"""

If the value of PLISTHEADER does change during the run, it will almost
certainly be a bug.  I could code defensively by only ever passing
copies, but that seems wasteful, and it could hide other bugs.  If
something does try to modify (not replace, modify) it, then there was
probably a typo or API misunderstanding; I *want* an exception.

http://svn.python.org/view/python/branches/py3k/Lib/plat-mac/plistlib.py?rev=57563&r1=57305&r2=57563

-jJ