Mailman 3 May 2015 - python-committers

Python 3.5 schedule addendum adding a new Python 3.5.0 beta, this weekend
by Larry Hastings May 29, 2015

May 29, 2015

On behalf of the Python 3.5 release team: Due to a particularly bad bug ( http://bugs.python.org/issue24285 ), we're going to issue a new beta of Python 3.5 this weekend. This will not change the rest of the schedule; it'll just bump the remaining beta numbers up by 1. Thus the schedule is now as follows: - 3.5.0 beta 1: May 24, 2015 - 3.5.0 beta 2: May 31, 2015 - 3.5.0 beta 3: July 5, 2015 - 3.5.0 beta 4: July 26, 2015 - 3.5.0 candidate 1: August 9, 2015 - 3.5.0 candidate 2: August 23, 2015 - 3.5.0 candidate 3: September 6, 2015 - 3.5.0 final: September 13, 2015 May you live in interesting times, //arry/

1 0

docs.python.org broken for 3.5
by Yury Selivanov May 28, 2015

May 28, 2015

Hi, docs.python.org is kind of broken for 3.5. For instance, "what's new in 3.5" link points now to a missing whatsnew for 3.6 (which gives us 404 error). Version switcher extension should also be updated in 2.7, 3.4, 3.5, and 3.6 branches. I think I could fix that all myself, but I don't have access to the docs server. Yury

1 1

Re: [python-committers] [Python-Dev] Preserving the definition order of class namespaces.
by Larry Hastings May 26, 2015

May 26, 2015

On 05/25/2015 03:22 PM, Eric Snow wrote: > On Mon, May 25, 2015 at 2:40 PM, Terry Reedy <tjreedy(a)udel.edu> wrote: >> On 5/25/2015 3:40 PM, Eric Snow wrote: >>> Since Larry already gave an exception, >> Conditional on 'general approval of the community'. > Unless I misunderstood him, Larry gave me an unconditional exception > for OrderedDict itself (as long as it is in before beta 2.) For the record I've granted three exceptions to the beta 1 feature freeze (so far): * Raymond asked for one (a couple weeks ago!) for adding slice support to collections.deque. He knew he wouldn't have time to finish it before beta 1. * Serhiy asked for one very-last-minute for a C reimplementation of lru_cache. He checked it in about a half-hour before feature freeze and it made all the buildbots fail. (The ones that weren't already failing, that is.) * Eric asked for one for this C reimplementation of OrderedDict; the coding was done, the debugging wasn't. And yes, as Eric said, I made separate pronouncements. I said COrderedDict could go in as long as it was in before beta 2; "the other work" of __definition_order__ and switching type_prepare and __build_class__ to using ordered dicts I made conditional on "general approval of the community." The latter has already been tabled for now. So, in all three cases it's work that's been under development for a while. These people did this work out of the kindness of their hearts, to make Python better. As a community we want to encourage that and make sure these developers know we appreciate their efforts. These people would be happier if the work shipped in 3.5 as opposed to 3.6 so it got into user's hands sooner. Also, in Serhiy and Eric's cases, these are reimplementations of existing Python libraries in C. On the one hand, that means we should have good regression test coverage in the library--which it seems like we do, as both of them are debugging problems uncovered by the regression tests. This gives us a little more confidence that the work is good. On the other hand, it does mean there's a higher chance of destabilization, as there's already an installed base using these libraries. (As opposed to something new like math.isclose which has no installed base.) So yes this could introduce bugs that will impact existing users. Bottom line: while an important part job of my job is saying "no", I also feel like an important part of my job is saying "yes". On balance, what will be best for Python? In these cases, I think "yes" is better. My feeling is, let's check it in (before beta 2), and if it causes problems during the betas / rcs we can back them out. //arry/

2 1

Reminder: 3.5 now has its own branch! "default" branch is now 3.6!
by Larry Hastings May 26, 2015

May 26, 2015

I've now pushed the 3.5.0 beta 1 release-engineering checkins to hg.python.org. At the same time I did this, I also created the 3.5 branch. Quick FAQ: Q: Where should I check in bugfixes for 3.5? A: In the "3.5" branch. You should also merge them forward into "default". Q: Where should I check in new features for 3.5? A: You sillyhead! New features aren't allowed for 3.5 anymore, it's in feature freeze. Q: What is "default" now? A: "default" is now 3.6. Meaning, you can now start on new features for 3.6! You don't have to wait until 3.5 final is released, like how we used to do it. Q: What's all this about bitbucket and push requests? A: We don't start doing that until 3.5.0 release candidate 1. Don't worry about it for now. When the time comes, I'll post instructions here and to the devguide. A new day is dawning, //arry/

3 4

Re: [python-committers] [Python-Dev] Reminder: 3.5 now has its own branch! "default" branch is now 3.6!
by Larry Hastings May 25, 2015

May 25, 2015

On 05/24/2015 06:01 PM, Chris Angelico wrote: > Additional Q. What does this mean for buildbots? Will they immediately > pick up the new branch? I don't know about "immediately", but yes the buildbots should get configured to point at the 3.5 branch, preferably soon. //arry/

1 0

[RELEASED] Python 3.5.0b1 is now available
by Larry Hastings May 24, 2015

May 24, 2015

On behalf of the Python development community and the Python 3.5 release team, I'm pleased to announce the availability of Python 3.5.0b1. Python 3.5 has now entered "feature freeze". By default new features may no longer be added to Python 3.5. (However, there are a handful of features that weren't quite ready for Python 3.5.0 beta 1; these were granted exceptions to the freeze, and are scheduled to be added before beta 2.) This is a preview release, and its use is not recommended for production settings. Three important notes for Windows users about Python 3.5.0b1: * If you have previously installed Python 3.5.0a1, you may need to manually uninstall it before installing Python 3.5.0b1 (issue23612). * If installing Python 3.5.0b1 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. * There is now a third type of Windows build for Python 3.5. In addition to the conventional installer and the web-based installer, Python 3.5 now has an embeddable release designed to be deployed as part of a larger application's installer for apps using or extending Python. During the 3.5 alpha releases, this was an executable installer; as of 3.5.0 beta 1 the embeddable build of Python is now shipped in a zip file. You can find Python 3.5.0b1 here: https://www.python.org/downloads/release/python-350b1/ Happy hacking, //arry/

1 0

Re: [python-committers] [Python-Dev] Reminder: Python 3.5 beta 1 will be tagged tomorrow
by Berker Peksağ May 24, 2015

May 24, 2015

On Sat, May 23, 2015 at 12:53 AM, Chris Barker <chris.barker(a)noaa.gov> wrote: > On Fri, May 22, 2015 at 2:33 PM, Larry Hastings <larry(a)hastings.org> wrote: >> >> On 05/22/2015 02:29 PM, Chris Barker wrote: >> >> Is it too late to get the isclose() code (PEP 485) into 3.5? > > ... >> >> Hopefully you can find a core dev familiar enough with the issues >> involved that they can (quickly!) guide it through the process of getting it >> checked in. > > Ping! Anyone willing to sponsor this? Hi Chris, Thanks for the PEP and the implementation! You'll get more attention If you open an issue with a patch at bugs.python.org. Having a GitHub repository is good, but the isclose() code(with tests and documentation) needs to be integrated into the CPython code base: * The C implementation should be in Modules/mathmodule.c * Tests should be in Lib/test/test_math.py * Documentation should be in Doc/library/math.rst * Add an entry to Doc/whatsnew/3.5.rst * If I remember correctly, we don't need the Python implementation and its tests --Berker

4 4

Can we clean up the buildbots please?
by Larry Hastings May 23, 2015

May 23, 2015

Right now we have eight online buildbots for Python trunk. Of those, currently *six* are reporting errors in either the compile or test phases. http://buildbot.python.org/all/waterfall?category=3.x.stable There's one platform ("AMD64 Snow Leop") where the failures are sporadic "stack overflow" errors encountered during the test suite. But the other five platforms have consistent failures, build after build. Those platforms: AMD64 OpenIndiana AMD64 Windows7 SP1 x86 Windows Server 2003 [SB] x86 Windows7 x86 XP-4 That includes *all* of the Windows buildbots. Gosh, it sure would be nice if Beta 1 didn't fail on Windows, wouldn't it? Could some Windows core devs take a look at the failures and see about cleaning them up? Naturally the OpenIndiana and OS X devs are invited to fix the errors on those platforms too, //arry/ p.s. My apologies for not bringing attention to this sooner. But, well, we still have a day left, right?

4 9

Re: [python-committers] [Python-Dev] Reminder: Python 3.5 beta 1 will be tagged tomorrow
by Larry Hastings May 22, 2015

May 22, 2015

On 05/22/2015 02:29 PM, Chris Barker wrote: > Is it too late to get the isclose() code (PEP 485) into 3.5? > > I posted the code here, and got a tiny bit of review, but have not yet > merged it into the source tree -- and don't know the process for > getting it committed to the official source. > > So -- too late, or should I try to get that merge done soon -- if so, how? Posting your plea here is a good start. Hopefully you can find a core dev familiar enough with the issues involved that they can (quickly!) guide it through the process of getting it checked in. Given that this is a new feature I can live with it being checked in at the last minute, as it shouldn't destabilize the build. Still, I would prefer that it was checked in far enough in advance that you can watch the buildbots ( http://buildbot.python.org/all/waterfall?category=3.x.stable ) and maybe even iterate if the checkin causes problems. //arry/

1 0

How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
by Larry Hastings May 22, 2015

May 22, 2015

Python 3.5 beta 1 is coming up soon. After beta is rc; after rc is 3.5.0 final. During the beta and rc periods the Python developer workflow changes a little--what sorts of checkins are permissible, and how to get something accepted and merged generally becomes more complicated. I was the release manager for Python 3.4, and the way I ran the rc period for 3.4 was miserable. Everyone hated it--and that includes me. I'm absolutely not doing it that way for 3.5. But that leads one to the question: okay, how *am* I going to run it? I have three ideas for workflows for the beta and rc periods for 3.5, below. But first let's talk about what I/we hope to achieve. Traditionally during the beta and rc periods, development of new features stops completely. Obviously, after feature freeze no new features can go into the beta / rc releases. But why can't people develop new features for the *next* release? The reason given is that we're trying to guide the core dev community in the right direction--they should concentrate on fixing bugs in the new release. I suspect the real reason for this is that back in the bad old days of Subversion (and CVS!) branching and merging were painful. This social engineering policy is a justification after-the-fact. But Mercurial makes branching and merging nearly effortless. Mercurial also makes it painless to develop new features in private. So consider: anyone who wants to work on new features during beta and rc can easily do so. All our "no new features during beta and rc" policy really does is drive such development away out of public view. I think it's time we experimented with lifting that policy. The trick is finding a good place for us to check in the work. You see, during the 3.5 rc period, we arguably want to accept checkins for *three* different revisions: 3.5.0 3.5.1 3.6 3.5.1? Yep. During the rc period for 3.4--and particularly after the last rc was tagged--there were a lot of minor fixes that were desirable, but I didn't want to accept into 3.4 just to avoid destabilizing the release. I still wanted those checkins, I just didn't want them in 3.4.0. So the way it worked was, developers would check those bugfixes in to trunk, then I'd cherry-pick the revisions I wanted into the rc branch. In other words, during the rc period for 3.4, trunk effectively represented 3.4.1. This was valuable and I absolutely want to do it again. So here are the workflows. Workflow 0 most resembles what we've done in the past. Workflow 1 is my favorite and the most ambitious. All three give us a public place to put revisions for 3.5.0 and 3.5.1; Workflow 1 also gives us a place to check in work for 3.6 during the beta and rc periods for 3.5. Workflow 2 is a less ambitious compromise. Workflow 0 ========== When I ship beta 1, trunk remains 3.5. When I ship rc 1, trunk becomes 3.5.1. I create a publically visible read-only repo that represents 3.5.0, and any checkins that I want to accept into 3.5.0 I must manually cherry-pick from trunk. When I ship Python 3.5.0 final, we branch 3.5, and trunk becomes 3.6. Workflow 1 ========== When I ship beta 1, we create the 3.5 branch. trunk become 3.6. When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically visible repo /on bitbucket/ for 3.5.0, and we use bitbucket "pull requests" for cherry-picks from 3.5.1 into 3.5.0. This gives us a pilot project to try out a web GUI for merging. It makes my workflow easier, as I can push a button to accept cherry-picks. (If they don't apply cleanly I can tell the author to go fix the conflict and resubmit it.) The downside: it requires core devs to have and use bitbucket accounts. Workflow 2 ========== When I ship beta 1, trunk remains 3.5. When I ship rc 1, we create the 3.5 branch. The 3.5 branch is 3.5.0 and trunk is 3.5.1. Only blessed stuff gets cherry-picked from 3.5.1 back into 3.5.0. What do you think? My votes are as follows: Workflow 0: -0.5 Workflow 1: +1 Workflow 2: +0.5 Please cast your votes, //arry/

11 18