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.
-T On Sat, Apr 11, 2009 at 6:38 AM, C. Titus Brown <c...@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 > summer. > > 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, > etc. > > --- > > 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. > > Comments/thoughts? > > 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 > interested. > > Both proposals are medium at least, and I've personally been > positively impressed with the student interaction. > > Comments/thoughts? > > --- > > 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 > > http://tarekziade.wordpress.com/2009/03/27/pycon-hallway-session-1-a-keyring-library-for-python/ > . > The poorer one of these will probably be axed unless Tarek gives it > strong support. > > -- > > --titus > -- > C. Titus Brown, c...@msu.edu > _______________________________________________ > 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/tleeuwenburg%40gmail.com > -- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think"
_______________________________________________ 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/archive%40mail-archive.com