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 <lists@cheimes.de> 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.

>  * 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/)
_______________________________________________
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