On Wed, Sep 16, 2009 at 07:49, C. Titus Brown <ctb@msu.edu> wrote:
Michael said: Armin said:
That, and a group of people, dedicated to standard library refactoring. The majority of libraries in the standard library are small and easy to understand, I'm sure they are perfectly suited for students on projects like GSOC or GHOP to work on. They could even be used as some sort of "playground" for new Python developers.
It would be a great project for GHOP *if* we have some experienced developers, like yourself, dedicated to working out what the things that need fixing are.
Testing and doc updates worked reasonably well within GHOP last time, and surprisingly little in the way of "experienced developers" were needed. Faced with the responsibility of coming up with dozens of tasks on short notice, I picked a dozen stdlib modules and said
test this integrate doug hellmann's documentation run through the existing examples and write more
...and voila, it happened and attracted positive notice from the BDFL, which is saying something.
We can also run figleaf or coverage.py across the standard library and see which modules have horrible test coverage.
By far the most important part of that process was not my role in putting the tasks up, but Georg's role in reviewing the patches and committing them in a timely manner. I can't speak for how much time he spent doing that, however, and I certainly don't expect that level of effort from HIM this time; perhaps with Mercurial we can get non-committers to act as first-pass filters to reduce the strain on Georg or whoever steps into his shoes. [0]
Hey, I helped a lot last time (and plan to do so again). As for the Mercurial thing, it might not happen by December, so don't rely on that (although we always have the mirrors so we can instruct the students on how to use those).
Perhaps this time we can focus on py3k stuff with GHOP; that'd be great, and a real community boost, IMO.
One possibility is to simply only care about the test and doc changes for py3k. -Brett