Mailman 3 September 2016 - python-committers

autoconf 2.70
by Xavier de Gaye Nov. 24, 2016

Nov. 24, 2016

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

Greeting from INADA Naoki
by INADA Naoki Sept. 30, 2016

Sept. 30, 2016

Hi, all. Thank you, Yury and all for approve me. I'll focus on polishing dict implementation, and getting familiar with workflow until 3.6. Self-introduction: * Github account name is methane * Maintainer of Japanese translation of Python document (http://docs.python.jp ) * Maintainer of two common MySQL driver: mysqlclient (successor of MySQL-python) and PyMySQL; And serialization library: msgpack-python. * My skills are network application programming on Linux, C, and Go. * I'm not fluent in English. I'm not good at writing documentation and joining long discussion. I want to contribute in C and Python code. * My interest is performance, efficiency, and simplicity. Regards, -- INADA Naoki <songofacandy(a)gmail.com>

10 10

IMPORTANT: An extra week until 3.6.0b2, now 2016-10-10
by Ned Deily Sept. 30, 2016

Sept. 30, 2016

Thanks for all of your efforts in getting us to the beta phase of 3.6.0! A large number of important features and a huge amount of code were committed just prior to the b1 feature freeze 3 weekends ago. Not surprisingly, there were a number of bugs found and loose ends identified and, as a result, we've negotiated some extensions to get things in before b2. Under the current schedule there were only 3 weeks between b1 and b2 and then 4 weeks between b2 and b3; that was mainly because we pushed b1 back a week due to the development sprint. I would *really* like for us to get those remaining pieces which were granted extensions into b2 as planned. The longer they are delayed, the more risk it puts on the final steps of the release and it's really important to have a stable base for our testing efforts and those of our downstream users, like third-party developers and distributors. So I think it makes sense to move b2 back a week, giving us all an extra week to get things in for b2. Without changing the date for b3, we will now have 4 weeks between b1 and b2 and 3 weeks between b2 and b3. That gives us about 10 days from now until b2. It would be great if you can update the issue tracker for any exempted items you have. I will try to followup with you, as needed, over the next few days on their status. Please contact me if you have any questions about the 3.6.0 schedule or about whether a change is appropriate for the beta phase. To recap, the remaining milestones for 3.6.0: 2016-10-10, 1200 UTC: 3.6.0 beta 2 (was 10-03, remaining exempted features, bug and doc fixes) 2016-10-31: 3.6.0 beta 3 (bug and doc fixes) 2016-11-21: 3.6.0 beta 4 (important bug fixes and doc fixes) 2016-12-05 3.6.0 release candidate 1 (3.6.0 code freeze, critical bug fixes, doc fixes) 2016-12-16 3.6.0 release (3.6.0rc1 plus any necessary emergency fixes) Thank you all again for your great efforts so far on 3.6! --Ned https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad(a)python.org -- []

1 0

commit privileges for INADA Naoki
by Yury Selivanov Sept. 26, 2016

Sept. 26, 2016

Hi, I want to propose to give commit privileges to INADA Naoki. He's the guy behind compact dict implementation for CPython 3.6, which was a super complex patch. He also participated in many asyncio related discussions/PRs, on python-ideas and bug tracker. He's quite interested in becoming a core developer. I can volunteer to help/mentor INADA until he's comfortable with our processes. Thanks, Yury

7 10

[RELEASE] Python 3.6.0b1 is now available
by Ned Deily Sept. 15, 2016

Sept. 15, 2016

On behalf of the Python development community and the Python 3.6 release team, I'm happy to announce the availability of Python 3.6.0b1. 3.6.0b1 is the first of four planned beta releases of Python 3.6, the next major release of Python, and marks the end of the feature development phase for 3.6. 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.0b1 here: https://www.python.org/downloads/release/python-360b1/ 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 planned release of Python 3.6 will be 3.6.0b2, currently scheduled for 2016-10-03. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad(a)python.org -- []

4 4

3.6.0 Beta Phase Development
by Ned Deily Sept. 13, 2016

Sept. 13, 2016

