< summary index  python-dev archives  pep index >

 This is a summary of traffic on the python-dev mailing list between
 June 21 and July 4 (inclusive) 2001.  It is intended to inform the
 wider Python community of ongoing developments.  To comment, just
 post to python-list@python.org or comp.lang.python in the usual
 way. Give your posting a meaningful subject line, and if it's about a
 PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep
 iteration) All python-dev members are interested in seeing ideas
 discussed by the community, so don't hesitate to take a stance on a
 PEP if you have an opinion.

 This is the eleventh summary written by Michael Hudson.
 Summaries are archived at:

  http://starship.python.net/crew/mwh/summaries/

   Posting distribution (with apologies to mbm)

   Number of articles in summary: 252

    40 |                 [|]                                    
       |                 [|]                                    
       |                 [|]                                    
       |                 [|]                                    
       |                 [|]                                    
    30 |                 [|]                                    
       |                 [|]                                    
       |                 [|]     [|]                 [|]        
       |                 [|]     [|]                 [|] [|]    
       |                 [|]     [|]                 [|] [|]    
    20 |                 [|]     [|]                 [|] [|]    
       |     [|]         [|]     [|]                 [|] [|]    
       |     [|]         [|] [|] [|]                 [|] [|]    
       |     [|]     [|] [|] [|] [|]         [|] [|] [|] [|]    
       |     [|]     [|] [|] [|] [|] [|]     [|] [|] [|] [|] [|]
    10 |     [|]     [|] [|] [|] [|] [|]     [|] [|] [|] [|] [|]
       |     [|]     [|] [|] [|] [|] [|]     [|] [|] [|] [|] [|]
       |     [|] [|] [|] [|] [|] [|] [|]     [|] [|] [|] [|] [|]
       |     [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
       | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
     0 +-004-019-007-016-042-018-028-013-005-015-016-029-027-013
        Thu 21| Sat 23| Mon 25| Wed 27| Fri 29| Sun 01| Tue 03|
            Fri 22  Sun 24  Tue 26  Thu 28  Sat 30  Mon 02  Wed 04

 This will be my last python-dev summary for a while, as I'm going to
 be mostly away from the internet for the summer.  However, Andrew
 Kuchling has agreed to take up writing them again, so there should be
 no interruption in the summaries.


    Support for "wide" Unicode characters

 Paul Prescod posted a draft of PEP 261 'Support for "wide" Unicode
 characters':

  http://mail.python.org/pipermail/python-dev/2001-June/015644.html

 which proposes adding a compile time option to configure unicode
 objects to store "code points" (the integers that the unicode
 specification maps to "characters" -- though that word is dangerously
 overlodaed in the Unicode arena) in 32 bit integers -- they're
 currently stored in 16 bits.
 
 This was (I believe) at least partially inspired by the Unicode
 Consortium assigning code points outside the "Basic Multilingual
 Plane" (i.e. the range of 16 bit integers).

 Noone is convinced that this is the best possible solution (a better
 solution might be to have unicode objects that could either store
 code points in 16 bits or 32 bits as necessary, and this solution
 could have binary compatibility problems), but it seems noone has the
 time to implement a better one (and a better one would probably have
 compatibility problems that couldn't be fixed by a simple recompile):

  http://mail.python.org/pipermail/python-dev/2001-July/015674.html

 (I apologise for any abuse of terminology in the above - I know very
 little about the issues surrounding Unicode).


    Python specializing compiler

 Armin Rigo announced his "Python specializing compiler", psyco:

  http://mail.python.org/pipermail/python-dev/2001-June/015503.html

 It works on the principle that you can compile a faster version of a
 function if you know stuff about the arguments it's likely to be
 called with.  This is one of the more asthetically pleasing of the
 possible ways to speed Python up (it's similar to some tactics used
 by the seemingly defunct self compiler), but it's still a very large
 amount of work away from being useful...


    IPv6

 *Very* preliminary support for IPv6 - the "next generation internet
 protocol" was checked in.  The support thus far doesn't actually
 support IPv6 at all, but rather emulates IPv6's new functions for
 IPv4 addresses, so that code for Python 2.2 will hopefully be
 portable between machines that do and do not support IPv6, whilst
 being able to use IPv6 where it is supported (I hope that makes
 sense).

 Unfortunately the checkin broke the build on some platforms (OSF1,
 Windows) but I believe these problems are now sorted out.

 IPv6 support has been muttered about for years now, so it's nice to
 finally see some movement, even if it is causing some x-platform
 pain.


    PEP 260: simplifying xrange

 Guido posted PEP 260, a proposal to removed some of the less useful
 aspects of the xrange type:

  http://mail.python.org/pipermail/python-dev/2001-June/015590.html

 Support was muted; there's the usual concern on removing "little
 used" features -- what if someone (who maybe doesn't read
 comp.lang.python or these summaries) uses them?


    site-python, site-packages

 Gregor Hoffleit posted a request that <prefix>/lib/site-python be
 considered a standard install target: 

  http://mail.python.org/pipermail/python-dev/2001-July/015715.html

 as the current standard of <prefix>/lib/pythonX.X/site-packages/
 makes life awkward for packagers.

 It's possible Gregor asked the wrong bunch of people; a non-version
 dependent path makes life awkward for those who want to mantain more
 than version of Python, and that includes most of the people on
 pyton-dev.  OTOH, it probably also includes everyone who cares about
 the cross-version portability of the code they write, so it seems
 that movemnet is unlikely here (could be wrong, though).