Mailman 3 November 2016 - python-committers

autoconf 2.70
by Xavier de Gaye 24 Nov '16

24 Nov '16

It seems that the configure file on the default branch has been generated with autoconf 2.70. Autoconf 2.70 has not yet been released [1]. The differences between the generated configure files with 2.69 and 2.70 are a few lines [3] added by 2.70 with 'runstatedir' in them. The last old discussion on the usage of different autoconf versions [2] does not really answer the following question: I am using 2.69, should a commit that changes configure.ac respects the existing 'runstatedir' lines added by a previous commit or uses directly the configure file generated by 2.69 ? Xavier [1] http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/16193 [2] http://thread.gmane.org/gmane.comp.python.devel/135327 [3] diff -r fe168c2b5e95 configure --- a/configure Wed Jul 06 23:58:16 2016 -0700 +++ b/configure Fri Jul 22 14:49:31 2016 +0200 @@ -777,7 +777,6 @@ docdir oldincludedir includedir -runstatedir localstatedir sharedstatedir sysconfdir @@ -888,7 +887,6 @@ sysconfdir='${prefix}/etc' sharedstatedir='${prefix}/com' localstatedir='${prefix}/var' -runstatedir='${localstatedir}/run' includedir='${prefix}/include' oldincludedir='/usr/include' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' @@ -1141,15 +1139,6 @@ | -silent | --silent | --silen | --sile | --sil) silent=yes ;; - -runstatedir | --runstatedir | --runstatedi | --runstated \ - | --runstate | --runstat | --runsta | --runst | --runs \ - | --run | --ru | --r) - ac_prev=runstatedir ;; - -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \ - | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \ - | --run=* | --ru=* | --r=*) - runstatedir=$ac_optarg ;; - -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb) ac_prev=sbindir ;; -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ @@ -1287,7 +1276,7 @@ for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \ datadir sysconfdir sharedstatedir localstatedir includedir \ oldincludedir docdir infodir htmldir dvidir pdfdir psdir \ - libdir localedir mandir runstatedir + libdir localedir mandir do eval ac_val=\$$ac_var # Remove trailing slashes. @@ -1440,7 +1429,6 @@ --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] - --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include]

10 19

[RELEASE] Python 3.6.0b4 is now available
by Ned Deily 23 Nov '16

23 Nov '16

On behalf of the Python development community and the Python 3.6 release team, I'm pleased to announce the availability of Python 3.6.0b4. 3.6.0b4 is the last planned beta release of Python 3.6, the next major release of Python. Among the new major new features in Python 3.6 are: * PEP 468 - Preserving the order of **kwargs in a function * PEP 487 - Simpler customization of class creation * PEP 495 - Local Time Disambiguation * PEP 498 - Literal String Formatting * PEP 506 - Adding A Secrets Module To The Standard Library * PEP 509 - Add a private version to dict * PEP 515 - Underscores in Numeric Literals * PEP 519 - Adding a file system path protocol * PEP 520 - Preserving Class Attribute Definition Order * PEP 523 - Adding a frame evaluation API to CPython * PEP 524 - Make os.urandom() blocking on Linux (during system startup) * PEP 525 - Asynchronous Generators (provisional) * PEP 526 - Syntax for Variable Annotations (provisional) * PEP 528 - Change Windows console encoding to UTF-8 * PEP 529 - Change Windows filesystem encoding to UTF-8 * PEP 530 - Asynchronous Comprehensions Please see "What’s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.0b4 here: https://www.python.org/downloads/release/python-360b4/ Beta releases are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.6 during the beta phase and report issues found to bugs.python.org as soon as possible. While the release is feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2016-12-05). Our goal is have no changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.6 as possible during the beta phase. Please keep in mind that this is a preview release and its use is not recommended for production environments The next pre-release of Python 3.6 will be 3.6.0rc1, the release candidate, currently scheduled for 2016-12-05. The official release of Python 3.6.0 is currently scheduled for 2016-12-16. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad(a)python.org -- []

8 13

New core developer: Xiang Zhang
by Victor Stinner 22 Nov '16

22 Nov '16

Hi, We have a new core developer today, Xiang Zhang! He comes from China and is already very active in various area of the CPython soure code. He just got his commit bit. * commit bit: Brett added Xiang's key. Xiang already pushed a test commit, https://hg.python.org/test/rev/530f0afa8072 * python-committers: he subscribed to python-committers. Can someone check if you got it (and approve it)? His email adddress is angwerzx(a)126.com * devguide: I just added him, https://github.com/python/devguide/commit/15eca42e59e132094f34dad58f778bb48… I will mentor Xiang for one month. I asked him to send me an email before pushing anything. After the first month, we will if it's worth it to continue mentoring or not. Welcome aboard Xiang! Victor

