[Py-howto-checkins] CVS: pyhowto python-22.tex,1.16,1.17

[A.M. K. <aku...@us...>]

Update of /cvsroot/py-howto/pyhowto
In directory usw-pr-cvs1:/tmp/cvs-serv22040

Modified Files:
	python-22.tex 
Log Message:
More Unicode corrections from MAL to match a post-2.2a1 change
Mention additional new imaplib.py features

(Don't expect to see an updated version of the Web page until around the 28th
   of July.  Vacation time!)


Index: python-22.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -r1.16 -r1.17
*** python-22.tex	2001/07/19 14:59:53	1.16
--- python-22.tex	2001/07/20 18:34:34	1.17
***************
*** 340,370 ****
  
  Python's Unicode support has been enhanced a bit in 2.2.  Unicode
! strings are usually stored as UTF-16, as 16-bit unsigned integers.
  Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned
  integers, as its internal encoding by supplying
  \longprogramopt{enable-unicode=ucs4} to the configure script.  When
  built to use UCS-4 (a ``wide Python''), the interpreter can natively
! handle Unicode characters from U+000000 to U+110000.  The range of
! legal values for the \function{unichr()} function has been expanded;
! it used to only accept values up to 65535, but in 2.2 will accept
! values from 0 to 0x110000.  Using a ``narrow Python'', an interpreter
! compiled to use UTF-16, values greater than 65535 will result in
! \function{unichr()} returning a string of length 2:
  
- \begin{verbatim}
- >>> s = unichr(65536)
- >>> s
- u'\ud800\udc00'
- >>> len(s)
- 2
- \end{verbatim}
- 
- This possibly-confusing behaviour, breaking the intuitive invariant
- that \function{chr()} and\function{unichr()} always return strings of
- length 1, may be changed later in 2.2 depending on public reaction.
- 
  All this is the province of the still-unimplemented PEP 261, ``Support
  for `wide' Unicode characters''; consult it for further details, and
! please offer comments and suggestions on the proposal it describes.
  
  Another change is much simpler to explain. Since their introduction,
--- 340,359 ----
  
  Python's Unicode support has been enhanced a bit in 2.2.  Unicode
! strings are usually stored as UCS-2, as 16-bit unsigned integers.
  Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned
  integers, as its internal encoding by supplying
  \longprogramopt{enable-unicode=ucs4} to the configure script.  When
  built to use UCS-4 (a ``wide Python''), the interpreter can natively
! handle Unicode characters from U+000000 to U+110000, so the range of
! legal values for the \function{unichr()} function is expanded
! accordingly.  Using an interpreter compiled to use UCS-2 (a ``narrow
! Python''), values greater than 65535 will still cause
! \function{unichr()} to raise a \exception{ValueError} exception.
  
  All this is the province of the still-unimplemented PEP 261, ``Support
  for `wide' Unicode characters''; consult it for further details, and
! please offer comments on the PEP and on your experiences with the
! 2.2 alpha releases.
! % XXX update previous line once 2.2 reaches beta.
  
  Another change is much simpler to explain. Since their introduction,
***************
*** 577,583 ****
    contributed by Martin von L\"owis.)
  
!   \item The \module{imaplib} module now has support for the IMAP
!   NAMESPACE extension defined in \rfc{2342}.  (Contributed by Michel
!   Pelletier.)
  
    \item The \module{rfc822} module's parsing of email addresses is
--- 566,573 ----
    contributed by Martin von L\"owis.)
  
!   \item The \module{imaplib} module, maintained by Piers Lauder, has
!   support for several new extensions: the NAMESPACE extension defined
!   in \rfc{2342}, SORT, GETACL and SETACL.  (Contributed by Anthony
!   Baxter and Michel Pelletier.)
  
    \item The \module{rfc822} module's parsing of email addresses is