Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
C. Titus Brown wrote: > [...] > I have had a hard time getting a good sense of what core code is well > tested and what is not well tested, across various platforms. While > Walter's C/Python integrated code coverage site is nice, it would be > even nicer to have a way to generate all that information within any > particular checkout on a real-time basis. This might have to be done incrementally. Creating the output for http://coverage.livinglogic.de/ takes about 90 minutes. This breaks done like this: Downloading: 2sec Unpacking: 3sec Configuring: 30sec Compiling: 1min Running the test suite: 1hour Reading coverage files: 8sec Generating HTML files: 30min > Doing so in the context of > Snakebite would be icing... and I think it's worth supporting in core, > especially if it can be done without any changes *to* core. The only thing we'd probably need in core is a way to configure Python to run with code coverage. The coverage script does this by patching the makefile. Running the code coverage script on Snakebite would be awesome. The script is available from here: http://pypi.python.org/pypi/pycoco > -> Another small nit is that they should address Python 2.x, too. > > I asked that they focus on EITHER 2.x or 3.x, since "too broad" is an > equally valid criticism. Certainly 3.x is the future so I though > focusing on increasing code coverage, and especially C code coverage, > could best be applied to 3.x. Servus, Walter ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
On Fri, Apr 10, 2009 at 4:38 PM, C. Titus Brown wrote: > Unquestionably "core" by my criteria above: > > 3to2 tool -- 'nuff said. I worked on the 3to2 tool during the sprint last week at PyCon. I can chip in for GSoC in the event it does get picked up. -Ron PS - I'm out of town next week for a family vacation, returning online the week of 20 Apr. ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
> The student will also provide some plugins for a maximum number of > existing keyring systems. > Some of these plugins might be included in Distutils, and some of them > in a third-party package. This is slightly better, but see my previous message (that is feature creep in distutils, and likely, people will start using the distutils implementation as if it were official API). Also, if you want it pluggable, you likely come up with *another* ad-hoc plugin system. Regards, Martin ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
Tarek Ziadé wrote: >> -> I'm also skeptical that this is a good SoC project in the first place. > > What is a good SoC project from your point of view ? As a core project - tricky. Implement some long-standing complex feature request, or fix a pile of outstanding bug reports for a module (like the IDLE proposal). I liked the outcome of last year's "memory profiling" project: the student added sys.getsizeof (with much of mentoring on my side), and created a profiling library and application that wasn't added to the core. The latter part is a biased outcome (as I originally hoped to get something that becomes part of the standard library - but gave up on this quickly as way too much design went into that library); the useful core contribution (getsizeof) took considerable amount of learning, and still had a few tricky design issues to resolve. In short, there must be a realistic chance that the code gets actually used. Chances for a from-scratch library to be used are nearly zero, so from-scratch libraries are not good projects. In case you wonder why I give it nearly zero chance: I keep telling long-term contributors that libraries have to be field-tested before being considered for inclusion, and sometimes, even field-testing is not enough (think setuptools). If SoC students get to short-cut the process, that would send a wrong message to contributors and users. > Part of the work will consist of working on a PEP-like document, and on > building APIs for various keychains and see if we can have an unified one. > I doubt the PEP-like document can be written before writing prototypes APIs > for various keychains has been done. That's certainly true. That's why I think it is a much larger project: - write different wrappers - come up with a unifying API - field-test it for actual applications - write a PEP This could easily take a few years to get right (unless the actual authors of the various keychain implementations get together, define a common C API, which then a Python module just needs to wrap). > At the end of the summer, if we come up with a nice unified API, I'd > like to include > it to Distutils for the "register" command, and maybe write a PEP to have it > as part of the standard library because it makes sense to have this kind > of feature imho. I completely agree that this is a useful functionality to have, and I also agree it *eventually* belongs into the standard library. I just don't like the idea of bypassing the proper process by making it part of distutils. This model (I need it, so I add it) made both distutils and setuptools so unmaintainable. Regards, Martin ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
> I'm using "core projects" as a shorthand for projects that directly > address the core development environment, the stdlib, and priorities of > committers on python-dev. Tarek is a committer, and it sounded like > you, Jim, and Georg were all interested in this project, too -- that > pushes it well into "core" territory IMO. I understand why Tarek wants it, and I can sympathise with that: to protect PyPI passwords better (they are currently stored on disk in plain). Putting it into distutils might not make it "official API", but then, I think it ought to be official API, since PyPI would be just one (minor) application of it; Python also features a netrc module (which probably nobody uses). So I think it would be good to have a discussion upfront whether this should be added to the library after the summer is over (assuming it actually works by then). Decision to accept it or not as a SoC project is independent, but if accepted, the student should well understand the outcome of this discussion. Regards, Martin ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
Ok what about this then: I am changing the scope a little bit, and I think the students will be fine with this change since it's the same work. "The project will consist of creating a plugin system into Distutils to be able to store and retrieve the username/password used by some commands, without having to store it in *clear text* in the .pypirc file anymore. The student will also provide some plugins for a maximum number of existing keyring systems. Some of these plugins might be included in Distutils, and some of them in a third-party package. " Regards Tarek ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
> -> I'm also skeptical that this is a good SoC project in the first place. What is a good SoC project from your point of view ? > -> Coming up with a wrapper for, say, Apple Keychain, could be a good > -> project. Coming up with a unifying API for all keychains is out of > -> scope, IMO; various past attempts at unifying APIs have demonstrated > -> that creating them is difficult, and might require writing a PEP > -> (whose acceptance then might not happen within a summer). > > Well, that's a more unassailable argument and one I agree with ;). For this case, the student work is not a "dumb" work consisting of writing code on an already-thaught PEP... Part of the work will consist of working on a PEP-like document, and on building APIs for various keychains and see if we can have an unified one. I doubt the PEP-like document can be written before writing prototypes APIs for various keychains has been done. At the end of the summer, if we come up with a nice unified API, I'd like to include it to Distutils for the "register" command, and maybe write a PEP to have it as part of the standard library because it makes sense to have this kind of feature imho. Tarek ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
On Sat, Apr 11, 2009 at 08:13:35AM +0200, "Martin v. L?wis" wrote: -> > 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. -> -> I don't think these are good "core" projects. Even if the students come -> up with a complete solution, it shouldn't be integrated with the -> standard library right away. Instead, it should have a life outside the -> standard library, and be considered for inclusion only if the user -> community wants it. Tarek has said he can put it into distutils on a trial basis, although I'm sure that'll depend on what the student comes up with. I'm using "core projects" as a shorthand for projects that directly address the core development environment, the stdlib, and priorities of committers on python-dev. Tarek is a committer, and it sounded like you, Jim, and Georg were all interested in this project, too -- that pushes it well into "core" territory IMO. -> I'm also skeptical that this is a good SoC project in the first place. -> Coming up with a wrapper for, say, Apple Keychain, could be a good -> project. Coming up with a unifying API for all keychains is out of -> scope, IMO; various past attempts at unifying APIs have demonstrated -> that creating them is difficult, and might require writing a PEP -> (whose acceptance then might not happen within a summer). Well, that's a more unassailable argument and one I agree with ;). cheers, --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/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
On Sat, Apr 11, 2009 at 12:21:18PM +0200, Mario wrote: -> > He says vague things about patches too, but I'm not sure what. If he -> > wanted to make that into a 'patchbot' that just applied every patch in -> > isolation and ran 'make && make test' and posted results in the -> > tracker I'd be a happy camper. -> > -> Jack, how about you write that idea down on the wiki page mentioned in the -> proposal, along with the use case? Following that, I'll see if I can do -> anything about it to make it a reality. We had a GSoC student two years back who worked on something like this; his name is Michal Kwiatkowski. He probably has the code working somewhere. It's a nontrivial problem if you want to do it properly with VMs etc. cheers, --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/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
> > > He says vague things about patches too, but I'm not sure what. If he > wanted to make that into a 'patchbot' that just applied every patch in > isolation and ran 'make && make test' and posted results in the > tracker I'd be a happy camper. > > Jack, how about you write that idea down on the wiki page mentioned in the proposal, along with the use case? Following that, I'll see if I can do anything about it to make it a reality. Cheers, M. ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
> 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. I don't think these are good "core" projects. Even if the students come up with a complete solution, it shouldn't be integrated with the standard library right away. Instead, it should have a life outside the standard library, and be considered for inclusion only if the user community wants it. I'm also skeptical that this is a good SoC project in the first place. Coming up with a wrapper for, say, Apple Keychain, could be a good project. Coming up with a unifying API for all keychains is out of scope, IMO; various past attempts at unifying APIs have demonstrated that creating them is difficult, and might require writing a PEP (whose acceptance then might not happen within a summer). Regards, Martin ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
On Fri, Apr 10, 2009 at 4:38 PM, C. Titus Brown wrote: [megasnip] > 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. >From the listed webpage I have no idea what he is promising (a combination of very high level and very low level tasks). If he is offering all the same magic for Hg that Trac does for SVN (autolinking "r2001" text to patches, for example) then I'm +1. That should be cake even for a student project. He says vague things about patches too, but I'm not sure what. If he wanted to make that into a 'patchbot' that just applied every patch in isolation and ran 'make && make test' and posted results in the tracker I'd be a happy camper. But maybe those are goals for next year, because I'm not quite sure what the proposal is. -Jack ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
On Fri, Apr 10, 2009 at 06:05:02PM -0500, Benjamin Peterson wrote: -> 2009/4/10 C. Titus Brown : -> > 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. -> -> To me, both of those proposals seem to say "measure and improve test -> coverage" or "nose integration" with a severe lack specific details. -> Especially the nose plugin one seems like very little work. (Running -> default nose in the test directory in fact works fairly well.) ...fairly, yes ;). But not perfectly. And certainly not with equivalent guarantees to regrtest, which is really what Python developers need. Tracking down the corner cases, writing up examples, setting up tags, getting multiprocess to work properly, and making sure that coverage recording works properly, and then getting people to try it out on THEIR machines, is likely to be a lot of work. The plugin ecosystem for nose is growing daily and supporting that for core would be fantastic; extending it to py.test (whose plugin interface is now mostly compatible with nose) would be even better. The lack of detail on the code coverage is intentional, IMO. It's non-trivial to get a full handle on C code coverage integrated with Python code coverage -- or at least it has been for me -- so I supported the student focusing on first writing robust coverage analysis tools, and only then deciding what to "hit" with more tests. I will encourage the student to talk to this list (or the "tests" list in the stdlib sig) in order to target areas that are more relevant to people. I have had a hard time getting a good sense of what core code is well tested and what is not well tested, across various platforms. While Walter's C/Python integrated code coverage site is nice, it would be even nicer to have a way to generate all that information within any particular checkout on a real-time basis. Doing so in the context of Snakebite would be icing... and I think it's worth supporting in core, especially if it can be done without any changes *to* core. -> Another small nit is that they should address Python 2.x, too. I asked that they focus on EITHER 2.x or 3.x, since "too broad" is an equally valid criticism. Certainly 3.x is the future so I though focusing on increasing code coverage, and especially C code coverage, could best be applied to 3.x. cheers, --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/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
2009/4/10 C. Titus Brown : > 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. To me, both of those proposals seem to say "measure and improve test coverage" or "nose integration" with a severe lack specific details. Especially the nose plugin one seems like very little work. (Running default nose in the test directory in fact works fairly well.) Another small nit is that they should address Python 2.x, too. -- Regards, Benjamin ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
On Fri, Apr 10, 2009 at 6:02 PM, C. Titus Brown wrote: > On Fri, Apr 10, 2009 at 05:53:23PM -0300, Guilherme Polo wrote: > -> > > -> > IDLE/Tkinter patch integration & improvement -- deal with ~120 tracker > -> > ? ? ? ?issues relating to IDLE and Tkinter. > -> > > -> > -> Is it important, for the discussion, to mention that it also involves > -> testing this area (idle and tkinter), Titus ? I'm considering this > -> more important than "just" dealing with the tracker issues. > > What, I tell you that your app is going to be accepted and we shouldn't > argue about it, and you want to argue about it? ;) > Oh awesome then :) I think I misread part of your original email. > --titus > -- > C. Titus Brown, c...@msu.edu > -- -- Guilherme H. Polo Goncalves ___ 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
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
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 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 ever
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
On Fri, Apr 10, 2009 at 05:53:23PM -0300, Guilherme Polo wrote: -> > -> > IDLE/Tkinter patch integration & improvement -- deal with ~120 tracker -> > ? ? ? ?issues relating to IDLE and Tkinter. -> > -> -> Is it important, for the discussion, to mention that it also involves -> testing this area (idle and tkinter), Titus ? I'm considering this -> more important than "just" dealing with the tracker issues. What, I tell you that your app is going to be accepted and we shouldn't argue about it, and you want to argue about it? ;) --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/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
On Fri, Apr 10, 2009 at 5:38 PM, C. Titus Brown 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. > . > . > > IDLE/Tkinter patch integration & improvement -- deal with ~120 tracker > issues relating to IDLE and Tkinter. > Is it important, for the discussion, to mention that it also involves testing this area (idle and tkinter), Titus ? I'm considering this more important than "just" dealing with the tracker issues. > --titus > -- > C. Titus Brown, c...@msu.edu Regards, -- -- Guilherme H. Polo Goncalves ___ 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
[Python-Dev] Google Summer of Code/core Python projects - RFC
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/archive%40mail-archive.com