4 3

IMPORTANT: 3.6.0b4 snapshot today, workflow changes for the final weeks of 3.6.0
by Ned Deily 21 Nov '16

21 Nov '16

The final beta snapshot planned for the 3.6 release cycle is scheduled to be tagged today within the next 12 hours. We then begin the Release Candidate stage, the final days leading up to 3.6.0, with the release candidate scheduled to be tagged in about 2 weeks. As I have noted previously, with the tagging today and release of beta 4, *all* non-critical bug fixes for 3.6.0 should now have been checked in. From the b4 tag on, *only* release critical and doc fixes should be pushed for the release candidate. A reminder from the Developer's Guide regarding the Release Candidate stage of the release cycle: "A branch preparing for an RC release can only have bugfixes applied that have been reviewed by other core developers. Generally, these issues must be severe enough (e.g. crashes) that they deserve fixing before the final release. All other issues should be deferred to the next development cycle, since stability is the strongest concern at this point. You cannot skip the peer review during an RC, no matter how small! Even if it is a simple copy-and-paste change, everything requires peer review from a core developer." A goal for this release has been to have no changes between the release candidate and the final release other than the tag itself. Remember that every time we make a change at this point, it puts a burden on and adds risk to our testing efforts and, more importantly, the efforts of our third-party package developers, downstream distributors, and end users helping us ensure that 3.6.0 will be a high-quality release. I think everyone has been doing a great job so far in exercising good judgement about what is appropriate at each stage of our release cycle. Thank you! Now, after b4, unless a code change addresses a truly release critical issue, please target bug fixes for 3.6.1 and, of course, continue to target new features for 3.7. This raises the issue of what process to follow for changes to the 3.6 branch following the b4 tag and up to the final 3.6.0 release. During the last feature release cycle (3.5.0), we tried something a little bit different: having a 3.5 branch open during the beta phase and then using a special Bitbucket repo with pull requests for changes in the release candidate phase. This was intended to ease the burden on us release managers trying to cherry pick a set of fixes into the RC and/or final releases while allowing the 3.5 branch to remain open to everyone for 3.5.1 changes. My sense is that, while we all appreciated keeping the branch open for bug fixes, many of us were new to the Bitbucket PR process and found it more confusing than expected. So for 3.6.0, I am trying to avoid going down that route. But I do need your help. First, throughout the release cycle I have tried to set expectations that the release candidate will be exactly what it says, a candidate for final release, and thus there should be at most a *very* small number of release critical fixes and final doc updates going in after b4 and with the goal of no changes after rc1. Second, by keeping the rc phase changes to a minimum, I have also tried to keep the release candidate phase shorter so that we all can move on to focus on the next feature release and on maintenance releases for 3.6 (schedules for both will be proposed soon). Also, 3.6.0 is the last feature release cycle using our current development workflow. Sometime after the 3.6.0 release, we will be phasing in our revised development workflow (thanks to Brett and crew!) and with it will come the opportunity for greater flexibility throughout the release cycle, with new tools like pull requests workflows and continuous integration testing. So I don't think it makes sense to spend a lot of time tweaking our current process just for the final weeks of one release. Therefore, what I am planning to do and asking you to do is: 1. Sometime after 1800 UTC today when we are ready to start the 3.6.0b4 tagging and release manufacturing process, I will send an email announcement. 2. Following that b4 tag notification and until rc1 is tagged on 2016-12-05 (in about two weeks), the 3.6 branch will *temporarily* be open only for fixes appropriate for 3.6.0, e.g. reviewed release critical items and final doc changes. Don't forget to mark such items as "release blocker" in the bug tracker. 3. Hold off pushing changes that are not 3.6.0 release critical until after rc1 is tagged. You can continue to push bug fixes as appropriate to other open branches if you are willing to back port them to the 3.6 branch, as necessary, after rc1 is tagged. Or, if you prefer to follow the normal development flow, take a bugfix holiday for the next two weeks and just hold off pushing any changes that affect 3.6.1 until after rc1 is tagged. With those (hopefully) small inconveniences to you, we won't have to go through a special Bitbucket PR process and it will ensure that our 3.6 buildbots continue to test what's going into 3.6.0. 4. Once rc1 is tagged, the 3.6 branch will again be open for the usual maintenance-release-appropriate changes destined for 3.6.1. Any emergency fixes that might arise after rc1 and prior to 3.6.0 will be approved and merged from the 3.6 branch into the 3.6.0 release by me. I'm really hoping we won't have to do that! I hope that you find the process for the few remaining weeks leading up to the 3.6.0 release to not be too burdensome. Please contact me if you have any questions about the 3.6.0 schedule or about whether a change is appropriate at this point in the 3.6.0 cycle. To recap, the remaining milestones for 3.6.0: 2016-11-21, ~1800 UTC: 3.6.0 beta 4 (important bug fixes and doc fixes) 2016-11-21 to 2016-12-05: 3.6 branch open *only* for 3.6.0 release critical and doc fixes 2016-12-05 (2 weeks from now) 3.6.0 release candidate 1 (3.6.0 code freeze, release critical bug fixes, doc fixes; 3.6 branch reopens for 3.6.1) 2016-12-16 3.6.0 release (3.6.0rc1 plus any necessary emergency fixes) Thank you all again for your efforts so far on 3.6. Beethoven and I are looking forward to celebrating 3.6.0 on 12-16! --Ned http://cpython-devguide.readthedocs.io/en/latest/devcycle.html#release-cand… https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad(a)python.org -- []

1 1

Promote Xiang Zhang as a core developer
by Victor Stinner 21 Nov '16

21 Nov '16

Hi, Last months, I noticed that Xiang Zhang is very active on the bug tracker and propose many enhancements and bug fixes. He contributes to Python code, but also to the C code (a rare skill nowadays). Slowly, he understood how to produce "good" patches, the CPython workflow, etc. I think that his contributions are now good enough to give him the commit bit. As I did previously (for Xavier), I also propose to be his mentor the first month: request him to ask me before pushing anything, help him with Mercurial, branches, etc. So I can help to avoid simple mistakes and to not break the buildbot too often :-) Maybe Serhiy Storchaka and/or Yury Selivanov may want to co-mentor Xiang? Serhiy reviewed many of Xiang's patches recently. Victor

9 16

Temporary moderator needed for Distutils SIG
by A.M. Kuchling 12 Nov '16

12 Nov '16

I'm going on vacation starting this Tuesday November 15th, and won't have much Internet access, and perhaps none at all, until I get back on November 30th. Could someone please take over moderating the Distutils-SIG mailing list? There's enough moderated traffic (list messages, spam, misdirected help requests) that it can't be left If you want to volunteer, please send me your e-mail address and then I'll e-mail you an admin password privately. You can either stay on as a moderator once I get back, or I can remove you. I'm also moderator for a few other lists that are largely inactive such as medusa-dev and psf-redesign; the only mail that arrives is spam, and spam can just sit for two weeks until I delete it, so we don't need to bother about them. (I couldn't think of a better place to ask for help; the Meta-SIG seems largely inactive, so I ruled it out.) --amk

2 2

daily reference leaks
by Yury Selivanov 08 Nov '16

08 Nov '16

Does anyone know where's "daily reference leaks"? Last email was sent on Sun Jul 10 05:57:30 EDT 2016. Just today I found two memory leaks in 3.6, it might be many more that we don't know about. Yury

2 2

[RELEASE] Python 3.6.0b3 is now available
by Ned Deily 31 Oct '16

31 Oct '16

On behalf of the Python development community and the Python 3.6 release team, I'm pleased to announce the availability of Python 3.6.0b3. 3.6.0b3 is the third of four planned beta releases of Python 3.6, the next major release of Python. Among the new major new features in Python 3.6 are: * PEP 468 - Preserving the order of **kwargs in a function * PEP 487 - Simpler customization of class creation * PEP 495 - Local Time Disambiguation * PEP 498 - Literal String Formatting * PEP 506 - Adding A Secrets Module To The Standard Library * PEP 509 - Add a private version to dict * PEP 515 - Underscores in Numeric Literals * PEP 519 - Adding a file system path protocol * PEP 520 - Preserving Class Attribute Definition Order * PEP 523 - Adding a frame evaluation API to CPython * PEP 524 - Make os.urandom() blocking on Linux (during system startup) * PEP 525 - Asynchronous Generators (provisional) * PEP 526 - Syntax for Variable Annotations (provisional) * PEP 528 - Change Windows console encoding to UTF-8 (provisional) * PEP 529 - Change Windows filesystem encoding to UTF-8 (provisional) * PEP 530 - Asynchronous Comprehensions Please see "What’s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.0b3 here: https://www.python.org/downloads/release/python-360b3/ Beta releases are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.6 during the beta phase and report issues found to bugs.python.org as soon as possible. While the release is feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2016-12-05). Our goal is have no changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.6 as possible during the beta phase. Please keep in mind that this is a preview release and its use is not recommended for production environments The next pre-release of Python 3.6 will be 3.6.0b4, currently scheduled for 2016-11-21. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad(a)python.org -- []

1 0