Wow! What a busy and productive couple of weeks it has been leading up to 3.6.0b1 and feature code freeze! Congratulations and thanks to all of you who've contributed to the amazing number of PEPs, features, bug fixes, and doc changes that have gone into 3.6.0b1! Now that feature development for 3.6 is over, the challenge is to put the finishing touches on the features and documentation, squash bugs, and test test test. The next preview release will be 3.6.0b2 scheduled for 2016-10-03. In the cpython repo, there is now a 3.6 branch. Starting now, all changes for 3.6.0 should get pushed to the 3.6 branch and then merged to default for 3.7. New features nay continue to be pushed to the default branch for release in 3.7; no new features are now permitted in 3.6 (unless you have contacted me and we have agreed on an extension). Bug fixes appropriate for 3.5.x should get pushed to the 3.5 branch and then merged to 3.6 and then to default. I've updated the Developer's Guide to reflect the now current workflow. Let me know if you find any bugs in it. Likewise, please contact me if you have any questions about the workflow or about whether a change is appropriate for 3.6 beta. To recap: 2016-09-12 3.6 branch open for 3.6.0; 3.7.0 feature development begins 2016-09-12 to 2016-12-04: 3.6.0 beta phase (no new features) - push code for 3.6.0 (bug/regression/doc fixes) to the new 3.6 branch - push code for new features to the default branch for release in 3.7 2016-10-03: 3.6.0 beta 2 2016-12-04 3.6.0 release candidate 1 (3.6.0 code freeze) 2016-12-16 3.6.0 release (3.6.0rc1 plus, if necessary, any dire emergency fixes) 2018-06 3.7.0 release (3.6.0 release + 18 months, details TBD) Thank you all again for your great efforts so far on 3.6! --Ned http://cpython-devguide.readthedocs.io/en/latest/ https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad(a)python.org -- []

2 1

FYI - 3.6.0 is freezing now, stand by for 3.6.0b1
by Ned Deily Sept. 12, 2016

Sept. 12, 2016

Just a heads up that I'm about to start the tag of 3.6.0b1. Given the large amount of code that has gone in recently, there may be a few bumps plus we'll be creating the 3.6 branch so this might be a good time to take a break and hold off on major checkins until the tag is pushed into the main repo. Many, many thanks for everyone's contributions leading up to this including a lot of last-minute effort in getting the buildbots green! -- Ned Deily nad(a)python.org -- []

1 0

IMPORTANT: 3.6.0b1 and feature code cutoff 2016-09-12 12:00 UTC
by Ned Deily Sept. 8, 2016

Sept. 8, 2016

Happy end of summer (northern hemisphere) or winter (southern)! Along with the changing of the seasons, the time has come to finish feature development for Python 3.6. As previously announced, this coming Monday marks the end of the alpha phase of the release cycle and the beginning of the beta phase. Up through the alpha phase, there has been unrestricted feature development phase; that ends as of beta 1. All feature code for 3.6.0 must be checked in by the b1 cutoff on Monday (unless you have contacted me and we have agreed on an extension). As was done during the 3.5 release cycle, we will create the 3.6 branch at b1 time. During the beta phase, the emphasis is on fixes for new features, fixes for all categories of bugs and regressions, and documentation fixes/updates. I will send out specific information for core committers next week after the creation of the b1 tag and the 3.6 branch. 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 will be 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. 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. To recap: 2016-09-12 ~12:00 UTC: code snapshot for 3.6.0 beta 1 (feature code freeze, no new features) 2016-09-12 3.6 branch opens for 3.6.0; 3.7.0 feature development begins 2016-09-12 to 2016-12-04: 3.6.0 beta phase (bug, regression, and doc fixes, no new features) 2016-12-04 3.6.0 release candidate 1 (3.6.0 code freeze) 2016-12-16 3.6.0 release (3.6.0rc1 plus, if necessary, any dire emergency fixes) 2018-06 3.7.0 release (3.6.0 release + 18 months, details TBD) Thank you all for your great efforts so far on 3.6; it should be a great release! --Ned https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad(a)python.org -- []

1 0