Re: [Python-Dev] Helping contributors with chores (do we have to?)
On 27 June 2017 at 07:49, Brett Cannon wrote: > On Sun, 25 Jun 2017 at 01:34 Antoine Pitrou wrote: >> So we have to rely on contributors to make the PR >> merge-ready by themselves... which means spending some time guiding >> them through the oh-so-exciting steps necessary to add the right >> Misc/NEWS entry, > > My hope is that having a news entry status check through Bedevere with help > with that. I'm also open to ideas on how to make it more obvious to > first-time contributors that things need to be done, e.g. maybe a default PR > message that is nothing more than "" (making it an HTML comment means it won't' ever show up in > the rendered output of the PR, plus that comment is short and thus easy to > ignore)? We could also make the CONTRIBUTING.md file have a bullet-point > list of the key things we expect people to do that is different from most > projects. (The only other thing I can think of is a comment for first-time > contributors pointing all of this out, but I'm leery of that as all of our > bots are stateless and this would make at least Bedevere stateful.) This reminded me of another relevant option for contributors making their first drafts of NEWS entries: they/we can take an existing NEWS snippet like https://github.com/python/cpython/blob/master/Misc/NEWS.d/next/Core%20and%20Builtins/2017-06-26-14-29-50.bpo-30765.Q5iBmf.rst, save it under an appropriate filename, and then edit the content. To be honest, I suspect that's how I'll end up writing most of my own NEWS entries rather than using blurb to generate them :) 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] Helping contributors with chores (do we have to?)
Small enhancement: I added Python 3.5 support to blurb with the help of Serhiy Storchaka ;-) Victor 2017-06-25 10:33 GMT+02:00 Antoine Pitrou : > On Sat, 24 Jun 2017 21:37:46 -0700 > Larry Hastings wrote: >> On 06/24/2017 09:14 PM, Serhiy Storchaka wrote: >> > Not only core developers make PRs for CPython. Since all non-trivial >> > changes need to be mentioned in Misc/NEWS, blurb becomes a required >> > tool for all committers. >> >> Well, no. *Writing blurb-compatible files* becomes a required step for >> all committers. And blurb makes that easy. But it's pretty easy to >> write them by hand; that's why we pre-created the "next" directories, >> and there are instructions in the dev guide. > > Hmm. If it were so easy, you wouldn't have felt the need to add that > functionality to blurb, right? :-) > > This is touching a more general problem, though. Before GitHub, we > (core developers) would take the patch submitted by a contributor, make > whatever minor changes were needed (e.g. Misc/NEWS) and push the > aggregate ourselves. With GitHub, while it's possible to edit someone > else's PR, it's frankly a PITA (I've tried to do it once, I don't want > to try a second time unless GitHub makes it massively easier and less > footgunning-prone). So we have to rely on contributors to make the PR > merge-ready by themselves... which means spending some time guiding > them through the oh-so-exciting steps necessary to add the right > Misc/NEWS entry, or fix the occasional bit of reStructuredText > mis-syntax. > > Regards > > Antoine. > > > ___ > 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/victor.stinner%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
[Python-Dev] Proposal for C++ metaclasses
Thought this might be interesting for those of us who live deeper in the language than most – this is the formal proposal to add metaclasses to C++. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf Given the differences between Python and C++, it’s obviously got a different approach, though I am struck by the similarities. I think it’s also a good presentation on the value and use of metaclasses, so likely also interesting for those of us who occasionally teach or explain the concept. Cheers, Steve ___ 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] Proposal for C++ metaclasses
Heh, I'm not totally surprised -- I took Python's metaclass design from a book named Putting Metaclasses to Work, by Ira R. Forman and Scott H. Danforth ( https://www.amazon.com/Putting-Metaclasses-Work-Ira-Forman/dp/0201433052). The book describes a custom metaclass extension to C++ supporting metaclasses, from which I took everything I could given that Python is a dynamic language (the key thing I left out was automatic synthesis of combined metaclasses when multiple inheritance sees two unrelated metaclasses). Hopefully the authors get some credit in the current C++ standard proposal. On Tue, Jun 27, 2017 at 7:36 AM, Steve Dower wrote: > Thought this might be interesting for those of us who live deeper in the > language than most – this is the formal proposal to add metaclasses to C++. > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf > > > > Given the differences between Python and C++, it’s obviously got a > different approach, though I am struck by the similarities. I think it’s > also a good presentation on the value and use of metaclasses, so likely > also interesting for those of us who occasionally teach or explain the > concept. > > > > Cheers, > > Steve > > ___ > 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/ > guido%40python.org > > -- --Guido van Rossum (python.org/~guido) ___ 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] New work-in-progress bisection tool for the Python test suite (in regrtest)
2017-06-27 7:33 GMT+02:00 Serhiy Storchaka : > You could make it just a submodule in the test package. > > ./python -m test.bisect -R 3:3 test_os I like the idea :-) I proposed a PR which was approved by Yury Selivanov, and so I just merged it! It means that you can now play with "./python -m test.bisect" in the master branch. Enjoy ;-) Example: ./python -m test.bisect -R 3:3 test_multiprocessing_forkserver This command should give you the name of the two failing test methods which are the last known reference leaks! => http://bugs.python.org/issue30775 This specific bisection is very slow since running the 286 tests of test_multiprocessing_forkserver using -R 3:3 takes longer than 3 minutes on my laptop! And the answer is already know, see the bpo ;-) FYI, apart of the bpo-30775, all other reference leaks now seem to be fixed on 2.7, 3.5, 3.6 and master branches! Tested on Windows and Linux. Victor ___ 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] New work-in-progress bisection tool for the Python test suite (in regrtest)
That's great, Victor. Thanks for all of your work on this. Eric. On 6/27/2017 8:39 PM, Victor Stinner wrote: 2017-06-27 7:33 GMT+02:00 Serhiy Storchaka : You could make it just a submodule in the test package. ./python -m test.bisect -R 3:3 test_os I like the idea :-) I proposed a PR which was approved by Yury Selivanov, and so I just merged it! It means that you can now play with "./python -m test.bisect" in the master branch. Enjoy ;-) Example: ./python -m test.bisect -R 3:3 test_multiprocessing_forkserver This command should give you the name of the two failing test methods which are the last known reference leaks! => http://bugs.python.org/issue30775 This specific bisection is very slow since running the 286 tests of test_multiprocessing_forkserver using -R 3:3 takes longer than 3 minutes on my laptop! And the answer is already know, see the bpo ;-) FYI, apart of the bpo-30775, all other reference leaks now seem to be fixed on 2.7, 3.5, 3.6 and master branches! Tested on Windows and Linux. Victor ___ 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/eric%2Ba-python-dev%40trueblade.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] New work-in-progress bisection tool for the Python test suite (in regrtest)
On 6/27/2017 8:39 PM, Victor Stinner wrote: 2017-06-27 7:33 GMT+02:00 Serhiy Storchaka : You could make it just a submodule in the test package. ./python -m test.bisect -R 3:3 test_os I like the idea :-) I proposed a PR which was approved by Yury Selivanov, and so I just merged it! It means that you can now play with "./python -m test.bisect" in the master branch. Enjoy ;-) Example: ./python -m test.bisect -R 3:3 test_multiprocessing_forkserver This command should give you the name of the two failing test methods which are the last known reference leaks! => http://bugs.python.org/issue30775 This specific bisection is very slow since running the 286 tests of test_multiprocessing_forkserver using -R 3:3 takes longer than 3 minutes on my laptop! And the answer is already know, see the bpo ;-) FYI, apart of the bpo-30775, all other reference leaks now seem to be fixed on 2.7, 3.5, 3.6 and master branches! Tested on Windows and Linux. Are you testing for refleaks with gui enabled? A few weeks ago I discovered that some had crept in IDLE, but the gui-less leak tests never saw them. I fixed the ones that existed then, but as I add tests, it will be easy enough to add more leaks. Can test.bisect run a test module in idlelib.idle_test? Unittest.main will, but as far as I know, it does not run leak tests. Test.regrtest has a leak test, but will not modules in other directories, at least not that one. I wrote a custom script to narrow a leak in test.test_idle to one or more files in idlelib.idle_test, but from then on it was manual work, commenting out parts of the file until I identified the test function or functions. One of the things I had to do is test setUpClass and tearDownClass by themselves by commenting out all test_xyz functions and inserting test_dummy(self): pass. -- Terry Jan Reedy ___ 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] New work-in-progress bisection tool for the Python test suite (in regrtest)
On Tue, Jun 27, 2017 at 11:52 PM, Terry Reedy wrote: > Are you testing for refleaks with gui enabled? Yes; the refleak builders are running on my Gentoo and Windows workers, both of which (should have, at least) GUI available and enabled. However, I have caught Xvfb not running properly on the Gentoo bot a time or two, so there may be occasional outages in that coverage. -- Zach ___ 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
