[Python-Dev] Google Summer of Code/core Python projects - RFC
tleeuwenburg at gmail.com
Fri Apr 10 23:26:12 CEST 2009
Well, I think Numpy is of huge importance to a major Python user segment,
the scientific community. I don't know if that makes it 'core', but I
strongly agree that it's important.
Better testing is always useful, and more "core", but IMO less important.
On Sat, Apr 11, 2009 at 6:38 AM, C. Titus Brown <ctb at msu.edu> wrote:
> Hi all,
> this year we have 10-12 GSoC applications that I've put in the "relevant
> to core Python development" category. These projects, if mentors etc
> are found, are *guaranteed* a slot under the PSF GSoC umbrella. As
> backup GSoC admin and general busybody, I've taken on the work of
> coordinating these as a special subgroup within the PSF GSoC, and I
> thought it would be good to mention them to python-dev.
> Note that all of them have been run by a few different committers,
> including Martin, Tarek, Benjamin, and Brett, and they've been obliging
> enough to triage a few of them. Thanks, guys!
> Here's what's left after that triage. Note that except for the four at
> the top, these have all received positive support from *someone* who is
> a committer and I don't think we need to discuss them here -- patches
> etc. can go through normal "python-dev" channels during the course of the
> I am looking for feedback on the first four, though. Can these
> reasonably be considered "core" priorites for Python? Remember, this
> "costs" us something in the sense of preferring these over Python
> subprojects like (random example) Cython, NumPy, PySoy, Tahoe, Gajim,
> Questionable "core":
> 2x "port NumPy to py3k" -- NumPy is a major Python module and porting it
> to py3k fits with Guido's request that "more stuff get ported".
> To be clear, I don't think anyone expects all of NumPy to get
> ported this summer, but these students will work through issues
> associated with porting big chunks o' code to py3k.
> One medium/strong proposal, one medium/weak proposal.
> 2x "improve testing tools for py3k" -- variously focus on improving test
> coverage and testing wrappers.
> One proposes to provide a nice wrapper to make nose and py.test
> capable of running the regrtests, which (with no change to
> regrtest) would let people run tests in parallel, distribute or
> run tests across multiple machines (including Snakebite), tag
> and run subsets of tests with personal and/or public tags, and
> otherwise take advantage of many of the nice features of nose
> and py.test.
> The other proposes to measure & increase the code coverage of
> the py3k tests in both Python and C, integrate across multiple
> machines, and otherwise provide a nice set of integrated reports
> that anyone can generate on their own machines. This proposal,
> in particular, could move smoothly towards the effort to produce
> a "Python-wide" test suite for CPython/IronPython/PyPy/Jython.
> (This wasn't integrated into the proposal because I only found
> out about it after the proposals were due.)
> I personally think that both testing proposals are good, and
> they grew out of conversations I had with Brett, who thinks that
> the general ideas are good. So, err, I'm looking for pushback,
> I guess ;). I can expand on these ideas a bit if people are
> Both proposals are medium at least, and I've personally been
> positively impressed with the student interaction.
> Unquestionably "core" by my criteria above:
> 3to2 tool -- 'nuff said.
> subprocess improvement -- integrating, testing, and proposing some of
> the various subprocess improvements that have passed across this
> list & the bug tracker
> IDLE/Tkinter patch integration & improvement -- deal with ~120 tracker
> issues relating to IDLE and Tkinter.
> roundup VCS integration / build tools to support core development --
> a single student proposed both of these and has received some
> support. See http://slexy.org/view/s2pFgWxufI for details.
> sphinx framework improvement -- support for per-paragraph comments and
> user/developer interface for submitting/committing fixes
> 2x "keyring package" -- see
> The poorer one of these will probably be axed unless Tarek gives it
> strong support.
> C. Titus Brown, ctb at msu.edu
> Python-Dev mailing list
> Python-Dev at python.org
"Don't believe everything you think"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev