[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/)