[Python-Dev] contributing to multiprocessing
Hi all -- I am interested in making some serious ongoing contributions around multiprocessing. My inspiration, first and foremost, comes from the current documentation for multiprocessing. There is great material there but I believe it is being presented in a way that hinders adoption and understanding. I've taken some initial baby-steps to propose specific changes: http://bugs.python.org/issue22952 http://bugs.python.org/issue23100 The first, issue22952, can reasonably be tackled with a patch like I've submitted. Continuing with patches for issue23100 can also be made to work. I realize that reviewing such patches takes non-trivial time from volunteers yet I'm interested in submitting a series of patches to hopefully make the documentation for multiprocessing much more consistent with other module docs and much more accessible to end users. I don't want to simply create more work for other volunteers -- I'd like to volunteer to reduce / share some of their work as well. Beyond the documentation, there is currently a backlog of 186 issues mentioning multiprocessing, some with patches on offer, some without. I'd like to volunteer my time reviewing and triaging these issues. Hopefully you can already get a sense of my voice on issues from what I wrote in those two issues above. Rather than me simply walking through that backlog, offering comments or encouragement here and there on issues, it makes more sense for me to ask: what is the right way for me to proceed? What is the next step towards me helping triage issues? Is there a bridge-keeper with at least three, no more than five questions for me? Thanks, Davin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] contributing to multiprocessing
On Thu, 08 Jan 2015 17:08:07 -0800, Ethan Furman et...@stoneleaf.us wrote: On 01/08/2015 03:21 PM, Davin Potts wrote: I am interested in making some serious ongoing contributions around multiprocessing. Great! Rather than me simply walking through that backlog, offering comments or encouragement here and there on issues, it makes more sense for me to ask: what is the right way for me to proceed? What is the next step towards me helping triage issues? Is there a bridge-keeper with at least three, no more than five questions for me? I would suggest having at least one, if not two or three, current core-devs ready and willing to quickly review your work (I believe Raymond Hettinger may be one); then, go ahead and triage, improve and/or submit patches, and make comments. Once you've got a few of these under your belt, with favorable reviews and your patches committed, you may get stuck with commit privileges of your own. ;) Indeed, the best way to proceed, regardless of any other issues, is in fact to review, triage, comment on, and improve the issues you are interested in. Get the patches commit ready, and then get a current core dev to do a commit review. Oddly, the doc issues may be more problematic than the code issues. Fixing bugs in docs isn't difficult to get done, but restructuring documentation sometimes gets bogged down in differing opinions. (I haven't myself looked at your proposals since I don't use multiprocessing, so I don't know how radical the proposed changes are). --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] contributing to multiprocessing
Thanks! That sounds like a nice, clear path forward. Regarding the doc issues being a bit more problematic to work through, I thoroughly understand. Davin On Jan 8, 2015, at 21:19, R. David Murray rdmur...@bitdance.com wrote: On Thu, 08 Jan 2015 17:08:07 -0800, Ethan Furman et...@stoneleaf.us wrote: On 01/08/2015 03:21 PM, Davin Potts wrote: I am interested in making some serious ongoing contributions around multiprocessing. Great! Rather than me simply walking through that backlog, offering comments or encouragement here and there on issues, it makes more sense for me to ask: what is the right way for me to proceed? What is the next step towards me helping triage issues? Is there a bridge-keeper with at least three, no more than five questions for me? I would suggest having at least one, if not two or three, current core-devs ready and willing to quickly review your work (I believe Raymond Hettinger may be one); then, go ahead and triage, improve and/or submit patches, and make comments. Once you've got a few of these under your belt, with favorable reviews and your patches committed, you may get stuck with commit privileges of your own. ;) Indeed, the best way to proceed, regardless of any other issues, is in fact to review, triage, comment on, and improve the issues you are interested in. Get the patches commit ready, and then get a current core dev to do a commit review. Oddly, the doc issues may be more problematic than the code issues. Fixing bugs in docs isn't difficult to get done, but restructuring documentation sometimes gets bogged down in differing opinions. (I haven't myself looked at your proposals since I don't use multiprocessing, so I don't know how radical the proposed changes are). --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/python%2Bpython_dev%40discontinuity.net ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
FWIW issue23084 was withdrawn as it appears to be touching and PEP sized, and/or anyways nanosec is defacto just an int. another patch went to http://bugs.python.org/issue15443 seemingly under the radar, I'm not arguing the quality of the patch, but bringing it up here in case with the holidays season it didn't get noticed. I wont bring much anything more so you may rest otherwise. Happy new year! On 12/18/2014 12:47 PM, mdcb808 wrote: done - http://bugs.python.org/issue23084 On 12/17/14 8:20 PM, Eric Snow wrote: On Wed, Dec 17, 2014 at 7:52 PM, Matthieu Bec mdcb...@gmail.com wrote: Attached patch defines a new type struct_timespec for the time module. A new capsule exports the type along with to/from converters - opening a bridge for C, and for example the datetime module. I'd recommend opening a new issue in the bug tracker (bugs.python.org) and attach the patch there. Attaching it to an email is a good way for it to get lost and forgotten. :) -eric -- Matthieu BecGMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] contributing to multiprocessing
On 9 January 2015 at 14:20, Davin Potts pyt...@discontinuity.net wrote: Thanks! That sounds like a nice, clear path forward. Regarding the doc issues being a bit more problematic to work through, I thoroughly understand. In the case of changes to the multiprocessing docs, accepting larger restructures would mainly be the domain of Richard Oudkerk (sbt) as the lead maintainer for the module. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] contributing to multiprocessing
On 01/08/2015 03:21 PM, Davin Potts wrote: I am interested in making some serious ongoing contributions around multiprocessing. Great! Rather than me simply walking through that backlog, offering comments or encouragement here and there on issues, it makes more sense for me to ask: what is the right way for me to proceed? What is the next step towards me helping triage issues? Is there a bridge-keeper with at least three, no more than five questions for me? I would suggest having at least one, if not two or three, current core-devs ready and willing to quickly review your work (I believe Raymond Hettinger may be one); then, go ahead and triage, improve and/or submit patches, and make comments. Once you've got a few of these under your belt, with favorable reviews and your patches committed, you may get stuck with commit privileges of your own. ;) -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My thinking about the development process
On Thu, Jan 8, 2015 at 12:59 AM, Nick Coghlan ncogh...@gmail.com wrote: On 6 December 2014 at 06:04, Brett Cannon bcan...@gmail.com wrote: # Next steps I'm thinking first draft PEPs by February 1 to know who's all-in (8 weeks away), all details worked out in final PEPs and whatever is required to prove to me it will work by the PyCon language summit (4 months away). I make a decision by May 1, and then implementation aims to be done by the time 3.5.0 is cut so we can switch over shortly thereafter (9 months away). Sound like a reasonable timeline? I've now updated PEP 474 to cover my current proposal for the support repositories, as well as some of the preparatory work that is already being undertaken: https://www.python.org/dev/peps/pep-0474/ By the end of the month, I'll also aim to have an updated version of PEP 462 published that considers how the forge.python.org service could potentially be extended to handle CPython itself, rather than attempting to build those flows directly into the existing Roundup and Rietveld based approach. There could be JSON[-LD] schema to describe resources with attributes: https://github.com/westurner/wiki/wiki/ideas#open-source-mailing-list-extractor There could be configurable per-list link heuristics: - http[s] - Issue: https://bugs.python.org/issue(d+) - Src: https://hg.python.org/repo/path - Src: https://github.com/org/project/path - Src: https://bitbucket.org/org/project/path - Patch/Attachment: http[s]://bugs.python.org/(file[d]+)/ filename(.diff) - Doc: https://docs.python.org/ver/path - Wiki: https://wiki.python.org/moin/path - Homepage: https://www.python.org/path - PyPI pkg: https://pypi.python.org/pypi/path - Warehouse pkg: https://warehouse.python.org/project/path - Wikipedia: https://[lang].wikipedia.org/wiki/page -- (dbpedia:page) - Build: http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.4/builds/771 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My thinking about the development process
I did a pull-request with current progress: https://github.com/python/psf-salt/pull/25 Any feedback is appreciated. Btw: Donald is very patient and helpful. :) On Thu Jan 08 2015 at 8:00:59 AM Nick Coghlan ncogh...@gmail.com wrote: On 6 December 2014 at 06:04, Brett Cannon bcan...@gmail.com wrote: # Next steps I'm thinking first draft PEPs by February 1 to know who's all-in (8 weeks away), all details worked out in final PEPs and whatever is required to prove to me it will work by the PyCon language summit (4 months away). I make a decision by May 1, and then implementation aims to be done by the time 3.5.0 is cut so we can switch over shortly thereafter (9 months away). Sound like a reasonable timeline? I've now updated PEP 474 to cover my current proposal for the support repositories, as well as some of the preparatory work that is already being undertaken: https://www.python.org/dev/peps/pep-0474/ By the end of the month, I'll also aim to have an updated version of PEP 462 published that considers how the forge.python.org service could potentially be extended to handle CPython itself, rather than attempting to build those flows directly into the existing Roundup and Rietveld based approach. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ tymoteusz.jankowski%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My thinking about the development process
On Jan 8, 2015, at 4:26 AM, Tymoteusz Jankowski tymoteusz.jankow...@gmail.com wrote: I did a pull-request with current progress: https://github.com/python/psf-salt/pull/25 https://github.com/python/psf-salt/pull/25 Any feedback is appreciated. Btw: Donald is very patient and helpful. :) Ah oops, I forgot to review that. *goes to do so now*. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
