[Python-Dev] Py2.3 Todo List

Guido van Rossum guido@python.org
Tue, 17 Jun 2003 13:31:53 -0400


> Here is my todo list for Py2.3.
> Feel free to comment on whether it is too late to pursue these
> or whether I should continue to work on them for the second beta.
> 
> 1) PEP 42 lists a request to add timeout settings to the higher level
>     net libraries.   Should this still be done?  In Py2.3, sockets offers
>     a setdefaulttimeout() function that provides an indirect way of
>     meeting the same goal.

IMO this is API design that should be done without the time pressure
of a beta.  I'd like you to experiment a bit with the
setdefaulttimeout() approach to see if it is workable though.

> 2) Jack Diedrich is working on two patches for itertools:
>  
>        itertools.window(iterable, n=2) --> (a0, a1), (a1, a2), (a2, a3), ...
> 
>        itertools.roundrobin(*iterables) which loops over the iterables 
>        returning one element from each and then cycles back to the
>        first until all of the iterables are exhausted:
>            itertools.roundrobin('ab', 'cde') --> a, c, b, d, e
> 
> Both functions were discussed on comp.lang.python and have been
> requested by multiple users.  Neither is easily implemented in terms
> of the existing tools.  OTOH, the more tools you add, the harder it
> is to comprehend the toolset as a whole.

itertools is new and yours; if you're comfortable with this, I'm okay
with it.

> 3) difflib now has functions to create a context diff or unified diff.
> A natural next step is to add a patch() function that applies the diff
> and finishes the roundtrip.    It also helps fulfill the original reason for
> adding the context/unified diffs which was to make it easier for
> general python users to either create or apply patches.

Interesting.  My own need is not for patching but for a three-way
merge.  If you could add a direct API for that, it'd be great.
difflib.merge(mine, old, yours) -> new.  With conflict markers a la
diff3 -m -E.

> 4) I've had a long outstanding patch to add methods like isalpha() to
> string objects.  The goal was to make sure that replacements exist
> for all the tools in the string module.  The hold-up has been in
> making UniCode equivalents.  If this is still wanted, I'll finish it up.

I'm +0 on that.

--Guido van Rossum (home page: http://www.python.org/~guido/)