Re: [Python-Dev] GSoC: Core Python development tools
Antoine Pitrou wrote: > Well, it seems to me that most of these steps are separated by manual > intervention (e.g. compile and run the test suite to check that everything > works > smoothly) Agreed. > so there's no real point in making a script out of them. The idea would be to provide scripts for each step that people think should be easier/automated. Like running the provided testcase before and after applying the corresponding patch. Or making sure to build before running tests for a patch that touches C code. > The real issues with svnmerge are its occasional bugs or failures (it forgot > some changesets when merging in the io-c branch!) Who's handling those bugs? Is any of them avoidable/easier to catch/easier to workaround with a script that checks for, e.g., svnmerge version, svnmerge correct usage and completeness of the merge? I think this proposal could help reproducing those issues and fixing/mitigating them until a better solution is available. > its slowness, Maybe something could be improved in svnmerge, as Martin suggests. Or merging could be made a bit easier, so people would backport their commits themselves more often and the laundry list merges could be a little smaller. > and its > limitations (which are really inherent to the SVN model: e.g., if someone > commits to the branch you have just started doing an svnmerge to, you have to > revert everything and start over with the latest updates). We have discussed this off-list and I have no answer regarding SVN limitations. If a svnmerge-on-top-of-hg or svnmerge-on-top-of-bzr script can be used to merge SVN branches with the exact same results of the real svnmerge, only faster and prettier, maybe it should be considered for GSoC too. If/when the main Python repository moves to a DVCS, scripts that allow people to perform the same steps they currently perform to achieve the same results might help the transition. I won't mention the bzr-on-top-of-git part :) Cheers, Daniel ___ 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] GSoC: Core Python development tools
"Martin v. Löwis" wrote: > Yes, I'm also quite grateful for the contributions I have received from > Daniel. Thank you Martin. I'm sure I'd still be going around in circles if it weren't for your guidance, and I'd be MIA after the first time I broke the tracker too. So thanks a lot for the support. > I hope he'll stay around for some time without exhausting. Me too. I'm trying to leave a big audit trail so other people can join efforts or take over parts of roadmap easily, but that's also a backup for long fieldwork trips or the eventual burn out. Best regards, Daniel ___ 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] GSoC: Core Python development tools
Nick Coghlan wrote: > Everything I've seen from Daniel so far seems to be about either making > things we already do more efficient, or else providing additional > features in ways that don't make the tools any more confusing for others > already used to a particular way of doing things. So he seems to be > navigating this particular minefield pretty well so far. Thanks a lot Nick! :) BTW, it seems there's a procedure to follow if my navigation fails[1]. > Then again, I may be a little biased - some of the recent bug tracker > changes are things I had wished for in the past, but never chipped in > any code to help make them happen :) Not a problem, sir, we accept RFEs devoid of any code bits in this store :) Cheers, Daniel [1] George: If we do happen to step on a mine, Sir, what do we do? Capt. Blackadder: Normal procedure, Lieutenant, is to jump two hundred feet in the air and scatter oneself over a wide area. ___ 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] GSoC: Core Python development tools
>> P.S. I don't believe your claim that it forgot changesets. Could it be >> that it simply forgot adding files, and that it did so because you >> already had the files in the sandbox, so that the merging failed? > > It's more weird actually, it actively forgot some changes in some files but > some > other changes in the /same/ files did get merged. I see. Provided there is somebody willing to work on this, it might be interesting to reproduce it. >> P.P.S. Are you sure you have to re-merge when somebody commits >> something unrelated to the branch? Or just when somebody else merges >> as well? > > Perhaps only the latter, I'm not sure actually. > (but it can also happen that the "unrelated" commit modifies some files you > were > merging changes in...) That should not be a problem, unless the to-be-merged changes directly conflict. Just svn-update, then try committing again. It's actually also possible to recover from overlapping merges also: just re-run svnmerge with --record-only (-M); this assumes nobody else has merged the very same changes concurrently. 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] GSoC: Core Python development tools
Martin v. Löwis v.loewis.de> writes: > > P.S. I don't believe your claim that it forgot changesets. Could it be > that it simply forgot adding files, and that it did so because you > already had the files in the sandbox, so that the merging failed? It's more weird actually, it actively forgot some changes in some files but some other changes in the /same/ files did get merged. > P.P.S. Are you sure you have to re-merge when somebody commits > something unrelated to the branch? Or just when somebody else merges > as well? Perhaps only the latter, I'm not sure actually. (but it can also happen that the "unrelated" commit modifies some files you were merging changes in...) ___ 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] GSoC: Core Python development tools
Martin v. Löwis wrote: > P.P.S. Are you sure you have to re-merge when somebody commits > something unrelated to the branch? Or just when somebody else merges > as well? The latter is the only one I've ever had problems with (and that was due to me forgetting to update before merging rather than someone else actually doing a concurrent merge). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] GSoC: Core Python development tools
> The real issues with svnmerge are its occasional bugs or failures (it forgot > some changesets when merging in the io-c branch!), its slowness, and its > limitations (which are really inherent to the SVN model: e.g., if someone > commits to the branch you have just started doing an svnmerge to, you have to > revert everything and start over with the latest updates). I think addressing the slowness should surely be in scope for SoC: I would hope that rewriting it to only use a single session should provide some speedup (i.e. through the Python bindings, rather than the command line). Of course, such a project might better be mentored at subversion than Python. Regards, Martin P.S. I don't believe your claim that it forgot changesets. Could it be that it simply forgot adding files, and that it did so because you already had the files in the sandbox, so that the merging failed? P.P.S. Are you sure you have to re-merge when somebody commits something unrelated to the branch? Or just when somebody else merges as well? ___ 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] GSoC: Core Python development tools
> Everything I've seen from Daniel so far seems to be about either making > things we already do more efficient, or else providing additional > features in ways that don't make the tools any more confusing for others > already used to a particular way of doing things. So he seems to be > navigating this particular minefield pretty well so far. Yes, I'm also quite grateful for the contributions I have received from Daniel. I hope he'll stay around for some time without exhausting. 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] GSoC: Core Python development tools
2009/3/23 Antoine Pitrou : > Guilherme Polo gmail.com> writes: >> >> Any chance you were not using the latest svnmerge when you did that >> merge ? I've had problems like this when using older versions. > > Well, actually, Benjamin did the merge, so perhaps he can give more info. I was using the latest svnmerge.py from the SVN trunk. (maybe it's broken?) -- 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] GSoC: Core Python development tools
Guilherme Polo gmail.com> writes: > > Any chance you were not using the latest svnmerge when you did that > merge ? I've had problems like this when using older versions. Well, actually, Benjamin did the merge, so perhaps he can give more info. Regards Antoine. ___ 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] GSoC: Core Python development tools
On Mon, Mar 23, 2009 at 5:03 PM, Antoine Pitrou wrote: > > Hi, > > Daniel (ajax) Diniz gmail.com> writes: >> >> But the real point is that, regardless of underlying VCS, there is a >> choice between "having all core developers know by heart the right >> switches and order of steps to correctly checkout/update ->( branch >> locally) -> fix -> diff -> commit -> merge -> solve conflicts" and >> "offering a little, well-documented script that takes care of the >> switches and sequence of steps". > > Well, it seems to me that most of these steps are separated by manual > intervention (e.g. compile and run the test suite to check that everything > works > smoothly), so there's no real point in making a script out of them. > > The real issues with svnmerge are its occasional bugs or failures (it forgot > some changesets when merging in the io-c branch!), Any chance you were not using the latest svnmerge when you did that merge ? I've had problems like this when using older versions. > its slowness, and its > limitations (which are really inherent to the SVN model: e.g., if someone > commits to the branch you have just started doing an svnmerge to, you have to > revert everything and start over with the latest updates). > > Regards > > Antoine. > > > ___ > 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/ggpolo%40gmail.com > -- -- 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] GSoC: Core Python development tools
Hi, Daniel (ajax) Diniz gmail.com> writes: > > But the real point is that, regardless of underlying VCS, there is a > choice between "having all core developers know by heart the right > switches and order of steps to correctly checkout/update ->( branch > locally) -> fix -> diff -> commit -> merge -> solve conflicts" and > "offering a little, well-documented script that takes care of the > switches and sequence of steps". Well, it seems to me that most of these steps are separated by manual intervention (e.g. compile and run the test suite to check that everything works smoothly), so there's no real point in making a script out of them. The real issues with svnmerge are its occasional bugs or failures (it forgot some changesets when merging in the io-c branch!), its slowness, and its limitations (which are really inherent to the SVN model: e.g., if someone commits to the branch you have just started doing an svnmerge to, you have to revert everything and start over with the latest updates). Regards Antoine. ___ 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] GSoC: Core Python development tools
Thanks for the feedback, Antoine! Antoine Pitrou wrote: > Daniel (ajax) Diniz gmail.com> writes: >> >> Sometimes, non-obvious bits like the right sequence of svnmerge >> commands, the right way to link a Rietveld code review to a given >> issue or checking for correct autoconf version might get in the way of >> real development. > > Well, really, rather than trying to improve svnmerge, we should try to find a > way forward to switch to Merc... oops, I mean what will turn out to be the > best > DVCS for our needs :-) That was a little bait for input ;) But the real point is that, regardless of underlying VCS, there is a choice between "having all core developers know by heart the right switches and order of steps to correctly checkout/update ->( branch locally) -> fix -> diff -> commit -> merge -> solve conflicts" and "offering a little, well-documented script that takes care of the switches and sequence of steps". Maybe a 'untangle svnmerge-created history' tool would help too? :) >> I am also available to help with the Python workflow part, and >> there's an early effort to integrate Rietveld and our bug tracker >> under way. > >> Food for thought example (sorry, not quite how a core dev works): > [...] >> >> SVN exporting current working copy to: ../month_delta > > Does it work when using an hg/bzr/git mirror? There's already hg and git > support > in Rietveld's upload.py, so this should be possible. Given that the pyfix script is completely imaginary ATM, yes, it works as well with hg/bzr/git/perforce/CVS/darcs as it does with SVN :) In a more serious note, the PIDA offer puts anyvc[1] on the table. So we could support different VCSs as upload.py does it, or aim for a more pluggable way, probably based on anyvc. Either way, them scripts should be simple and follow the Unix way, so e.g. pyfix --export would actually call anyvc --export or pyvcs --export. Cheers, Daniel [1] http://pypi.python.org/pypi/anyvc ___ 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] GSoC: Core Python development tools
Daniel (ajax) Diniz gmail.com> writes: > > Sometimes, non-obvious bits like the right sequence of svnmerge > commands, the right way to link a Rietveld code review to a given > issue or checking for correct autoconf version might get in the way of > real development. Well, really, rather than trying to improve svnmerge, we should try to find a way forward to switch to Merc... oops, I mean what will turn out to be the best DVCS for our needs :-) > I am also available to help with the Python workflow part, and > there's an early effort to integrate Rietveld and our bug tracker > under way. > Food for thought example (sorry, not quite how a core dev works): [...] > > SVN exporting current working copy to: ../month_delta Does it work when using an hg/bzr/git mirror? There's already hg and git support in Rietveld's upload.py, so this should be possible. ___ 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] GSoC: Core Python development tools
C. Titus Brown wrote: > Given the relative paucity of core Python GSoC ideas, I think you should > go for both of these, *especially* if you have a mentor up front. So, > write 'em up, add 'em to the GSoC page, and let's see who we get... > If we get good applications for both, then I think we can "fund" both of > them. Great, thanks a lot for the feedback :) > I do think you should be prepared for pushback from python-dev on any > such ideas ;). Don't get too ambitious about writing up *your* way of > fixing things, but rather make sure you and the students are prepared to > adapt to what people on python-dev think. Mind you, ultimately the > people doing the work should make the decisions, but input from > python-dev is usually pretty useful even when it's contradictory! Pushback? Luxury! :) Thanks for the great advice, but I'd actually love negative input on this. Better to find out early that there's no way out of the bikeshedding tar pit than to waste a slot (and the student's time). I think many people don't speak up for or against GSoC proposals because they don't have time to mentor / discuss details. This particular proposal is doomed if nobody voices the itches to be scratched. So I'm kinda taunting python-dev with a huge proposal that goes around generalities and tries to make the case for joining efforts with PIDA ;) Skipping to "Suggestions" and the "Food for thought example" might help in deciding whether the wall of text is worth a look... Best regards, Daniel == Helper Python core development tools. There's some amount of repetitive, required steps to work on Python development. This proposal is about improving the workflow of core developers, probably with small glue scripts. As each developer has his own personal workflow, these helper scripts should be optional, easy to extend and aimed at the most common tasks. Of course, there may be no real demand for optimizing the workflow. Avoiding the use of a GSoC slot for unnecessary projects is very important, so if you think it's a wast of resources, please speak up :) Justification Sometimes, non-obvious bits like the right sequence of svnmerge commands, the right way to link a Rietveld code review to a given issue or checking for correct autoconf version might get in the way of real development. Other obvious steps, like handling issue properties (e.g. Resolution), posting a message that tells in which revs the issue was fixed of or even checking for changes in tabs versus spaces, also require a bit of time. Regardless of obviousness, forgetting one item (or getting it wrong) in the development checklist happens from time to time. If there are ways to factor these repetitive, required tasks out from a core dev's concerns, it can only help the development process. Non-code developers could also benefit from this kind of tool, and could contribute in a more efficient way to Python development, with higher code/ticket quality. Quoting the tracker cleanup proposal: Optimizing the application of main/core developers' time to Python issues is a no-brainer. Being able to add volunteers to the productive time pool is also very desirable. Pre-Requisites Identifying which tasks and steps should be optimized cannot be left to the student nor to the mentor, it must be a collective effort. Clear goals must be set before someone try to implement them. Sure, there are many descriptions of workflows in past python-dev (and python-list) threads, but the GSoC is about code. Methods It's up to the mentors/student team. I suggest offering early releases for the scripts and maybe test repositories, trackers, Rietveld instance, etc., as ways of making sure the resulting code will be useful and used by the target public. I believe most tools should be developed in a generic way, so that they could fit in other projects and workflows. IMHO, this would make the resulting scripts much more valuable. Student Besides some experience with Python and tools of the trade (VCSs, bug trackers, etc.), the most important requisite is being able to listen to the community and taking criticism well. Mentors Ali Afshar from PIDA is willing to mentor if the 'generic tools' way is accepted. Since it's about reusing development tools inside an IDE, any of these helper scripts could be integrated into PIDA, the only pre-requisite being that they'd not be too deeply linked to the Python infrastructure. With a small bit of concern about this, it'd be easy to extend/fork the resulting tools to use with other trackers, VCSs, test runners and code review tools. I am also available to help with the Python workflow part, and there's an early effort to integrate Rietveld and our bug tracker under way. At least one core Python developer should mentor, preferably one that knows how to interact well with python-dev. Any project focused on how people work is prone to flamefests, so diverting most heat away from the student might be a nece
Re: [Python-Dev] GSoC: Core Python development tools
> Oh, I heartily endorse his suggestions! I just want to make sure that we > make maximum use of students (and their code doesn't get tossed at the > end of the summer, which has serious morale consequences ;) This is my concern as well. One of my past students pitched a core project and ended up spending most of his SoC time in the PEP process (http://www.python.org/dev/peps/pep-0368/). Given how frustrating the experience was for him, I'd rather have future SoC students be able to focus on code. Let's at least have rough consensus on brainstormed ideas before they hit the ideas page. Existing PEPs that have had a time to air and evolve are much better for this reason. ___ 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] GSoC: Core Python development tools
On Mon, Mar 23, 2009 at 10:26:54PM +1000, Nick Coghlan wrote: -> C. Titus Brown wrote: -> > On Sun, Mar 22, 2009 at 07:30:01PM -0300, Daniel (ajax) Diniz wrote: -> > I do think you should be prepared for pushback from python-dev on any -> > such ideas ;). Don't get too ambitious about writing up *your* way of -> > fixing things, but rather make sure you and the students are prepared to -> > adapt to what people on python-dev think. Mind you, ultimately the -> > people doing the work should make the decisions, but input from -> > python-dev is usually pretty useful even when it's contradictory! -> -> Everything I've seen from Daniel so far seems to be about either making -> things we already do more efficient, or else providing additional -> features in ways that don't make the tools any more confusing for others -> already used to a particular way of doing things. So he seems to be -> navigating this particular minefield pretty well so far. -> -> Then again, I may be a little biased - some of the recent bug tracker -> changes are things I had wished for in the past, but never chipped in -> any code to help make them happen :) Oh, I heartily endorse his suggestions! I just want to make sure that we make maximum use of students (and their code doesn't get tossed at the end of the summer, which has serious morale consequences ;) --t -- 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] GSoC: Core Python development tools
C. Titus Brown wrote: > On Sun, Mar 22, 2009 at 07:30:01PM -0300, Daniel (ajax) Diniz wrote: > I do think you should be prepared for pushback from python-dev on any > such ideas ;). Don't get too ambitious about writing up *your* way of > fixing things, but rather make sure you and the students are prepared to > adapt to what people on python-dev think. Mind you, ultimately the > people doing the work should make the decisions, but input from > python-dev is usually pretty useful even when it's contradictory! Everything I've seen from Daniel so far seems to be about either making things we already do more efficient, or else providing additional features in ways that don't make the tools any more confusing for others already used to a particular way of doing things. So he seems to be navigating this particular minefield pretty well so far. Then again, I may be a little biased - some of the recent bug tracker changes are things I had wished for in the past, but never chipped in any code to help make them happen :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] GSoC: Core Python development tools
On Sun, Mar 22, 2009 at 07:30:01PM -0300, Daniel (ajax) Diniz wrote: -> Even if neither is considered worthy, I'll keep them on my to-do list -> and hope to slowly and hackishly work towards both proposals' goals. -> Barring feedback saying that they're out of scope, stupid and -> downright offensive, I'll post details on each to this thread very -> soon. Given the relative paucity of core Python GSoC ideas, I think you should go for both of these, *especially* if you have a mentor up front. So, write 'em up, add 'em to the GSoC page, and let's see who we get... If we get good applications for both, then I think we can "fund" both of them. I do think you should be prepared for pushback from python-dev on any such ideas ;). Don't get too ambitious about writing up *your* way of fixing things, but rather make sure you and the students are prepared to adapt to what people on python-dev think. Mind you, ultimately the people doing the work should make the decisions, but input from python-dev is usually pretty useful even when it's contradictory! 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
[Python-Dev] GSoC: Core Python development tools
Hi, I'd like to bring up the general idea of using a PSF slot in GSoC2009 to improve the Python development infrastructure. I also happen to have two concrete proposals for that (such a coincidence!). But I assure you the general idea is more important than my proposals :) General: Solving issues that get in core devs' way when they work on Python development could be a nice PSF GSoC project. I believe there are enough code related tasks that would greatly improve Python development workflow but lack manpower to complete. E.g., ISTM that a student working on svnmerge in past SoC editions would've been able to mitigate some painful shortcomings. If the core developers could come up with a list of peeves that would be solvable in code (in existing tools), that would allow for a very useful GSoC proposal. Proposals: These might fit the description above, and they're both tracker related (yep, one-trick-pony here). The upside is that at least one potential mentor is available for each, and I'd be able to offer support to the student. First, the PSF could invest a slot on integrating different tools of the development workflow. Variations of 'file issue at bug tracker, submit code for review' or 'branch locally to virtualenv, upload failing testcase to tracker, upload patch to tracker' command line utils. If these could be developed as general tools (i.e., not deeply tied to Python dev infrastructure), Ali Afshar from PIDA is willing to mentor it. I'd be available to help with Roundup and Rietveld (integration in progress), but would like to see it work with Launchpad, Bugzilla, Google Code and Review Board :) The other proposal is to use a slot in Roundup proper and the Python tracker instance. This could have a core Roundup developer as mentor, under the condition it's focused on Roundup itself. IMO, are some missing/broken core features in Roundup that would have a positive impact on our tracker, mostly those relating to searches, security and UI. I'd have a lot to contribute to the Python tracker part, based on ongoing work. Even if neither is considered worthy, I'll keep them on my to-do list and hope to slowly and hackishly work towards both proposals' goals. Barring feedback saying that they're out of scope, stupid and downright offensive, I'll post details on each to this thread very soon. So, if the PSF was to use a slot on improving the way you work on Python development, what would you like to see fixed or implemented? Best regards, Daniel ___ 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
