Re: [Python-Dev] Contribute
On Tue, Mar 30, 2010 at 2:20 AM, wrote: > > Shashwat> Python should have something like gnome-love ( > Shashwat> http://live.gnome.org/GnomeLove ). Some bugs on bugzilla is > Shashwat> tagged with gnome-love which are fairly easy and especially > Shashwat> created to help dive in new developers. > > I don't know what gnome love is (and would be hesitant to click on any such > links, especially at work) but on bugs.python.org such items are tagged > "easy". Right on the front page is a link with the label "Show Easy". The difference between "gnome-love" and "easy" tags is that the latter can only be flagged by code devs (who usually do not have much time to review bugs). -- anatoly t. ___ Python-Dev mailing list [email protected] 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 2010 is on -- projects?
On Mon, Mar 29, 2010 at 3:30 PM, C. Titus Brown wrote: > >> I would vote for allowing student work on community infrastructure >> tasks. Tracker, Wiki, Web site management tools are all outdated and >> everybody who cares agrees that they've seen a better tools. > > As long as it's programming, it's allowed by Google. So let's find a good > student or two, and outline a few good projects! > > I do worry that that kind of work is difficult to evaluate, and requires > really > great communication on both sides... First we need to compile a list of things to do into one big list. I see the major problem that there is no "dashboard" that gives an overview of available/supported community services and their status. Services that are parts of python.org and those that linked and often used, but not parts. Status of service is the amount of opened/languishing bugs/enhancements. Some services don't have trackers at all. For example, infrastructure proposals, web site patches is nowhere to track. Service on a dashboard should be accompanied by contact points info. Service should list location of primary repository and mirrors. Feature creep: - Service can be monitored for online/offline status. - Service may have maintenance scripts, which community members can see, inspect scheduled times for the next run and results of execution. - Service may publish stats for further analysis. After dashboard is ready, it would be nice to unify all Services: 1. Add OpenID/Google support 2. Add searchable Google Groups mirrors 3. Add Google search form to Mailman web interface for hosted groups 4. Register services search with Google (see attach) Then we need to find a contact point - a person who could be most helpful for each service and help other students with other specific tasks. I am not such person for neither service, but I am interested to help push progress forward. -- anatoly t. <>___ Python-Dev mailing list [email protected] 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 2010 is on -- projects?
anatoly techtonik writes: > I would vote for allowing student work on community infrastructure > tasks. Tracker, Wiki, Web site management tools are all outdated and > everybody who cares agrees that they've seen a better tools. I've also seen *much* worse tools in actual use. You don't have to look any farther than macports.org and GNU Savannah for examples of implementations of individual tools that are much worse, and overall usability that is clearly worse, than Python's environment. Over and over again I have seen short-term volunteers pick the best- reputed software of the day, run out of steam just getting the old data ported over to the new host software, leaving behind a disgrace. (This is what happened to MacPorts Trac, it would seem -- it took 4 years for them to get an explanation of how to search for bugs on a given port on the top page of the issue tracker, and you still have to type queries like "?PORT=python26" by hand in the browser address field![1]) In other cases, the old data is never successfully ported at all (a common way to migrate from one VCS to another). So while improving the infrastructure is clearly a good thing, it is not a good idea to have people without *long-term* commitment to maintenance *changing the tools themselves*. I would recommend changing the tools only if *current* maintainers are either planning to step down (and so we face the problem of how to support maintenance in the future in any case), or are willing to supervise (ie, the people who will come back and fix problems in the future find the proposed "improvements" to be real improvements). Eg, MvL should be intimately involved in any move to use different software for the tracker. If the GSoC student(s) is (are) willing to work within the constraints of the existing software (ie, incremental improvements), then the constraints on mentors could be substantially relaxed to any of the senior folks who have recently contributed in those areas. Footnotes: [1] Actually, it may be even worse than it looks -- IIUC, macosforge has paid staff! ___ Python-Dev mailing list [email protected] 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 2010 is on -- projects?
On Wed, Mar 31, 2010 at 05:41:47PM +0900, Stephen J. Turnbull wrote: > anatoly techtonik writes: > > > I would vote for allowing student work on community infrastructure > > tasks. Tracker, Wiki, Web site management tools are all outdated and > > everybody who cares agrees that they've seen a better tools. [ munch ] > I would recommend changing the tools only if *current* maintainers are > either planning to step down (and so we face the problem of how to > support maintenance in the future in any case), or are willing to > supervise (ie, the people who will come back and fix problems in the > future find the proposed "improvements" to be real improvements). Eg, > MvL should be intimately involved in any move to use different > software for the tracker. If the GSoC student(s) is (are) willing to > work within the constraints of the existing software (ie, incremental > improvements), then the constraints on mentors could be substantially > relaxed to any of the senior folks who have recently contributed in > those areas. Agreed. It'd be great to have students work on prototyping improvements, with an eye to making changes that can then be evaluated in terms of maintainability, extensibility, etc. Having them actually change the infrastructure itself seems to me like a bad idea :) --titus -- C. Titus Brown, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Add -3 and -Wd to the buildbots
Hi, now that the py3k warnings are fixed (see http://bugs.python.org/issue7092) we should run the tests on the trunk buildbots with the -3 flags, in order to check if new warnings are introduced and possibly to uncover other ones. It might be a good idea to add the -Wd flag too, both on trunk and py3k. -Ezio ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Replacing threads with swapcontext()
Hello. I have went and replaced Python threads with explicitly-scheduled coroutines using swapcontext() family of functions (basically out of frustration with the greenlet). I have two questions. 1. Is it as dangerous to switch C stacks and not switch PyThreadState as I suspect? In particular, how tightly is PyThreadState::frame coupled to current C stack? 2. How do you all look at merging my work as another threading-related configure switch? It's only another thread_something.h file and a small patch to threadmodule.c. Project is at http://code.google.com/p/coev/ -- ./lxnt ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add -3 and -Wd to the buildbots
On Wed, Mar 31, 2010 at 07:58, Ezio Melotti wrote: > Hi, > now that the py3k warnings are fixed (see http://bugs.python.org/issue7092) > we should run the tests on the trunk buildbots with the -3 flags, in order > to check if new warnings are introduced and possibly to uncover other ones. > It might be a good idea to add the -Wd flag too, both on trunk and py3k. > +1 from me. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add -3 and -Wd to the buildbots
2010/3/31 Brett Cannon: > On Wed, Mar 31, 2010 at 07:58, Ezio Melotti wrote: >> Hi, >> now that the py3k warnings are fixed (see >> http://bugs.python.org/issue7092) we should run the tests on the trunk >> buildbots with the -3 flags, in order to check if new warnings are >> introduced and possibly to uncover other ones. >> It might be a good idea to add the -Wd flag too, both on trunk and py3k. > > +1 from me. I agree, it could help to catch unexpected warnings or bugs earlier in the process. -- Florent ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add -3 and -Wd to the buildbots
> now that the py3k warnings are fixed (see > http://bugs.python.org/issue7092) we should run the tests on the trunk > buildbots with the -3 flags, in order to check if new warnings are > introduced and possibly to uncover other ones. > It might be a good idea to add the -Wd flag too, both on trunk and py3k. Not sure what you are asking for. If you want confirmation that this change is desirable, it seems you got that already. If you are asking for someone to make that change - go ahead and make it yourself. You just need to change the buildbottest target. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacing threads with swapcontext()
Alexander Sabourenkov wrote: > Hello. > > I have went and replaced Python threads with explicitly-scheduled > coroutines using swapcontext() family of functions (basically out of > frustration with the greenlet). > > I have two questions. > > 1. Is it as dangerous to switch C stacks and not switch PyThreadState as > I suspect? In particular, how tightly is PyThreadState::frame coupled to > current C stack? Off the top of my head, recursion limit checks will definitely go haywire, and I would expect threading.local() and exception handling to explode at some point (although the latter depends on what you mean by "switching C stacks" - if you really are just fiddling the stack pointer without affecting the thread local heap storage mechanisms, the latter two should be fine. Still doesn't sound like a good idea though). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
