On Sun, Mar 16, 2008 at 10:23 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Moving this to a new subject to keep the discussion of tasks and the > discussion of task tracking tools separate. > > On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]> > wrote: > > I did a quick brainstorming with me, myself and I. I came up with a > list > > of (IMHO) important tasks. > > > > * Stabilize the C API of Python 3.0. I like to rename several prefixes > > to reduce the confusing: PyBytes -> PyByteArray, > > +1 (also +1 to backporting this to 2.6) > > > PyString -> PyBytes ... > > -1. This will make merging code from 2.6 harder, and causes more work > for porting C extensions. There was a thread about this a few weeks ago: http://mail.python.org/pipermail/python-dev/2008-March/077339.html We can still do the renaming, but alias PyString to PyBytes. > > > > * Backport the new buffer protocol to 2.6. I spoke to Travis yesterday > > and he said he is trying to get it done during the PyCon sprint. Maybe > > somebody can assist him? > > Does he need assistance? > > > When the new buffer protocol is available in 2.6 we can start back > > porting bytesarray and the new IO framework. > > Are these really so closely tied that they have to wait before they > can be backported? > > > * Replace Windows API calls with wide versions to support unicode for > > file names, environment etc. > > +1. This should be broken into separate tasks for each API. > > > * Get the stdlib reorg done > > +1. But again, I think this is many small tasks. > > > and add the fixers to 2to3 > > +1. I think quite a few changes have not had a fixer added. Again, I > think we should maintain a specific list of needed fixers; fixers can > easily be developed independently. > > > * Speed up 2to3. I suggested a GSoC task to improve and speed up 2to3 > > but it may be too late when we plan to ship out 3.0 in August. > > While I know that some people are expecting to use a development model > that invokes 2to3 very frequently, I think this is at best a > nice-to-have. (I also don't see how it could be done, but maybe I'm > blind for the obvious, as the original author.) > > I have some other tasks to add: > > - getargs.c (Georg posted about this; his post actually inspired my post.) > > - Tweak structseq to be more like namedtuple. Maybe they could have a > common ABC. I also think we should get rid of the concept of "hidden" > fields (that are accessible by name but not through the tuple API). > > - Devise a way to handle str instances pickled in 2.6 and unpickled in > 3.0, and also bytes instances pickled in 3.0 and unpickled in 2.6. > > - Someone should go over > https://spreadsheets.google.com/ccc?key=pCKY4oaXnT81FrGo3ShGHGg > and extract more tasks. > > -- > --Guido van Rossum (home page: > http://www.python.org/~guido/<http://www.python.org/%7Eguido/> > ) > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
