Re: [Python-Dev] Python 2.7 patch levels turning two digit
In article <53a87fb3.2000...@egenix.com>, "M.-A. Lemburg" wrote: [...] > But without access to the VS 2008 compiler that is needed to > compile those extensions, it will become increasingly difficult > for package authors to provide such binary packages, so we have to > ask ourselves: > > What's worse: breaking old Windows binaries for Python 2.7 > or not having updated and new Windows binaries for Python 2.7 > at all in a few years ? > > Switching to a newer compiler will make things easier for everyone > and we'd see more binary packages for Windows again. It does seem like a conundrum. As I have no deep Windows experience to be able to have an appreciation of all of the technical issues involved, I ask out of ignorance: would it be possible and desirable to provide a transition period of n 2.7.x maintenance releases (where n is between 1 and, say, 3) where we would provide 2 sets of Windows installers, one set (32- and 64-bit) with the older compiler and CRT and one with the newer, and campaign to get users and packagers who provide binary extensions to migrate? Would that mitigate the pain, assuming that Steve (or someone else) would be willing to build the additional installers for the transition period? I've done something similar on a smaller scale with the OS X 32-bit installer for 2.7.x but that impact is much less as the audience for that installer is much smaller. -- Ned Deily, n...@acm.org ___ 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] Python 2.7 patch levels turning two digit
In article <14de41e2-5314-4e49-be93-85eeeddde...@stufft.io>, Donald Stufft wrote: > On Jun 23, 2014, at 4:31 PM, Martin v. Lowis wrote: > > >> > >> Would that mitigate the pain, assuming that > >> Steve (or someone else) would be willing to build the additional > >> installers for the transition period? I've done something similar on a > >> smaller scale with the OS X 32-bit installer for 2.7.x but that impact > >> is much less as the audience for that installer is much smaller. > > > > Well, the question really is whether precompiled extension modules > > available from PyPI would work on both compilers. I understand that > > for OSX, you typically don't have precompiled binaries for the extension > > modules, so installation compiles the modules from scratch. This is > > easier, as it can use the ABI of the Python which will be installed > > to. > > > > If you go the "parallel ABIs" route, extension authors have to provide > > two parallel sets of packages as well. Given 32-bit and 64-bit packages, > > this will make actually two additional packages - just as if they had > > to support another Python version. > > As far as I know, stuff on OSX is generally built for "X compiler or later" > so binary compatibility is kept as long as you're using an "or later" but > I could be wrong about that. Using binary packages on OSX is a much > less frequent thing I think though since getting a working compiler toolchain > is easier there. Both points are generally true on OS X so, yes, binary extensions are much less of an issue there. Where binary distributions on OS X are most used, I think, is when there are dependencies on third-party non-Python libraries that are not shipped by Apple with OS X. But, yes, if we were to go down the route of two sets of installers, that could mean two sets of third-party packages. I suppose there could potentially be some pip / wheel / possibly Distutils help by conditioning the platform name or other component used to generate the egg / wheel / and/or bdist file names on the CRT version (or compiler version), much as what we do today with OS X deployment target. Again, I'm speculating in ignorance here. If that were feasible, things built with the old toolchain could have unchanged names. And, clearly, we would want to keep that "n" number of releases with two sets of installers to be as small as possible, like 1. While there would be a certain amount of unavoidable disruption for some folks, others *might* welcome the opportunity to no longer have to keep around old versions of the tool chain, particularly if they now could use the same tool chain to produce binaries for both Py2 and Py3. -- Ned Deily, n...@acm.org ___ 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] Fix Unicode-disabled build of Python 2.7
In article <1403625970.6550.133062453.693ec...@webmail.messagingengine.com>, Benjamin Peterson wrote: > If Serhiy wants to spend his time supporting this arcane feature, he can > do that. It doesn't really seem worth risking regressions to do this, > though. That's why I'm concerned about applying these 20+ patches that touch many parts of the code base. I don't have any objection to the "arcane feature" per se and I appreciate the obvious effort that Serhiy put into the patches but, at this stage of the life of Python 2, our overriding concern should be stability. That's really why most users of Python 2.7 continue to use it. As I see it, maintenance mode is a promise from us to our users that we will try our best, in general, to only make changes that fix serious problems, either due to bugs in Python itself or changes in the external world (new OS releases, etc). We don't automatically fix all bugs. Any time we make a change, we're making an engineering decision with cost-benefit tradeoffs. The more lines of code changed, the greater the risk that we introduce new bugs; inadvertently adding regressions has been an issue over a number of the 2.7.x releases, including the most recent one. The cost-benefit of this set of changes seems to me to be: Costs: - Code changes in many modules: - careful review -> additional work for multiple core developers - careful testing on all platforms including this option that we don't currently test at all, AFAIK -> added work for platform experts - risk of regressions not caught prior to release, at worst requiring another early followup release -> added work for release team, third-party packagers, users - possibly making backporting of other issues more difficult due to merge conflicts - possible invalidation of waiting-for-review patches forcing patch refreshes and retests -> added work for potential contributors - possible invalidation of user local patches -> added work for users - may encourage use of an apparently little-used feature that has no equivalent in Python 3, another incentive to stay with Py2? Benefit: - Fixes documented feature that may be of benefit to users of Python in applications with very limited memory available, although there aren't any open issues from users requesting this (AFAIK). No benefit to the overwhelming majority of Python users, who only use Unicode-enabled builds. That just doesn't seem like a good trade-off to me. I'll certainly abide by the release manager's decision but I think we all need to be thinking more about these kinds of cost-benefit tradeoffs and recognize that there are often non-obvious costs of making changes, costs that can affect our entire community. Yes, we are committed to maintaining Python 2.7 for multiple years but that doesn't mean we have to fix every open issue or even most open issues. Any or all of the above costs may apply to any changes we make. For many of our users, the best maintenance policy for Python 2.7 would be the least change possible. -- Ned Deily, n...@acm.org ___ 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] cpython (3.3): Closes #20872: dbm/gdbm/ndbm close methods are not documented
In article <3gz1lk1lykz7...@mail.python.org>, jesus.cea wrote: > http://hg.python.org/cpython/rev/cf156cfb12e7 > changeset: 91398:cf156cfb12e7 > branch: 3.3 > parent: 91384:92d691c3ca00 > user:Jesus Cea > date:Wed Jun 25 13:05:31 2014 +0200 > summary: > Closes #20872: dbm/gdbm/ndbm close methods are not documented The 3.3 branch is open only to security fixes. Please don't backport other patches to there. https://docs.python.org/devguide/devcycle.html#summary -- Ned Deily, n...@acm.org ___ 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] cpython (3.3): Closes #20872: dbm/gdbm/ndbm close methods are not documented
In article <53ab53a7.6050...@jcea.es>, Jesus Cea wrote: > On 25/06/14 20:35, Ned Deily wrote: > > The 3.3 branch is open only to security fixes. Please don't backport > > other patches to there. > > > > https://docs.python.org/devguide/devcycle.html#summary > > Ned, I am aware. It is a doc-only fix, like fixing a typo or correcting > an incorrect statement. It that is against policy, let me know. My understanding is that doc changes are treated the same as any other code changes. As you noticed, after a release leaves maintenance mode, its documentation is no longer updated on the web site. -- Ned Deily, n...@acm.org ___ 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] buildbot.python.org down?
The buildbot web site seems to have been down for some hours and still is as of 0915 UTC. I'm not sure who is watching over it but I'll ping the infrastructure team as well. -- Ned Deily, n...@acm.org ___ 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] buildbot.python.org down again?
As of the moment, buildbot.python.org seems to be down again. Where is the best place to report problems like this? -- Ned Deily, n...@acm.org ___ 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] buildbot.python.org down again?
In article <62321d60-1197-47a5-b455-6e5200dd5...@stufft.io>, Donald Stufft wrote: > On Jul 8, 2014, at 12:58 AM, Nick Coghlan wrote: > > On 7 Jul 2014 10:47, "Guido van Rossum" wrote: > > > It would still be nice to know who "the appropriate persons" are. Too > > > much of our infrastructure seems to be maintained by house elves or the > > > ITA. > > I volunteered to be the board's liaison to the infrastructure team, and > > getting more visibility around what the infrastructure *is* and how it's > > monitored and supported is going to be part of that. That will serve a > > couple of key purposes: > > - making the points of escalation clearer if anything breaks or needs > > improvement (although "infrastruct...@python.org" is a good default choice) > > - making the current "todo" list of the infrastructure team more visible > > (both to calibrate resolution time expectations and to provide potential > > contributors an idea of what's involved) > > Noah has already set up http://status.python.org/ to track service status, > > I can see about getting buildbot.python.org added to the list. > We (the infrastructure team) were actually looking earlier about > buildbot.python.org and we're not entirely sure who "owns" > buildbot.python.org. > Unfortunately a lot of the *.python.org services are in a similar state where > there is no clear owner. Generally we've not wanted to just step in and take > over for fear of stepping on someones toes but it appears that perhaps > buildbot.p.o has no owner? In parallel to this discussion, I ran into Noah at a meeting the other day and we talked a bit about buildbot.python.org. As Donald noted, it sounds like he and the infrastructure team are willing to add it to the list of machines they monitor and reboot, as long as they wouldn't be expected to administer the buildbot master itself. I checked with Antoine and Martin and they are agreeable with that. So I think there is general agreement that the infrastructure team can take on uptime monitoring and rebooting of buildbot.python.org and that Antoine/Martin would be the primary/secondary contacts/owners for other administrative issues. Martin would also be happy if the infrastructure team could handle installing routine security fixes as well. I'll leave it to the interested parties to discuss it further among themselves. -- Ned Deily, n...@acm.org ___ 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] PEP 477: selected ensurepip backports for Python 2.7
In article , Nick Coghlan wrote: > On 1 Sep 2014 09:23, "Benjamin Peterson" wrote: > > On Sun, Aug 31, 2014, at 16:17, Antoine Pitrou wrote: > > > On Mon, 1 Sep 2014 08:00:14 +1000 > > > Nick Coghlan wrote: > > > > > > > > That part of the proposal proved to be controversial, so we dropped > it from > > > > the original PEP in order to focus on meeting the Python 3.4 specific > > > > release deadlines. This also had the benefit of working out the kinks > in > > > > the bootstrapping processing as part of the Python 3.4 release cycle. > > > > > > > > However, we still think we should start providing pip by default to > Python > > > > 2.7 users as well, at least as part of the Windows and Mac OS X > installers. A much bigger than average +1 > > > I don't agree with this. pip is simply not part of the 2.7 feature set. > > > If you add pip to a bugfix version, then you have bugfix versions which > > > are more featureful than others, which makes things more complicated to > > > explain. > > 2.7.x has been and will be alive for so long that will already have to > > explain that sort thing; i.e. PEP 466 and why different bugfix releases > > support different versions of dependency libraries. And that is a minor complication compared with the confusion and difficulty of trying to explain to users (stuck with 2.7 for the time being) of how to install third-party packages on each platform (especially Windows) versus the simplicity of the 3.4.x story, thanks to ensurepip. Having pip available as a documented, batteries-included tool for all current releases would be a huge usability improvement. > Exactly. LTS is genuinely different from stopping maintenance after the > next feature release - it requires considering the "stability risk" and > "user experience improvement" questions separately. > > In this case, the problem is that the Python 2 platform *is* still > evolving, but the centre of that evolution has moved to PyPI. For "standard > library only" users, Python 2 stopped evolving back in 2010. For PyPI > users, by contrast, it's still evolving at a rapid pace. > > For our Python 3 transition story to be coherent, we need to ensure tools > like six, modernize and future are readily available, while still remaining > free to evolve independently of the standard library. That means providing > a package management utility as easily and as painlessly as possible. > > Embracing pip upstream for Python 2 as well as Python 3 also sends a > powerful signal to redistributors that says "your users are going to need > this" and makes them do additional work to *avoid* providing it. Some of > them *will* choose that path, but that becomes a matter for discussion > between them and their user base, rather than a problem we need to worry > about upstream. FTR, I'm willing to backport the pieces I did for 3.4 and I could do the ensurepip backport, as well. I'll leave the Windows installer changes for someone else, though. -- Ned Deily, n...@acm.org ___ 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] Proposed schedule for 3.4.2
In article <540c521c.7070...@hastings.org>, Larry Hastings wrote: > Matthias asked me when I was going to release 3.4.2. I propose the > following schedule: > > Tag 3.4.2rc1 Friday Sep 12 2014 > Release 3.4.2rc1 Saturday Sep 13 2014 > Tag 3.4.2 final Saturday Sep 27 2014 > Release 3.4.2 final Sunday Sep 28 2014 > > Normally I want to tag on Saturdays and release on Sundays, however I > propose moving rc1 a day earlier because I'll be unavailable that Sunday. > > Any objections? I will interpret silence as tacit approval. As I've already discussed with Larry, I think adding a week to the scheduled dates would be preferable. The original dates give pretty short notice and there are a number of open issues that would be good to resolve now in 3.4.2. -- Ned Deily, n...@acm.org ___ 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] Python 3.4.2rc1 Mac OS X
In article <54217c0d.90...@willingconsulting.com>, Carol Willing wrote: > [...] The new 3.4.2rc1 installer is a *big* improvement. Thanks for the feedback, Carol. Let us know via bugs.python.org of any issues you see. BTW, the new installer format will be coming to Python 2.7.9 as well. -- Ned Deily, n...@acm.org ___ 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] Fixing 2.7.x
In article <5432be77.40...@stoneleaf.us>, Ethan Furman wrote: > With the incredibly long life span of 2.7, which bugs should we *not* fix? > > For example, in http://bugs.python.org/issue22297 I mentioned one reason to > not fix that bug was that the fix was not in > 3.1-3.3, but 2.7 will outlive all those plus a couple more. > > So, what are the current guidelines on what to fix? Is it still security > only, with the rest being carrots for switching? Python release families are in one of four states: 1. in-development feature: the default branch, unreleased = 3.5 2. maintenance: currently released and actively maintained, bug fixes, no compatibility breaks, no new features without very compelling use cases, discussion, and release manager approval. = 2.7.x and 3.4.x 3. security: "fixing issues exploitable by attackers such as crashes, privilege escalation and, optionally, other issues such as denial of service attacks. Any other changes are not considered a security risk and thus not backported to a security branch." = 3.2.x and 3.3.x 4. retired: no fixes of any kind from python-dev = all other releases So 2.7.x is not "security only" and wouldn't reach that stage until 2020 under current policy. http://legacy.python.org/dev/peps/pep-0373/#id5 https://docs.python.org/devguide/devcycle.html#branches -- Ned Deily, n...@acm.org ___ 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] Fixing 2.7.x
In article , Skip Montanaro wrote: > Apparently no other 2.x release qualifies as "security only" at this > point? I would have expected at least 2.6 to fall into that category. 2.6 had its five-year run. "Python 2.6.9 is the final security-only source-only maintenance release of the Python 2.6 series. With its release on October 29, 2013, all official support for Python 2.6 has ended. Python 2.6 is no longer being maintained for any purpose." http://legacy.python.org/dev/peps/pep-0361/ -- Ned Deily, n...@acm.org ___ 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] Fixing 2.7.x
In article , Zachary Ware wrote: > On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote: > > 3. security: "fixing issues exploitable by attackers such as crashes, > > privilege escalation and, optionally, other issues such as denial of > > service attacks. Any other changes are not considered a security risk > > and thus not backported to a security branch." > >= 3.2.x and 3.3.x > 3.1 is still in this category, is it not? According to PEP 375, it's > a few months past due for its last release. > http://legacy.python.org/dev/peps/pep-0375/#maintenance-releases I don't think Benjamin was planning any further security releases. But, in any case, the PEP should be updated, I guess. Benjamin? -- Ned Deily, n...@acm.org ___ 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] [RELEASE] Python 3.4.2 is now available
In article , Geoffrey Spear wrote: > It looks like the Download dropdown on python.org has a blank button > (when accessed from Windows) has an empty button that's supposed to be > for the 3.4.2 release by just links back to the current page; the 2.7 > button is working fine. https://github.com/python/pythondotorg/issues/167 -- Ned Deily, n...@acm.org ___ 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] [python-committers] [RELEASE] Python 3.4.2 is now available
In article , Mark Lawrence wrote: > On 08/10/2014 11:21, Victor Stinner wrote: > > This page redirect me to > > https://www.python.org/download/releases/3.4.1 Maybe some web servers > > of the CDN don't contain the latest version. I guess that the issue > > will quickly disappears. > Further if you navigate from 3.4.1 to 3.4.2 it says "Python 3.4.2rc1 was > released on October 8th, 2014.". The download itself is correct. Those two problems should be gone now. Thanks. -- Ned Deily, n...@acm.org ___ 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] XP buildbot problem cloning from hg.python.org
In article , David Bolen wrote: > David Bolen writes: > > > which appears to die mid-stream while receiving the manifests. > > > > So I'm sort of hoping there might be some record server-side as to why > > things are falling apart mid-way. > > Just to follow-up to myself, I get the same same error trying to do a > clone from my own personal XP machine rather than the buildbot (which > is a VM). I've had the issue with hg 1.6.2, 2.5.2 and 3.1.2. > > However, the same clones completely successfully under OSX and Linux. > > So that's sort of strange. Very interesting! I had been doing some housekeeping on some of my older OS X build systems over the past few days and I've run into the same problem. In particular, I am seeing this failure on an OS X 10.5.8 system (running in a Fusion VM) which I've used for years and from which I have regularly cloned repos from hg.python.org. I spent some time yesterday trying to isolate it. I came to the conclusion that it was independent of the version of OpenSSL (identical failures occurred with the system's ancient Apple 0.9.7 as well as a newly-build 1.0.1j) and independent of the version of hg (at least with two data points, current and a year-old version) and seemingly independent of the network connection. I was not able to reproduce the failure on the host OS X system (10.10) and I didn't have problems a few days earlier with various other OS X releases (10.6.x through 10.9.x) also running in VMs on the same host. I stumbled across a workaround for the problem as I was experiencing it: adding --uncompressed to hg clone eliminated failures. You can get more info on the hg failures by adding --traceback and --debugger to the clone command. After spending way too much time on the issue, I was not in the mood to spend more time isolating the problem after finding a workaround but if others are also seeing it, it might be worth doing. Sigh. $ hg --version Mercurial Distributed SCM (version 3.1.2) $ hg clone -U http://hg.python.org/cpython cpython real URL is https://hg.python.org/cpython requesting all changes adding changesets adding manifests transaction abort! rollback completed abort: connection ended unexpectedly $ hg clone --uncompressed -U https://hg.python.org/cpython cpython streaming all changes 10404 files to transfer, 248 MB of data transferred 248 MB in 44.4 seconds (5.58 MB/sec) -- Ned Deily, n...@acm.org ___ 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] XP buildbot problem cloning from hg.python.org
In article , Ned Deily wrote: > In article , > David Bolen wrote: > > So that's sort of strange. > Very interesting! I had been doing some housekeeping on some of my > older OS X build systems over the past few days and I've run into the > same problem. In particular, I am seeing this failure on an OS X 10.5.8 > system (running in a Fusion VM) which I've used for years and from which > I have regularly cloned repos from hg.python.org. [...] Update: after consulting with Donald on IRC, it appears that the problem was on the python.org end and is now fixed. David, is it now working again for you? -- Ned Deily, n...@acm.org ___ 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] understanding ubuntu's patches to cpython
In article
,
Buck Evan wrote:
> This particular patch caused virtualenv issue #118 and a subsequent
> workaround:
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/python2.7/trusty/vi
> ew/head:/debian/patches/distutils-install-layout.diff#L281
> <http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/python2.7/trusty-p
> roposed/view/head:/debian/patches/distutils-install-layout.diff#L281>
>
> Although this patch sits on the trusty branch of cpython patckaging, in
> point of fact on that line i have `return
> os.path.join(get_config_var('LIBPL'), "Makefile")`. I see that other
> patches in the same project also touch this line, but none of them have
> this LIBPL code that I find in my actual installation.
>
> Can any of you all help me understand what's going on here? I'm trying to
> pinpoint exactly when/how the problematic code (.replace("/usr/local","/usr")
> went away.
>
> I'm hoping "doko" is on this mailing list. Of course feel free to advise if
> there's a more appropriate forum for this discussion.
This isn't really the place to ask about Ubuntu- (or Debian-) specific
downstream modifications to CPython. Yes, there are people here who
contribute to CPython, Debian, and Ubuntu but I think the best place to
bring up questions like this, based on the Ubuntu project page, might be
on the Ubuntu Core Developers mailing list:
http://packages.ubuntu.com/source/utopic/python-defaults
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Perhaps someone more familiar with the Ubuntu dev process will have a
better suggestion.
--
Ned Deily,
n...@acm.org
___
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] OneGet provider for Python
In article , Paul Moore wrote: > I don't know if this got lost in the other messages in this thread, > but *is* there a stable URL for "the latest Python 3.4 MSI for Windows > amd64" (or similar)? AFAIK, no, there is no such stable URL that directly downloads the latest installer(s) for a platform; the closest is probably https://www.python.org/downloads/windows/ which would require scraping. I'm not sure we would want to encourage such a thing; we want downloaders to read the web page information for each release and make an informed choice. And the number of installer variants may change from release to release for a platform, as was recently the case with the OS X installers. For testing purposes, scraping the web pages or using the (undocumented, see the code base on github) website JSON API are probably the best options now. You could open an issue on the website github issue tracker. -- Ned Deily, n...@acm.org ___ 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] Move selected documentation repos to PSF BitBucket account?
In article <20141121102647.46e97...@limelight.wooz.org>, Barry Warsaw wrote: > On Nov 21, 2014, at 10:36 PM, Nick Coghlan wrote: > > >I'd been taking "must be hosted in PSF infrastructure" as a hard > >requirement, but MAL pointed out earlier this evening that in the age > >of DVCS's, that requirement may not make sense: if you avoid tightly > >coupling your automation to a particular DVCS host's infrastructure, > >then reverting back to self-hosting (if that becomes necessary for > >some reason) is mostly just a matter of "hg push". > > > >If that "must be self-hosted" constraint is removed, then the obvious > >candidate for Mercurial hosting that supports online editing + pull > >requests is the PSF's BitBucket account. > > For the record, I object to moving *official* PSF resources to proprietary, > closed-source infrastructure that we do not control or have access to[*]. > > As nice and friendly as BitBucket or any other code hosting source is today, > there are many reasons why I think this is a bad idea for *official* > branches. We are beholden to their policies and operations, which may not > align with PSF policies or principles today or in the future. We will not be > able to customize the experience for our own needs. We will not have access > to the underlying resources should we need them for any purpose. We cannot > take action ourselves if some problem occurs, e.g. banning an offensive user. > > You're right that in a world of dvcs, branches can be mirrored anywhere. For > that reason, I have no problem allowing developers to use non-PSF controlled > resources *unofficially* if it makes their work easier and doesn't conflict > with their own principles. However, in such cases, I still believe that the > official, master, blessed repositories remain on PSF controlled > infrastructure. Surely that too is possible in the world of dvcs, right? I agree with Barry's arguments. Another issue, so to speak, is what to do about issues? Bitbucket, Github, et al provide integrated issue trackers - like we do with the current hg.python.org / bugs.python.org integration. If we were to move the official repos to another site, then what about the official site for issues? If we don't move the issues as well, some of the power and advantages of using the third-party site are lost (no one-click moving between issues and source, etc.). If we do move the issues, then we have a new source of confusion as to where people should open bugs (adding to the bug janitors workload), the problem of issue history (older and open issues in one tracker, newer ones in another), and a different workflow for tracking the issues. bugs.python.org already supports a kind of pull request with the "Remote hg repo" field. If the goal is to make it easier for newcomers to contribute via pull requests, perhaps that field could be better documented (like adding specific instructions to a readme on the Bitbucket read-only mirror) or improved, if necessary. https://docs.python.org/devguide/triaging.html#mercurial-repository -- Ned Deily, n...@acm.org ___ 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] Move selected documentation repos to PSF BitBucket account?
In article <19336614-0e4f-42bf-a918-1807bb7f3...@stufft.io>, Donald Stufft wrote: [...] > Well you can’t document your way out of a bad UX. The thing you’re > competing with (on Github at least) is: > > 1. I notice a docs change I can make > 2. I click the “Edit” button and it automatically creates a fork, >and opens up a web based editor where I can make changes to >that file. > 3. I fill out the commit message and hit Save. > 4. An automatic pull request is opened up with my changes. > > I can submit a fix for a typo in the docs in like ~30 seconds assuming > I already have a Github account. That sort of instant win is a great > way to get people started contributing to a project and can lead later > to bigger more substantial contributions. [...] > Mostly what I’m trying to say is that documenting a field that essentially > requires > the end user to not only figure out how to use mercurial, but figure out how > to > host a public repository somewhere is not even really within the same order > of > magnitude in ease of use. Sure, I get that. But we're not even talking here about the main Python docs since they are part of the CPython repos, only ancillary repos like PEPs and the developer's guide. The level of activity on those is quite small. So, thinking about it a bit more, PEPs don't normally have bug tracker issues associated with them so I suppose my concerns about issue tracker aren't a major concern for them. The dev guide does get issues opened about it and I suppose they could be managed. But, without tackling the CPython repo workflow (a *much* bigger deal), is the divergence in workflows worth it? I dunno. -- Ned Deily, n...@acm.org ___ 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] installing python 2.7.9 on a Mac
In article <201502070539.t175dmcj003...@fido.openend.se>, Laura Creighton wrote: > webmaster just got mail from a novice who is trying to learn Python in > an introductory class. She got a "The version of Tcl/Tk (8.5.7) in > use may be unstable" message. > > I think that the download page should have a link. > If you get > download and install . Any reason we cannot do that? The truncated "use may be unstable" message above is displayed when you run IDLE. The full message displayed already contains a link to the python.org web page that explains the most up-to-date recommendations for Tcl/Tk use with python.org installers on OS X and includes links to download options. That same link is included in the Welcome message and README text when running the installer for Python. It is also already linked to on the download pages for each release. Until we start shipping our own version of Tcl/Tk for OS X (which has been in the cards), I don't think we can make it much easier. -- Ned Deily, n...@acm.org ___ 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] libffi embedded in CPython
In article , > For UNIX OSs we could probably rely on the system libffi then. What's the > situation on OS X? Anyone know if it has libffi, or would be need to be > pulled in to be used like on Windows? Ronald (in http://bugs.python.org/issue23534): "On OSX the internal copy of libffi that's used is based on the one in PyObjC, which in turn is based on the version of libffi on opensource.apple.com (IIRC with some small patches that fix minor issues found by the PyObjC testsuite)." -- Ned Deily, n...@acm.org ___ 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] Sub-claasing pathlib.Path seems impossible
In article , Christophe Bal wrote: > In this post > <http://stackoverflow.com/questions/29850801/simple-subclassing-pathlib-path-d > oes-not-work/29854141#29854141>, > I have noticed a problem with the following code. [...] > This breaks the sub-classing from Python point of view. In the post > <http://stackoverflow.com/questions/29850801/simple-subclassing-pathlib-path-d > oes-not-work/29854141#29854141>, > I give a hack to sub-class Path but it's a bit Unpythonic. In article , Guido van Rossum wrote: > It does sound like subclassing Path should be made easier. Christophe, if you want to pursue this, you should open an issue for it on the Python bug tracker, bugs.python.org. Otherwise, it will likely be forgotten here. -- Ned Deily, n...@acm.org ___ 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] Mac popups running make test
In article , Tal Einat wrote: > On Sun, May 10, 2015 at 9:07 PM, Carol Willing < > willi...@willingconsulting.com> wrote: > > On 5/10/15 10:29 AM, Tal Einat wrote: > > On Sun, May 10, 2015 at 5:07 PM, Brett Cannon wrote: > >> On Sun, May 10, 2015 at 10:04 AM Skip Montanaro > >> wrote: > >>> I haven't run the test suite in awhile. I am in the midst of running it > >>> on my Mac running Yosemite 10.10.3. Twice now, I've gotten this popup: > >>> I assume this is testing some server listening on localhost. Is this a > >>> new thing, either with the Python test suite or with Mac OS X? (I'd > >>> normally be hidden behind a NAT firewall, but at the moment I am on a > >>> miserable public connection in a Peet's Coffee, so it takes on slightly > >>> more importance...) > >> It's not new. > > Indeed, I've run into this as well. > >>> I've also seen the Crash Reporter pop up many times, but as far as I > >>> could tell, in all cases the test suite output told me it was expected. > >>> Perhaps tests which listen for network connections should also mention > >>> that, at least on Macs? > >> Wouldn't hurt. Just requires tracking down which test(s) triggers it > >> (might be more than one and I don't know if answering that popup applies > >> for the rest of the test execution or once per test if you use -j). > > If anyone starts working on this, let me know if I can help, e.g. trying > > things on my own Mac. \> >I believe that the message has to do with OS X's sandboxing > > implementation and the setting of the sandbox's entitlement keys. Here's an > > Apple doc: > > https://developer.apple.com/library/ios/documentation/Miscellaneous/Referenc > > e/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/u > > id/TP40011195-CH4-SW9 > > I'm unaware of a way to work around this other than using Apple's code > > signing or adjusting target build settings in XCode :( If anyone knows a > > good way to workaround or manually set permission (other than clicking the > > Allow button), I would be interested. > I was reading about this a few weeks ago an recall finding a way to ad-hoc > sign the built python executable. Here's a link below. I haven't tried > this, though, and don't know if it would work with a python executable > rather than a proper OSX app. If it does work, it would be useful to add > this as a tool and/or mention it in the developer docs. > > http://apple.stackexchange.com/a/121010 I believe the issue has to do with the OS X application firewall and not sandboxing, as vanilla Python on OS X is not sandboxed. See: https://support.apple.com/en-us/HT201642 As described there, codesigned applications are automatically authorized to accept inbound connections; that's the workaround proposed in the apple.stackexchange cite. But arbitrarily signing development binaries after every compile is probably not a good idea. Another option is to configure the firewall but that probably only can be made to work with a framework build of Python which launches Python within an app bundle. In any case, please open an issue on the bug tracker so we can follow up on this. -- Ned Deily, n...@acm.org ___ 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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On May 12, 2015, at 10:04, Larry Hastings wrote: > 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. One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA "trunk"), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3.4 support ends, which following recent past practice, would be relatively soon after 3.5.0. > 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. Where does 3.6.x fit into Workflow 2? -- Ned Deily n...@acm.org -- [] ___ 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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On May 12, 2015, at 10:38, Larry Hastings wrote: > On 05/12/2015 10:23 AM, Ned Deily wrote: >> One possible issue with Workflow 1 is that there would need to be an >> additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA >> "trunk"), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 >> is released and, ideally, until 3.4 support ends, which following recent >> past practice, would be relatively soon after 3.5.0. > Good point. Though I could concievably push the 3.5.0 rc repo up to an > hg.python.org "server-side clone" and kick off the buildbots from there. I wasn't worrying about the 3.5.0rc "branch", but, yeah, we could probably improvise ones for that as you suggest. So, buildbots would be: 3.5 branch (->3.5.1 as of beta1), 3.5rc (as needed from rc1 to final), along with the current 3.x (->3.5.0 today, -> 3.6.0, as of beta1), 3.4, and 2.7 buildbots. I like the idea of experimentally trying the push workflow but, if we are all doing our jobs right, there should be very few changes going in after rc1 so most committers won't need to push anything to the 3.5.0rc repo and, if for some reason they aren't able to use Bitbucket, someone could do it for them. In other words, while nice, the use of Bitbucket is not a critical feature of Workflow 1. I think 1 is the best choice with or without the use of Bitbucket. But we should also recognize that adopting it can make more work for committers fixing bugs over the next few months (between beta1 and final), as we need to consider testing and pushing each fix to default (for 3.6.0), 3.5 (for 3.5.0 until rc1, then for 3.5.1), 3.4 (for 3.4.4), and/or 2.7 (for 2.7.11). That's the tradeoff for allowing feature work to be committed, integrated, and tested during the beta and rc periods. >> Where does 3.6.x fit into Workflow 2? > It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after > 3.5.0 final ships, as per tradition. Workflow 0 = -1 Workflow 1 = +1 Workflow 2 = -0.5 -- Ned Deily n...@acm.org -- [] ___ 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] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
In article <55523adb.4000...@hastings.org>, Larry Hastings wrote: > On 05/12/2015 10:23 AM, Chris Angelico wrote: > > Will this model be plausibly extensible to every release? For > > instance, when a 3.5.1 rc is cut, will the 3.5 branch immediately > > become 3.5.2, with a new 3.5.1 branch being opened on bitbucket? > Yes, we could always do it that way, though in the past we haven't > bothered. Development on previous versions slows down a great deal > after x.y.1. Well, we *could*. But that is hardly worth it as we don't do long-term maintenance of each maintenance release. In other words, from a python-dev perspective, 3.5.1 is dead the moment 3.5.2 goes out the door; we only maintain the most recent maintenance release of a major release cycle. So there is no need for a 3.5.x branch other than possibly during the typically very short rc cycle of a maintenance release and even then we usually see at most a couple of rc fixes and usually none, as expected. -- Ned Deily, n...@acm.org ___ 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] cpython (merge 3.4 -> default): Added tests for more builtin types.
In article <20150516183940.21146.77...@psf.io>,
serhiy.storchaka wrote:
> https://hg.python.org/cpython/rev/7b350f712c0e
> changeset: 96099:7b350f712c0e
> parent: 96096:f0c94892ac31
> parent: 96098:955dffec3d94
> user:Serhiy Storchaka
> date:Sat May 16 21:35:56 2015 +0300
> summary:
> Added tests for more builtin types.
> Made test_pprint discoverable.
>
> files:
> Lib/test/test_pprint.py | 17 -
> 1 files changed, 8 insertions(+), 9 deletions(-)
==
ERROR: test_coverage (test.test_trace.TestCoverage)
--
Traceback (most recent call last):
File "/py/dev/3x/root/uxd/lib/python3.5/test/test_trace.py", line 312,
in test_coverage
self._coverage(tracer)
File "/py/dev/3x/root/uxd/lib/python3.5/test/test_trace.py", line 305,
in _coverage
tracer.run(cmd)
File "/py/dev/3x/root/uxd/lib/python3.5/trace.py", line 500, in run
self.runctx(cmd, dict, dict)
File "/py/dev/3x/root/uxd/lib/python3.5/trace.py", line 508, in runctx
exec(cmd, globals, locals)
File "", line 1, in
AttributeError: module 'test.test_pprint' has no attribute 'test_main'
==
ERROR: test_coverage_ignore (test.test_trace.TestCoverage)
--
Traceback (most recent call last):
File "/py/dev/3x/root/uxd/lib/python3.5/test/test_trace.py", line 327,
in test_coverage_ignore
self._coverage(tracer)
File "/py/dev/3x/root/uxd/lib/python3.5/test/test_trace.py", line 305,
in _coverage
tracer.run(cmd)
File "/py/dev/3x/root/uxd/lib/python3.5/trace.py", line 500, in run
self.runctx(cmd, dict, dict)
File "/py/dev/3x/root/uxd/lib/python3.5/trace.py", line 508, in runctx
exec(cmd, globals, locals)
File "", line 1, in
AttributeError: module 'test.test_pprint' has no attribute 'test_main'
Also breaks 3.4.
--
Ned Deily,
n...@acm.org
___
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] PEP 490 "Chain exceptions at C level" rejected
On Sep 12, 2017, at 12:18, Larry Hastings wrote: > On 09/12/2017 02:49 AM, Victor Stinner wrote: >> Note: The PEP is not yet rejected on python.org, it will be done at >> the next cron job run. > My understanding is that the docs are built once a day via cron job, but the > PEPs are built every time the repo changes thanks to Travis CI. So it should > be only a matter of minutes between you pushing a change to a PEP and the > change showing up live on the web. I believe peps on python.org are updated every 15 minutes. The html version of docs for maintenance and feature branches (currently, master->3.7, 3.6, 2.7) on docs.python.org are updated every 3 hours and, in theory, the downloadable versions are updated once a day. But take that with a grain of salt (nudge nudge, wink wink). -- Ned Deily n...@python.org -- [] ___ 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] Reminder: snapshots and releases coming up in the next several days
Lots of releases coming up soon! 2017-09-16: - Python 2.7.14 final release 2017-09-18 1200 UTC cutoff: - Python 3.6.3 rc1 - Python 3.3.7 final release (following by retirement) If you know of any issues that you feel need to be addressed in these releases, please make sure there is an open issue on the bug tracker set to "release blocker". Also on 2017-09-18: - Python 3.7.0 alpha 1 This will be the first preview snapshot of 3.7.0. It's still very early in the development cycle for 3.7. The main purpose of early alpha releases is to exercise the build and release process and to make it easier for Windows and Macs users to help test. Many new features and build changes are yet to appear in subsequent releases prior to feature code cutoff on 2018-01-29 at 3.7.0b1. Thanks for your help! --Ned -- Ned Deily n...@python.org -- [] ___ 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] Reminder: snapshots and releases coming up in the next several days
I know the issue of the Google Calendar feed has come up before and we should either maintain it or remove it from the web site. I don't know who has or had the "keys" to it. I'm traveling the next couple of days but I'll look into it afterwards. If anyone has info about it, please contact me directly. AFAIK, there is no other release calendar feed currently. -- Ned Deily n...@python.org -- [] > On Sep 13, 2017, at 09:57, Fred Drake wrote: > >> On Wed, Sep 13, 2017 at 12:35 PM, Ned Deily wrote: >> Lots of releases coming up soon! > > There's a "Python Release Schedule" calendar on Google Calendar that > used to be maintained, but that appears to have been dropped, though I > found it useful. > > Is there any sort of calendar feed available with this schedule that's > currently maintained? > > > -Fred > > -- > Fred L. Drake, Jr. > "A storm broke loose in my mind." --Albert Einstein ___ 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] [RELEASE] Python 3.6.3rc1 and 3.7.0a1 are now available for testing and more
The Python build factories have been busy the last several weeks preparing our fall lineup of releases. Today we are happy to announce three additions: 3.6.3rc1, 3.7.0a1, and 3.3.7 final, which join last weekend's 2.7.14 and last month's 3.5.4 bug-fix releases and 3.4.7 security-fix update (https://www.python.org/downloads/). 1. Python 3.6.3rc1 is the first release candidate for Python 3.6.3, the next maintenance release of Python 3.6. While 3.6.3rc1 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). 3.6.3 is planned for final release on 2017-10-02 with the next maintenance release expected to follow in about 3 months. You can find Python 3.6.3rc1 and more information here: https://www.python.org/downloads/release/python-363rc1/ 2. Python 3.7.0a1 is the first of four planned alpha releases of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview release, 3.6.0a2, is planned for 2017-10-16. You can find Python 3.7.0a1 and more information here: https://www.python.org/downloads/release/python-370a1/ 3. Python 3.3.7 is also now available. It is a security-fix source-only release and is expected to be the final release of any kind for Python 3.3.x before it reaches end-of-life status on 2017-09-29, five years after its initial release. Because 3.3.x has long been in security-fix mode, 3.3.7 may no longer build correctly on all current operating system releases and some tests may fail. If you are still using Python 3.3.x, we **strongly** encourage you to upgrade now to a more recent, fully supported version of Python 3. You can find Python 3.3.7 here: https://www.python.org/downloads/release/python-337/ -- Ned Deily n...@python.org -- [] ___ 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] [RELEASE] Python 3.6.3 is now available
On behalf of the Python development community and the Python 3.6 release team, I am happy to announce the availability of Python 3.6.3, the third maintenance release of Python 3.6. Detailed information about the changes made in 3.6.3 can be found in the change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-3-final Please see "What’s New In Python 3.6" for more information about the new features in Python 3.6: https://docs.python.org/3.6/whatsnew/3.6.html You can download Python 3.6.3 here: https://www.python.org/downloads/release/python-363/ The next maintenance release of Python 3.6 is expected to follow in about 3 months, around the end of 2017-12. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ Enjoy! -- Ned Deily n...@python.org -- [] ___ 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] [RELEASE] Python 3.7.0a2 is now available for testing
Python 3.7.0a2 is the second of four planned alpha previews of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview, 3.7.0a3, is planned for 2017-11-27. You can find Python 3.7.0a2 and more information here: https://www.python.org/downloads/release/python-370a2/ -- Ned Deily n...@python.org -- [] ___ 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] Reminder: 12 weeks to 3.7 feature code cutoff
Happy belated Halloween to those who celebrate it; I hope it wasn't too scary! Also possibly scary: we have just a little over 12 weeks remaining until Python 3.7's feature code cutoff, 2018-01-29. Those 12 weeks include a number of traditional holidays around the world so, if you are planning on writing another PEP for 3.7 or working on getting an existing one approved or getting feature code reviewed, please plan accordingly.If you have something in the pipeline, please either let me know or, when implemented, add the feature to PEP 537, the 3.7 Release Schedule PEP. As you may recall, the release schedule calls for 4 alpha preview releases prior to the feature code cutoff with the first beta release. We have already produced the first two alphas. Reviewing the schedule recently, I realized that I had "front-loaded" the alphas, leaving a bigger gap between the final alphas and the first beta. So I have adjusted the schedule a bit, pushing alpha 3 and 4 out. The new d ates are: - 3.7.0 alpha 3: 2017-11-27 (was 2017-11-13) - 3.7.0 alpha 4: 2018-01-08 (was 2017-12-18) - 3.7.0 beta 1: 2018-01-29 (feature freeze - unchanged) I hope the new dates give you a little bit more time to get your bits finished and get a little bit of exposure prior to the feature freeze. Considering how quickly and positively it has been adopted, 3.6 is going to be a tough act to follow. But we can do it again. Thank you all for your ongoing efforts! --Ned -- Ned Deily n...@python.org -- [] ___ 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] 3.5.4 doesn't appear in changelog
On Nov 6, 2017, at 13:07, Antoine Pitrou wrote: > Is there a known reason why 3.5.4 doesn't appear in the changelogs at > the bottom of https://docs.python.org/3.7/whatsnew/index.html ? > > (all releases until 3.5.3 do) As things stand now, the changelogs from maintenance releases have to be manually merged into feature release trees (e.g. master). That's something I've done close to final feature release. With the switch to blurb, it would be nice to better automate the sharing of changelogs between branches but I don't think anyone has tried to tackle that yet. Patches welome. -- Ned Deily n...@python.org -- [] ___ 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] [python-committers] IPv6 issues on *.python.org
On Nov 16, 2017, at 15:07, Antoine Pitrou wrote: > I'm having IPv6 issues on *.python.org. Is anyone having the same > issues or is it just me? Who should I report this to? The PSF Infrastructure team is available via email or IRC: http://psf-salt.readthedocs.io/overview/#the-infrastructure-team -- Ned Deily n...@python.org -- [] ___ 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] 3.7.0a3 cutoff extended a week to 12-04
We are extending the cutoff for the next 3.7 alpha preview (3.7.0a3) a week, moving it from today to 12-04 12:00 UTC. The main reason is a selfish one: I have been traveling and mainly offline for the last few weeks and I am still catching up with activity. Since we are getting close to feature code cutoff for the 3.7 cycle, it would be better to get things in sooner than later. Following alpha 3, we will have one more alpha preview, 3.7.0a4 on 2018-01-08, prior to the feature code cutoff with 3.7.0b1 on 2018-01-29. Note that 12-04 is also the scheduled date for the next 3.6.x maintenance release release candidate, 3.6.4rc1. So I hope you can take advantage of the extra days for both release cycles. Thanks again for all your efforts! --Ned -- Ned Deily n...@python.org -- [] ___ 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] 3.7.0a3 still open
Congratulations to the owners of the newly accepted PEPs. The code cutoff for 3.7.0 alpha 3 is scheduled for today (along with 3.6.3rc1). I know at least one of the PEPs has code ready to commit. I will hold off on tagging 3.7.0a3 for another 6 hours or so. If you feel your code is adequately reviewed and ready to go, go for it; likewise for normal bug fixes and doc changes. But keep in the mind that there is still one more alpha preview release coming prior to the beta 1 feature code freeze, so no need to panic. -- Ned Deily n...@python.org -- [] ___ 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] [RELEASE] Python 3.6.4rc1 and 3.7.0a3 now available for testing
Announcing the immediate availability of Python 3.6.4 release candidate 1 and of Python 3.7.0 alpha 3! Python 3.6.4rc1 is the first release candidate for Python 3.6.4, the next maintenance release of Python 3.6. While 3.6.4rc1 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). 3.6.4 is planned for final release on 2017-12-18 with the next maintenance release expected to follow in about 3 months. You can find Python 3.6.4rc1 and more information here: https://www.python.org/downloads/release/python-364rc1/ Python 3.7.0a3 is the third of four planned alpha releases of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview release, 3.7.0a4, is planned for 2018-01-08. You can find Python 3.7.0a3 and more information here: https://www.python.org/downloads/release/python-370a3/ -- Ned Deily n...@python.org -- [] ___ 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] Support of the Android platform
On Dec 10, 2017, at 16:26, Guido van Rossum wrote: > On Dec 10, 2017 12:29, "Brett Cannon" wrote: >> On Sun, 10 Dec 2017 at 06:19 Xavier de Gaye wrote: >>> The following note is a proposal to add the support of the Android platform. >>> [...] >> While the note from a technical standpoint is interest, Xavier, I don't >> quite see what needs to be done to support Android at this point. Are you >> simply asking we add Android API 24 as an official platform? Or permission >> to add your note to the Misc/ directory? Basically what are you wanting to >> see happen? :) > Maybe it should be a PEP? Yes, I agree there needs to be a PEP for this. I have conflicting thoughts about formalizing Android support. On the one hand, it would be nice to have. But on the other, it does add a large non-zero burden to all core developers and to the release teams, to the minimum extent of trying to make sure that all ongoing changes don't break platform support. At a minimum a PEP needs to address the minimum platform support requirement outlined in PEP 11 (https://www.python.org/dev/peps/pep-0011/#supporting-platforms). As long as Xavier is willing to keep supporting the platform, the first requirement, having a core developer, should be met. But for a platform that, understandably, has as many special requirements as Android does, the second requirement, having a stable buildbot, seems to me to be an absolute necessity, and the PEP needs to address exactly what sort of buildbot requirements make sense here: emulators, SDKs, etc. Otherwise, we run the risk of ending up with an ongoing maintenance headache and unhappy users, as has been the case in the past with support for other platforms. -- Ned Deily n...@python.org -- [] ___ 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] [RELEASE] Python 3.6.4 is now available
On behalf of the Python development community and the Python 3.6 release team, I am happy to announce the availability of Python 3.6.4, the fourth maintenance release of Python 3.6. Detailed information about the changes made in 3.6.4 can be found in the change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-4-final Please see "What’s New In Python 3.6" for more information about the new features in Python 3.6: https://docs.python.org/3.6/whatsnew/3.6.html You can download Python 3.6.4 here: https://www.python.org/downloads/release/python-364/ The next maintenance release of Python 3.6 is expected to follow in about 3 months, around the end of 2018-03. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ Enjoy! -- Ned Deily n...@python.org -- [] ___ 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] [RELEASE] Python 3.7.0a4 is now available for testing
Python 3.7.0a4 is the last of four planned alpha releases of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview release, 3.7.0b1, is planned for 2018-01-29. You can find Python 3.7.0a4 and more information here: https://www.python.org/downloads/release/python-370a4/ -- Ned Deily n...@python.org -- [] ___ 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] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3
On Jan 14, 2018, at 08:39, Christian Heimes wrote: > On 2018-01-14 09:24, Matt Billenstein wrote: >> Correct me if I'm wrong, but Python3 on osx bundles openssl since Apple has >> deprecated (and no longer ships the header files for) the version shipped >> with >> recent versions of osx. >> >> Perhaps this is an option to support the various flavors of Linux as well? > > AFAK Apple has decided to compile and statically link CPython's ssl with > an ancient, customized LibreSSL version. Cory posted [1] a couple of > months ago I think you're conflating some things here. Apple has not yet shipped a version of Python 3 with macOS so the fact that Apple now links their version of Python2.7 with a "private" copy of LibreSSL is irrelevant. (It's private in the sense that they don't ship the header files for it; the shared libs are there just for the use of the open source products they ship with macOS that don't yet use the macOS native crypto APIs, products like Python and Perl.) What Matt is likely thinking of is the Python 3 versions provided by the python.org macOS binary installers where we do build and link with our own 1.0.2 (and soon 1.1.0 for 3.7) versions of OpenSSL. Currently, the OpenSSL (and several other third-party libs such as libxz which is not shipped by Apple) are built as part of the installer build script in the Mac section of the source repo. I would like to refactor and generalize that so those third-party libs could optionally be used for non-installer builds as well. But, in any case, we don't have much choice for the installer builds until such time as cPython has support for the Apple-provided crypto APIs. > I'm not going to add OpenSSL sources or builds to CPython. We just got > rid of copies of libffi and other 3rd party dependencies. Crypto and TLS > libraries are much, MUCH more complicated to handle than libffi. It's a > constant moving targets of attacks. Vendors and distributions also have > different opinions about trust store and policies. > > Let's keep build dependencies a downstream and vendor problem. That's not always an option, unfortunately. -- Ned Deily n...@python.org -- [] ___ 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] IMPORTANT: 3.7.0b1 and feature code cutoff 2018-01-29
Happy mid-winter (northern hemisphere) or -summer (southern)! The time has come to finish feature development for Python 3.7. 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.7.0 must be checked in by the b1 cutoff on end-of-day Monday (unless you have contacted me and we have agreed on an extension). As was done during the 3.6 release cycle, we will create the 3.7 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.7 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.7 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.7 as possible during the beta phase. Also, during the 3.6.0 release cycle, the question of ABI stability during the final (e.g. beta and release candidate) phases of the release came up. Last-minute changes put a burden on our and our downstream users testing efforts and adds risk to the release. Therefore, as was proposed then, we will strive to have no ABI changes after beta 3. More details forthcoming. To recap: 2018-01-29 ~23:59 Anywhere on Earth (UTC-12:00): code snapshot for 3.7.0 beta 1 (feature code freeze, no new features) 2019-01-30: 3.7 branch opens for 3.7.0 feature development continues on master branch, now for 3.8.0 2018-01-30 to 2018-05-21: 3.7.0 beta phase (bug, regression, and doc fixes, no new features) 2018-03-26: 3.7.0 beta 3 (3.7.0 ABI freeze) 2018-05-21: 3.7.0 release candidate 1 (3.7.0 code freeze) 2018-06-15: 3.7.0 release (3.7.0rc1 plus, if necessary, any dire emergency fixes) ~2019-12 tentative (3.7.0 release + 18 months): 3.8.0 release (details TBD) Thank you all for your great efforts so far on 3.7; it should be another great release! --Ned https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@python.org -- [] ___ 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] Sad buildbots
On Jan 28, 2018, at 18:00, Victor Stinner wrote: > It seems like the feature freeze is close: while I usually get 2 > emails/day at maximum on buildbot-status, I got 14 emails during the > weekend: > https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/ > (are all buildbots red? :-p) > > I will not have the bandwidth to analyze all buildbot failures. Can > someone help to investigate all these funny new regressions? > http://buildbot.python.org/all/#/builders > > I would feel safer to cut a release if most buildbots are green again. Never fear, we're *not* going to do a release in such a state. That's one of the reasons we have release managers. :-) Not surprisingly, there has been a *lot* of activity over the last few days as core-developers work on getting features finished prior to the 3.7 feature code freeze coming up at the end of Monday AoE. Some of the intermediate checkins cause some breakages across the board, unfortunately, that have subsequently been addressed. Most of the 3.x stable buildbots are currently green with some builds still going on. But, yeah, please all keep an eye of them especially those of you merging code. Just because the CI tests passed doesn't mean there won't be problems on other platforms and configurations. Thanks for everyone's help so far! We're getting close. -- Ned Deily n...@python.org -- [] ___ 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] 3.7.0b1 status
Just a quick update: thanks to all of you who worked long hours to get features completed and merged in for the 3.7 feature code cutoff yesterday. We release elves have been busy behind the scenes baking goodies. So far everything looks OK. But we're taking a little longer than usual: this is, in many ways, the most complicated milestone of the release cycle, since it involves creating a new release branch and other munging, and this is the first time we are doing this since we moved to our new git-based workflow last year and we want to get it right. We will have everything done and announced in not more than 24 hours from now. If you wish, feel free to merge new commits into the master branch for release in 3.8, with the understanding that any also destined for 3.7.0 will need to be cherrypicked after the 3.7 branch is available. Other branches (3.6, 2.7) are unaffected. Thanks for your patience! -- Ned Deily n...@python.org -- [] ___ 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] [IMPORTANT] post 3.7.0b1 development now open
Here we are: 3.7.0b1 and feature code freeze! Congratulations and thanks to all of you who've contributed to the huge number of PEPs, features, bug fixes, and doc changes that have gone into 3.7 since feature development began back in September 2016, after 3.6.0b1, 3.6's feature freeze. Now that feature development for 3.7 is over, the challenge is to put the finishing touches on the features and documentation, squash bugs, and test test test. In the cpython repo, there is now a 3.7 branch. Starting now, all PRs destined for 3.7.0 should get cherry-picked from master to the 3.7 branch or just pushed to 3.7 if only applicable there. New features should continue to be pushed to the master branch for release in 3.8; no new features are now permitted in 3.7 unless you have contacted me and we have agreed on an extension (and all granted extensions will expire as of 3.7.0b2). As before, bug fixes appropriate for 3.6.x should continue to be cherry-picked to the 3.6 branch. 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.7 beta. The cpython repo on Github has been updated. You should now find that builds on the master branch produce a Python 3.8, rather than 3.7; you may want to clean your build directory. And there is now a 3.7 branch that you will need to use for 3.7 builds and pushs. There were several PRs that were merged to master over the last couple of days since we started 3.7.0b1 release engineering. All but one of those have been cherry-picked into the new 3.7 branch and you should have seen messages for them. One was for a 3.8 feature and so was not backported. At the moment, the new 3.7 buildbots may not be fully operational but they should be soon. Likewise, the docs.python.org may take up to 24 hours to reflect all the changes. Note that is the first time we've done a feature freeze using our new git-based workflow, so there's likely that there might be a glitch or something overlooked. Please let us know if you suspect something or have a question. I'll be around here and or #python-dev. Also, don't forget to direct 3.8-related questions to Łukasz. Welcome on-board! To recap: 2018-01-31: 3.7 branch open for 3.7.0; 3.8.0 feature development begins 2018-01-31 to 2018-05-21: 3.7.0 beta phase (no new 3.7 features) - push PRs for new features, bugs, regressions, doc fixes to the master branch for release in 3.8 - cherry-pick or push PRs for 3.7.0 (bug/regression/doc fixes) to the new 3.7 branch - cherry-pick or push select PRs for important bug/regression/doc fixes to 3.6 and 2.7 branches as appropriate - propose PRs to 3.5 and 3.4 branches for any identified security issues 2018-02-26: 3.7.0 beta 2 (next beta preview) 2018-03-26: 3.7.0 beta 3 (3.7.0 ABI freeze) 2018-04-30: 3.7.0 beta 4 (only critical and urgent fixes after this point) 2018-05-21: 3.7.0 release candidate 1 (3.7.0 code freeze, only any emergency fixes afer this point) 2018-06-15: 3.7.0 release 2019-10-20: 3.8.0 release (next planned feature release, see PEP 569) Thank you all again for your great efforts so far on 3.7! --Ned ___ 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] [RELEASE] Python 3.7.0b1 is now available for testing
On behalf of the Python development community and the Python 3.7 release team, I'm happy to announce the availability of Python 3.7.0b1. b1 is the first of four planned beta releases of Python 3.7, the next major release of Python, and marks the end of the feature development phase for 3.7. You can find Python 3.7.0b1 here: https://www.python.org/downloads/release/python-370b1/ Among the new major new features in Python 3.7 are: * PEP 538, Coercing the legacy C locale to a UTF-8 based locale * PEP 539, A New C-API for Thread-Local Storage in CPython * PEP 540, UTF-8 mode * PEP 552, Deterministic pyc * PEP 553, Built-in breakpoint() * PEP 557, Data Classes * PEP 560, Core support for typing module and generic types * PEP 562, Module __getattr__ and __dir__ * PEP 563, Postponed Evaluation of Annotations * PEP 564, Time functions with nanosecond resolution * PEP 565, Show DeprecationWarning in __main__ * PEP 567, Context Variables Please see "What’s New In Python 3.7" for more information. Additional documentation for these features and for other changes will be provided during the beta phase. https://docs.python.org/3.7/whatsnew/3.7.html Beta releases are intended to give you the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage you to test your projects with 3.7 during the beta phase and report issues found to https://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 (2018-05-21). Our goal is have no ABI changes after beta 3 and no code changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.7 as possible during the beta phase. Attention macOS users: with 3.7.0b1, we are providing a choice of two binary installers. The new variant provides a 64-bit-only version for macOS 10.9 and later systems; this variant also now includes its own built-in version of Tcl/Tk 8.6. We welcome your feedback. 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.7 will be 3.7.0b2, currently scheduled for 2018-02-26. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@python.org -- [] ___ 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] Is 4.0 a major breaking changes release?
On Feb 3, 2018, at 17:40, Alex Walters wrote: > I am still working on porting code from 2.x to 3.x. As of late on the lists > I've seen comments about making somewhat major changes in 4.0 - now I'm > concerned that I should pause my porting effort until that is released. Is > python 4 going to be another python 3? At this point, Python 4 is just a convenient tag for really big changes. There are no concrete plans or schedule for such a major undertaking. Port away to Python 3.x! -- Ned Deily n...@python.org -- [] ___ 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] 3.7.0b2 code cutoff soon!
Just a reminder that 3.7.0b2 is almost upon us. Please get your feature fixes, bug fixes, and documentation updates in before 2018-02-26 ~23:59 Anywhere on Earth (UTC-12:00). That's a little over 1.5 days from now. Also, as previously noted, for those of you who asked for and received extensions for a few remaining 3.7.0 features, those extensions expire as of the b2 cutoff so please plan accordingly. Looking ahead, we need to start locking down 3.7.0 so that our downstream users, that is, third-party package developers, Python distributors, and end users, can test their code with confidence that the actual release of 3.7.0 will hold no unpleasant surprises. So please assume that the 3.7.0 ABI will be frozen as of beta 3, in 4 weeks on 2018-03-26, and that only doc updates and the kinds of bug fixes appropriate for a maintenance release should be going into the 3.7 branch after 3.7.0b3 without further discussion. Thanks again for all of your hard work towards making 3.7.0 yet another great release! --Ned -- Ned Deily n...@python.org -- [] ___ 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] [RELEASE] Python 3.7.0b2 is now available for testing
On behalf of the Python development community and the Python 3.7 release team, I'm happy to announce the availability of Python 3.7.0b2. b2 is the second of four planned beta releases of Python 3.7, the next major release of Python, and marks the end of the feature development phase for 3.7. You can find Python 3.7.0b2 here: https://www.python.org/downloads/release/python-370b2/ Among the new major new features in Python 3.7 are: * PEP 538, Coercing the legacy C locale to a UTF-8 based locale * PEP 539, A New C-API for Thread-Local Storage in CPython * PEP 540, UTF-8 mode * PEP 552, Deterministic pyc * PEP 553, Built-in breakpoint() * PEP 557, Data Classes * PEP 560, Core support for typing module and generic types * PEP 562, Module __getattr__ and __dir__ * PEP 563, Postponed Evaluation of Annotations * PEP 564, Time functions with nanosecond resolution * PEP 565, Show DeprecationWarning in __main__ * PEP 567, Context Variables Please see "What’s New In Python 3.7" for more information. Additional documentation for these features and for other changes will be provided during the beta phase. https://docs.python.org/3.7/whatsnew/3.7.html Beta releases are intended to give you the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage you to test your projects with 3.7 during the beta phase and report issues found to https://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 (2018-05-21). Our goal is have no ABI changes after beta 3 and no code changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.7 as possible during the beta phase. Attention macOS users: as of b1, there is a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default version when 3.7.0 releases. Check it out! We welcome your feedback. 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.7 will be 3.7.0b3, currently scheduled for 2018-03-26. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@python.org -- [] ___ 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] Reminder: 3.6.5rc1 cutoff coming up
A quick reminder that it's time for our next quarterly maintenance release of Python 3.6. The cutoff for 3.6.5rc1 is planned for 2018-03-12 end-of-the-day AOE. Please get any bug fixes and doc changes in before then. Expect that any changes merged after the 3.6.5rc1 cutoff will be released in 3.6.6 which is currently scheduled for 2018-06 (along with 3.7.0). Also, a reminder that 3.6.x has been out in the field for nearly 15 months now and thanks to all of your hard work in previous feature releases and during the 3.6 development phase, the 3.6 release series has seen remarkably quick adoption to overall great acclaim. Now that 3.6 has reached a certain level of maturity, it is important for all of us to continue to focus on stability for all of its downstream users. A key assumption of our maintenance strategy for years has been that we as a project will only maintain the most recent bugfix (or security) release. In other words, when we release x.y.z, we immediately drop support for x.y.z-1. To do that, we implicitly promise to users that they can "painlessly" upgrade from any x.y.n to x.y.z where n < z. To try to keep that promise, we strive to make no incompatible changes in x.y.z without *really* good reasons. I think it is important as 3.6 moves along in its lifecycle to put ourselves in the shoes of our users and ask ourselve s if a change is really appropriate at this stage. There's no hard and fast rule here, just continue to use your best judgement. When in doubt, ask! FYI, I've adjusted the 3.6.x release schedule to allow for 2 additional quarterly maintenance releases after 3.7.0 releases instead of just one. That means the final bugfix release for the 3.6 series is planned to be 3.6.8 in 2018-12, 6 months after 3.7.0 releases and 2 years after 3.6.0 first released. Thereafter, only security issues will be accepted and addressed for the remaining life of 3.6. Thanks again! --Ned https://www.python.org/dev/peps/pep-0494/ -- Ned Deily n...@python.org -- [] ___ 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] Git hub : CLA Not Signed label
On Mar 10, 2018, at 21:58, Anthony Flury via Python-Dev wrote: > I submitted two Pull Requests last Sunday, only a few hours after I signed > the CLA. > > I understand why the 'Knights who say ni' marked the Pull request as 'CLA Not > Signed' Label at the time I submitted the Pull requests, but I was wondering > when the Labels get reset. I've reset both manually. Thanks for the heads up. Now to get reviews! -- Ned Deily n...@python.org -- [] ___ 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] [RELEASE] Python 3.6.5rc1 is now available for testing
Announcing the immediate availability of Python 3.6.5 release candidate 1! Python 3.6.5rc1 is the first release candidate for Python 3.6.5, the next maintenance release of Python 3.6. While 3.6.5rc1 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). 3.6.5 is planned for final release on 2018-03-26 with the next maintenance release expected to follow in about 3 months. You can find Python 3.6.5rc1 and more information here: https://www.python.org/downloads/release/python-365rc1/ Attention macOS users: as of 3.6.5rc1, there is a new additional installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default variant in future releases. Check it out! -- Ned Deily n...@python.org -- [] ___ 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] IMPORTANT - 3.7.0b3 cutoff / 3.7.0 ABI freeze
Just a reminder that 3.7.0b3 is almost upon us. Please get your feature fixes, bug fixes, and documentation updates in before 2018-03-26 ~23:59 Anywhere on Earth (UTC-12:00). That's a little over 3.5 days from now. IMPORTANT: We are now entering the final phases of 3.7.0. After the tagging for 3.7.0b3, the intention is that the ABI for 3.7.0 is frozen. After next week's 3.7.0b3, there will only be two more opportunities planned for changes prior to 3.7.0 final: - 2018-04-30 3.7.0 beta 4 - 2018-05-31 3.7.0 release candidate As I've noted in previous communications, we need to start locking down 3.7.0 so that our downstream users, that is, third-party package developers, Python distributors, and end users, can test their code with confidence that the actual release of 3.7.0 will hold no unpleasant surprises. So after 3.7.0b3, you should treat the 3.7 branch as if it is already released and in maintenance mode. That means you should only push the kinds of changes that are appropriate for a maintenance release: non-ABI-changing bug and feature fixes and documentation updates. If you find a problem that requires an ABI-altering or other significant user-facing change (for example, something likely to introduce an incompatibility with existing users' code or require rebuilding of user extension modules), please make sure to set the b.p.o issue to "release blocker" priority and describe there why you feel the change is necessary. If you are reviewing PRs for 3.7 (and please do!), be on the lookout for and flag potential incompatibilities (we've all made them). Thanks again for all of your hard work towards making 3.7.0 yet another great release! --Ned -- Ned Deily n...@python.org -- [] ___ 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] Move ensurepip blobs to external place
On Mar 24, 2018, at 16:13, Steve Dower wrote: > Or we could just pull the right version directly from PyPI? (Note that > updating the version should be an explicit step, as it is today, but the file > should be identical to what’s on PyPI, right? And a urlretrieve is easier > than pulling from a git repo.) I think the primary original rationale for having the pip wheel and its dependencies checked into the cpython repo was so that users would be able to install pip even if they did not have an Internet connection. But perhaps that requirement can be relaxed a bit if we say that the necessary wheels are vendored into all of our downloadable release items, that is, included in the packaging of source release files (the various tarballs) and the Windows and macOS binary installers. The main change would likely be making ensurepip a bit smarter to download if the bundled wheels are not present in the source directory. Assuming that people building from a cpython repo need to have a network connection if they want to run ensurepip, at least for the first time, is probably not an onerous requirement. -- Ned Deily n...@python.org -- [] ___ 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] [RELEASE] Python 3.6.5 is now available
Python 3.6.5 is now available. 3.6.5 is the fifth maintenance release of Python 3.6, which was initially released in 2016-12 to great interest. Detailed information about the changes made in 3.6.5 can be found in its change log. You can find Python 3.6.5 and more information here: https://www.python.org/downloads/release/python-365/ See the "What’s New In Python 3.6" document for more information about features included in the 3.6 series. Detailed information about the changes made in 3.6.5 can be found in the change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-5-final Attention macOS users: as of 3.6.5, there is a new additional installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default variant in future releases. Check it out! The next maintenance release is expected to follow in about 3 months, around the end of 2018-06. Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation: https://www.python.org/psf/ -- Ned Deily n...@python.org -- [] ___ 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] [RELEASE] Python 3.7.0b3 is now available for testing
On behalf of the Python development community and the Python 3.7 release team, I'm happy to announce the availability of Python 3.7.0b3. b3 is the third of four planned beta releases of Python 3.7, the next major release of Python, and marks the end of the feature development phase for 3.7. You can find Python 3.7.0b3 here: https://www.python.org/downloads/release/python-370b3/ Among the new major new features in Python 3.7 are: * PEP 538, Coercing the legacy C locale to a UTF-8 based locale * PEP 539, A New C-API for Thread-Local Storage in CPython * PEP 540, UTF-8 mode * PEP 552, Deterministic pyc * PEP 553, Built-in breakpoint() * PEP 557, Data Classes * PEP 560, Core support for typing module and generic types * PEP 562, Module __getattr__ and __dir__ * PEP 563, Postponed Evaluation of Annotations * PEP 564, Time functions with nanosecond resolution * PEP 565, Show DeprecationWarning in __main__ * PEP 567, Context Variables Please see "What’s New In Python 3.7" for more information. Additional documentation for these features and for other changes will be provided during the beta phase. https://docs.python.org/3.7/whatsnew/3.7.html Beta releases are intended to give you the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage you to test your projects with 3.7 during the beta phase and report issues found to https://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 (2018-05-21). Our goal is have no ABI changes after beta 3 and no code changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.7 as possible during the beta phase. Attention macOS users: there is a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default version when 3.7.0 releases. Check it out! We welcome your feedback. As of 3.7.0b3, the legacy 10.6+ installer also includes a built-in Tcl/Tk 8.6. 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.7 will be 3.7.0b4, currently scheduled for 2018-04-30. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@python.org -- [] ___ 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] Python Bug Tracker
On Apr 4, 2018, at 07:21, Agnostic Dev wrote: > Apologies if this is not the correct place to report this, but I am seeing > outages on bugs.python.org. > I am in the Chicago area so maybe this is a regional issue or possibly the > site is being update, but I wanted to report it. You are not alone. There have been intermittent TLS connection issues with bugs.python.org for some time now. The issue is being tracked here: https://github.com/python/psf-infra-meta/issues/4 -- Ned Deily n...@python.org -- [] ___ 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] Python Bug Tracker
On Apr 4, 2018, at 12:59, Ned Deily wrote: > On Apr 4, 2018, at 07:21, Agnostic Dev wrote: >> Apologies if this is not the correct place to report this, but I am seeing >> outages on bugs.python.org. >> I am in the Chicago area so maybe this is a regional issue or possibly the >> site is being update, but I wanted to report it. > You are not alone. There have been intermittent TLS connection issues with > bugs.python.org for some time now. The issue is being tracked here: > > https://github.com/python/psf-infra-meta/issues/4 Ah, but beyond that, I see now that bugs.python.org had a major outage earlier today. Should be OK now. -- Ned Deily n...@python.org -- [] ___ 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] gdb support could use some love
There are a bunch of open issues regarding gdb support including one with a PR in need of review for 3.6+. I imagine that there are duplicates at least among the more recent open issues. If you use and are familiar with the gdb macros, it would be really swell if you could take some time to review some of those open issues. Thanks! --Ned https://bugs.python.org/issue29673 https://github.com/python/cpython/pull/6126 https://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=gdb&%40columns=title&id=&%40columns=id&stage=&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=&priority=&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40group=&%40pagesize=50&%40startwith=0&%40sortdir=on&%40action=search -- Ned Deily n...@python.org -- [] ___ 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] gdb support could use some love
On Apr 5, 2018, at 12:35, Brett Cannon wrote: > On Thu, 5 Apr 2018 at 02:49 Skip Montanaro wrote: >> > There are a bunch of open issues regarding gdb support including one with >> > a PR in need of review for 3.6+. >> >> I rejected one (which assumed everyone now uses a python-aware gdb), >> commented on another (ceval.c-related name changes in several >> commands), and created a PR for third (documentation for the >> user-defined commands). Unfortunately, it's been so long since I >> contributed, I don't quite understand the ins and outs of the workflow >> anymore. In particular, I could find no way to add the "skip news" >> label. > There's a "Labels" section in the right-hand column. You can click "Labels" > and a drop-down of available and selected labels will show up. Modifying GitHub Labels is only available to people with commit privs and, IIRC, Skip asked to drop his commit privs a few years ago (although I'm sure we would all be happy to welcome him back!). > I'm afraid someone might have to intervene here: > > https://github.com/python/cpython/pull/6384 Thanks for pushing that! It's now merged. -- Ned Deily n...@python.org -- [] ___ 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] gdb support could use some love
On Apr 5, 2018, at 14:48, Terry Reedy wrote:
> On 4/5/2018 5:47 AM, Skip Montanaro wrote:
>>> There are a bunch of open issues regarding gdb support including one with a
>>> PR in need of review for 3.6+.
>> I rejected one (which assumed everyone now uses a python-aware gdb),
>> commented on another (ceval.c-related name changes in several
>> commands), and created a PR for third (documentation for the
>> user-defined commands). Unfortunately, it's been so long since I
>> contributed, I don't quite understand the ins and outs of the workflow
>> anymore. In particular, I could find no way to add the "skip news"
>> label. I'm afraid someone might have to intervene here:
>> https://github.com/python/cpython/pull/6384
>
> You created the PR from your local python repository master branch. I have
> done this, with negative consequences. I believe you will find life with git
> easier if you never edit your master branch, or at least, never make local
> commits to it, and only commit to and create PRs from special-purpose patch
> branches, as described in the devguide.
That's a good observation, Terry. The main problem is that, when a core
developer merges the PR from your local repo to the main python/cpython repo,
we do a squash merge which means that the change or changes committed in the
python/cpython and included in the PR will end up with a single new hash id
that differs from what you originally committed in your cpython fork. So the
next time you pull to your cpython fork (conventionally "origin") from the main
cpython repo ("upstream"), there will be a conflict on the "normal" branch,
i.e. master, 3.7, etc, requiring a merge or rebase, but you don't want to do
that since the change is already upstream.
Once the PR is merged into the main cpython repo, you can fix the problem by
force removing the original commit(s) from the "normal" branch in your forked
repo. See for example:
https://stackoverflow.com/questions/9646167/clean-up-a-fork-and-restart-it-from-the-upstream
--
Ned Deily
n...@python.org -- []
___
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] Can't open standard streams with "a"
On Apr 6, 2018, at 12:06, Skip Montanaro wrote: > [...] > https://bugs.python.org/issue27805 > [...] > Any chance of this getting into 3.7 or will a fix have to wait for 3.8 > at this point? (I'm guessing "no" as I don't see a patch.) It seems like most commenters on the issue consider the behavior to be a bug so a case could be made for a fix to go into a maintenance release, not just a feature release. But, obviously, someone needs to produce a PR for review first. -- Ned Deily n...@python.org -- [] ___ 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] Soliciting comments on the future of the cmd module (bpo-33233)
In https://bugs.python.org/issue33233, I have proposed considering deprecation for the cmd module: "The cmd module in the standard library has languished for many years. In the mean time, third-party replacements for it have arisen. Perhaps the most popular is cmd2 which seems to be actively maintained, provides upward compatibility from cmd along with many desirable new features, and is permissively licensed. I suggest we consider at a minimum adding a "See also:" note referencing cmd2 to the cmd documentation in the Standard Library document, similar to what we do for the third-party "requests" module in the "urllib.request" documentation. We could be even bolder and officially deprecate "cmd" and consider closing open enhancement issues for it on b.p.o." What triggered this suggestion is that Oz Tiram opened an enhancement request for cmd with suggested code (https://bugs.python.org/issue33227) that implements a feature already in cmd2. As I replied there, it seems to me to be almost a disservice to our users to add piecemeal enhancements to cmd at this point when it is essentially unmaintained and a superior alternative exists - that's assuming a core developer stepped up to shepherd the proposed change. I don't have a strong feeling one way or another about the change but I think this might be one instance where we can and should make a decision to prioritize our limited volunteer resources and acknowledge the current state of affairs re cmd. We've done similar things with other standard library modules in the past. If you have an opinion about either recommending cmd2 in the cmd docs and/or deprecating cmd in 3.8, please comment on https://bugs.python.org/issue33233. Thanks! --Ned https://docs.python.org/3.8/library/cmd.html https://pypi.org/project/cmd2/ https://cmd2.readthedocs.io/ =- Ned Deily n...@python.org -- [] ___ 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] Soliciting comments on the future of the cmd module (bpo-33233)
Thanks for everyone's interest but, please, let's keep the discussion in one place as originally requested: > If you have an opinion about either recommending cmd2 in the cmd docs and/or > deprecating cmd in 3.8, please comment on https://bugs.python.org/issue33233. You'll find some answers to some of these questions there already. -- Ned Deily n...@python.org -- [] ___ 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] PEP 572: Assignment Expressions
On Apr 23, 2018, at 18:04, Tim Peters wrote: > However, against "as" is that its current use in "with" statements > does something quite different: > >with f() as name: > > does not bind the result of `f()` to `name`, but the result of > `f().__enter__()`. Whether that "should be" fatal, I don't know, but > it's at least annoying ;-) Prior art: COBOL uses "GIVING", as in: ADD x, y GIVING z No need to re-invent the wheel ;) -- Ned Deily n...@python.org -- [] ___ 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] IMPORTANT - final 3.7.0 beta cutoff!
Just a reminder that 3.7.0b4 is almost upon us. Please get your feature fixes, bug fixes, and documentation updates in before 2018-04-30 ~23:59 Anywhere on Earth (UTC-12:00). That's about 16 hours from now. IMPORTANT: We are now in the final phase of 3.7.0. Tomorrow's 3.7.0b4 is the final beta planned for 3.7.0. After tomorrow, the next planned release is the 3.7.0 release candidate, on 2018-05-21, for final testing. Our goal is to have no changes between the release candidate and final; after rc1, changes applied to the 3.7 branch will be released in 3.7.1. Between now and the rc1 cutoff, please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Also, during the time leading up to the release candidate, we will be completing the What's New in 3.7 document. As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You should now be treating the 3.7 branch as if it were already released and in maintenance mode. That means you should only push the kinds of changes that are appropriate for a maintenance release: non-ABI-changing bug and feature fixes and documentation updates. If you find a problem that requires an ABI-altering or other significant user-facing change (for example, something likely to introduce an incompatibility with existing users' code or require rebuilding of user extension modules), please make sure to set the b.p.o issue to "release blocker" priority and describe there why you feel the change is necessary. If you are reviewing PRs for 3.7 (and please do!), be on the lookout for and flag potential incompatibilities (we've all made them). Thanks again for all of your hard work towards making 3.7.0 yet another great release - coming to a website near you on 06-15! --Ned -- Ned Deily n...@python.org -- [] ___ 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] [RELEASE] Python 3.7.0b4, final 3.7 beta, now available for testing
Python 3.7.0b4 is the final beta preview of Python 3.7, the next feature release of Python. Beta releases are intended to give you the opportunity to test new features and bug fixes and to prepare your projects to support the new feature release. We strongly encourage you to test your projects with 3.7 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. Please keep in mind that this is a preview release and its use is not recommended for production environments. Attention macOS users: there is now a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default version when 3.7.0 releases. Check it out! The next preview release will be the release candidate and is planned for 2018-05-21 followed by the official release of 3.7.0, planned for 2018-06-15. You can find Python 3.7.0b4 and more information here: https://www.python.org/downloads/release/python-370b4/ -- Ned Deily n...@python.org -- [] ___ 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] Python linkage on macOS
On May 4, 2018, at 08:10, Ray Donnelly wrote: > On Fri, May 4, 2018 at 11:00 AM, Antoine Pitrou wrote: >> On Fri, 04 May 2018 00:21:54 + >> Ray Donnelly wrote: >>> Anyway, it is obviously safer for us to do what upstream does and I will >>> try to post some benchmarks of static vs shared to the list so we can >>> discuss it. >> I have no idea what our default builds do on macOS, I'll let Ned Deily >> or another mac expert answer (changing the topic in the hope he notices >> this subthread :-)). > And thanks for doing this. For the benchmarks I think I should build > Python 3.6.5 (or would 3.7.0b4 be better?) from pyperformance built > each way using the AD scripts and reply here with the results. If I do > not get it done today then I hope to get them ready by Monday. The macOS python interpreters provided by python.org binary installers have always (for a very long time of always) been built as shared, in particular the special macOS framework build configuration. It would be very interesting to do Apple to Apple comparisons of shared vs static builds on macOS. I would look forward to seeing any results you have, Ray, and your methodology. Static builds is on my list of things to look at for 3.8. -- Ned Deily n...@python.org -- [] ___ 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] FINAL WEEK FOR 3.7.0 CHANGES!
This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be to have no changes between the release candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Those of us who are participating in the development sprints at PyCon US 2018 here in Cleveland can feel the excitement building as we work through the remaining issues, including completing the "What's New in 3.7" document and final feature documentation. (We wish you could all be here.) As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You should now be treating the 3.7 branch as if it were already released and in maintenance mode. That means you should only push the kinds of changes that are appropriate for a maintenance release: non-ABI-changing bug and feature fixes and documentation updates. If you find a problem that requires an ABI-altering or other significant user-facing change (for example, something likely to introduce an incompatibility with existing users' code or require rebuilding of user extension modules), please make sure to set the b.p.o issue to "release blocker" priority and describe there why you feel the change is necessary. If you are reviewing PRs for 3.7 (and please do!), be on the lookout for and flag potential incompatibilities (we've all made them). Thanks again for all of your hard work towards making 3.7.0 yet another great release - coming to a website near you on 06-15! Release Managerly Yours, --Ned https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@python.org -- [] ___ 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] Changes to configure.ac, auto-detection and related build issues
On May 15, 2018, at 01:58, Eitan Adler wrote: > On Monday, 14 May 2018, Victor Stinner wrote: > Hi Eitan, > > 2018-05-15 0:01 GMT-04:00 Eitan Adler : > > I am working on updating, fixing, or otherwise changing python's > > configure.ac. This work is complex, (...) > > Is your work public? Is there an open issue on bugs.python.org or an > open pull request? > > I'm opening bugs and PRs as I Go. Some examples are: > > https://github.com/python/cpython/commit/98929b545e86e7c7296c912d8f34e8e8d3fd6439 > https://github.com/python/cpython/pull/6845 > https://github.com/python/cpython/pull/6848 > https://github.com/python/cpython/pull/6849 > https://bugs.python.org/issue33485 > > And so on > > > If not, would you mind to at least describe the changes that you plan to do? > > > Please feel free to tag me in > > related PRs or bugs or emails over the next few weeks. > > Hopefully, we only rarely need to modify configure.ac > > I'm primarily worried about breaking arcane platforms I don't have direct > access to. Hi, Eitan! As you recognize, it is always a bit dangerous to modify configure.ac and friends as we do support so many platforms and configuration and downstream users try combinations that we don't claim to test or support. So, we try to be conservative about making changes there and do so only with good reason. So far, it's somewhat difficult for me to understand what you are trying to accomplish with the changes you've noted so far other than various cosmetic cleanups. It is also difficult to properly review a bunch of small PRs that modify the same configuration files and especially without an overall tracking issue. For most of this to move forward, I think you should create or adapt at least one b.p.o issue to describe what changes you are suggesting and why and how they apply to our various platforms and then consolidate PRs under that PR. Don't be surprised if the PRs don't get much attention right away as we're busy at the moment trying to get 3.7.0 out the door. And it would be best to avoid including generated files (like configure vs configure.ac) in new PRs as that will only add to the likelihood of merge conflicts and review complexity. Thanks! - Ned Deily n...@python.org -- [] ___ 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] What is the rationale behind source only releases?
On May 16, 2018, at 00:35, Alex Walters wrote:
> In the spirit of learning why there is a fence across the road before I tear
> it down out of ignorance [1], I'd like to know the rationale behind source
> only releases of cpython. I have an opinion on their utility and perhaps an
> idea about changing them, but I'd like to know why they are done (as opposed
> to source+binary releases or no release at all) before I head over to
> python-ideas. Is this documented somewhere where my google-fu can't find
> it?
The Python Developer's Guide has a discussion of the lifecycle of cPython
releases here:
https://devguide.python.org/#status-of-python-branches
The ~short answer is that we produce source+binary (Windows and macOS binary
installers) artifacts for release branches in "bugfix" (AKA "maintenance") mode
(currently 3.6 and 2.7) as well as during the later stages of the
in-development phase for future feature releases ("prerelease" mode) (currently
3.7); we produce only source releases for release branches in "security" mode.
After the initial release of a new feature branch (for example, the upcoming
3.7.0 release), we will continue to support the previous release branch in
bugfix mode for some overlapping period of time. So, for example, the current
plan is to support both 3.7.x and 3.6.x (along with 2.7.x) in bugfix mode,
releasing both source and binary artifacts for about six months after the 3.7.0
release. At that point, 3.6.x will transition to security-fix-only mode, where
we will only produce releases on an as-needed basis and only in source form.
Currently, 3.5 and 3.4 are also in security-fix-only mode. Eventually, usually
five years after its initial release, a release branch will reach end-of-life:
the branch will be frozen and no further issues for that release branch will be
accepted nor will fixes be produced by Python Dev. 2.7 is a special case, with
a greatly extended bugfix phase; it will proceed directly to end-of-life status
as of 2020-01-01.
There is more information later elsewhere in the devguide:
https://devguide.python.org/devcycle/
and in the release PEPs linked in the Status of Python Branches section.
Hope that helps!
--
Ned Deily
n...@python.org -- []
___
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] What is the rationale behind source only releases?
On May 17, 2018, at 04:24, Paul Moore wrote: > On 17 May 2018 at 04:46, Alex Walters wrote: >>> 1. Producing binaries (to the quality we normally deliver - I'm not >>> talking about auto-built binaries produced from a CI system) is a >>> chunk of extra work for the release managers. >> >> This is actually the heart of the reason I asked the question. CI tools are >> fairly good now. If the CI tools could be used in such a way to make the >> building of binary artifacts less of a burden on the release managers, would >> there be interest in doing that, and in the process, releasing binary >> artifact installers for all security update releases. >> >> My rationale for asking if its possible is... well.. security releases are >> important, and it's hard to ask Windows users to install Visual Studio and >> build python to use the most secure version of python that will run your >> python program. Yes there are better ideal solutions (porting your code to >> the latest and greatest feature release version), but that’s not a zero >> burden option either. >> >> If CI tools just aren't up to the task, then so be it, and this isn't >> something I would darken -ideas' door with. > > I honestly don't know if we're at a point where an auto-built security > release would be sufficient and/or useful. That's mostly a question > for the release manager(s). One sticking point might be that I believe > the Windows installers (at least) are signed, and only the release > managers have the signing key. It's probably *not* OK to leave the > security releases unsigned ;-) So there would be a key management > issue to address there. IMO, the idea of having either the current CI system or a third party produce binary artifacts for Python releases to be downloadable from python.org is a non-starter for lots of reasons, primarily because of the security risks. The release team *could* produce those artifacts for releases in security mode and, while it would be some extra work, there are so few of them. The question is should we. Once a release moves from bugfix/maintenance mode to security mode, in some ways we are doing a disservice to our users to encourage them to not upgrade to a more recent maintained release. Release branches in security mode do not get any fixes other than, based on past experience, at most a small number of security issues that might arise. In particular, security mode release branches receive no platform-support fixes to support newer OS releases and/or newer hardware support and receive no buildbot testing. Security mode releases today are really for downstream distributors and DIYers who are comfortable building and maintaining their own versions of software. -- Ned Deily n...@python.org -- [] ___ 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] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
Elvis has been working on the What’s New doc at the sprints this week. He should be checking in his edits soon. Stay tuned! -- Ned Deily n...@python.org -- [] > On May 17, 2018, at 14:31, Serhiy Storchaka wrote: > > 15.05.18 14:51, Ned Deily пише: >> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your >> feature fixes, bug fixes, and documentation updates in before >> 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days >> from now. We will then tag and produce the 3.7.0 release candidate. >> Our goal continues been to be to have no changes between the release >> candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 >> BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are >> no critical problems outstanding and that documentation for new >> features in 3.7 is complete (including NEWS and What's New items), and >> that 3.7 is getting exposure and tested with our various platorms and >> third-party distributions and applications. Those of us who are >> participating in the development sprints at PyCon US 2018 here in >> Cleveland can feel the excitement building as we work through the >> remaining issues, including completing the "What's New in 3.7" >> document and final feature documentation. (We wish you could all be >> here.) > > The "What's New in 3.7" document is still not complete. Actually it is far > completing. In the previous releases somebody made a thoughtful review of the > NEWS file and added all significant changes in What's New, and also removed > insignificant entries, reorganized entries, fixed errors, improved wording > and formatting. Many thanks to Martin Panter, Elvis Pranskevichus, Yury > Selivanov, R. David Murray, Nick Coghlan, Antoine Pitrou, Victor Stinner and > others for their great work! But seems in 3.7 this documents doesn't have an > editor. > ___ 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] 3.7.0rc1 deadline extended two days to 2018-05-23 AOE [Re: FINAL WEEK FOR 3.7.0 CHANGES!]
We are going to extend for 48 hours the deadline for 3.7.0rc1, that is, until 2018-05-23 23:59 AOE. While we have made tremendous progress towards the release candidate over the past week especially with the huge efforts at the PyCon US Sprints, we still have some important issues to resolve. A stumbling block has been the increased instability in the test suite, primarily in test_asyncio, which has caused delays in merging PRs due to intermittent failures in CI test runs and which has caused widespread buildbot failures. Another factor is that this weekend and Monday are public holidays in many countries, something I did not take into account when drawing up the schedule. (Note that next weekend is a major public holiday in the USA.) So let's plan on using the extra two days to work through the remaining release blockers. Thanks again! --Ned On May 15, 2018, at 07:51, Ned Deily wrote: > This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your > feature fixes, bug fixes, and documentation updates in before > 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days > from now. We will then tag and produce the 3.7.0 release candidate. > Our goal continues been to be to have no changes between the release > candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 > BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are > no critical problems outstanding and that documentation for new > features in 3.7 is complete (including NEWS and What's New items), and > that 3.7 is getting exposure and tested with our various platorms and > third-party distributions and applications. Those of us who are > participating in the development sprints at PyCon US 2018 here in > Cleveland can feel the excitement building as we work through the > remaining issues, including completing the "What's New in 3.7" > document and final feature documentation. (We wish you could all be > here.) > > As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You > should now be treating the 3.7 branch as if it were already released > and in maintenance mode. That means you should only push the kinds of > changes that are appropriate for a maintenance release: > non-ABI-changing bug and feature fixes and documentation updates. If > you find a problem that requires an ABI-altering or other significant > user-facing change (for example, something likely to introduce an > incompatibility with existing users' code or require rebuilding of > user extension modules), please make sure to set the b.p.o issue to > "release blocker" priority and describe there why you feel the change > is necessary. If you are reviewing PRs for 3.7 (and please do!), be on > the lookout for and flag potential incompatibilities (we've all made > them). > > Thanks again for all of your hard work towards making 3.7.0 yet > another great release - coming to a website near you on 06-15! > > Release Managerly Yours, > --Ned > > https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@python.org -- [] ___ 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] Procedure for adding new public C API
On May 21, 2018, at 08:41, Serhiy Storchaka wrote: > Please don't forgot to perform the following steps when add a new public C > API: > [...] Perhaps this should be added to the Python Developer's Guide? -- Ned Deily n...@python.org -- [] ___ 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 fork lacks a 3.7 branch - can I create it somehow?
On May 22, 2018, at 18:51, Skip Montanaro wrote: > [Ivan Pozdeev]: >> You don't really need copies of official branches on your Github fork >> if you're not a maintainer for these branches. > I explicitly wanted to run with 3.7 in the run-up to release. On that > branch, the built ./python reports 3.7.0b4+ at startup. Master tells me > 3.8.0a0 on startup. Since my local repo is a clone of my fork, it made > sense to me to have a 3.7 branch on my fork which I could switch to. Am I > only nutcase who thinks that might be mildly useful? (Or that if I want to > test an application across multiple versions using tox that it makes sense > to have pre-release visibility of point releases.) No, what you what you want to do makes perfect sense. It sounds like Ivan is used to projects with a somewhat different workflow than ours. We don't have "branch maintainers"; core-developers are responsible themselves for merging changes into all appropriate branches. While these days some of the backporting can be semi-automated, thanks to the backport bot, but it is still up to the core developer to decide whether a change can and should be backported, so having all active branches available in a local repo is a pretty much a necessity. As always, the Developer's Guide should be able to answer questions like this: https://devguide.python.org/devcycle/ -- Ned Deily n...@python.org -- [] ___ 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] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On May 23, 2018, at 07:45, Serhiy Storchaka wrote: > 15.05.18 14:51, Ned Deily пише: >> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your >> feature fixes, bug fixes, and documentation updates in before >> 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days >> from now. We will then tag and produce the 3.7.0 release candidate. >> Our goal continues been to be to have no changes between the release >> candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 >> BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are >> no critical problems outstanding and that documentation for new >> features in 3.7 is complete (including NEWS and What's New items), and >> that 3.7 is getting exposure and tested with our various platorms and >> third-party distributions and applications. Those of us who are >> participating in the development sprints at PyCon US 2018 here in >> Cleveland can feel the excitement building as we work through the >> remaining issues, including completing the "What's New in 3.7" >> document and final feature documentation. (We wish you could all be >> here.) > Is it possible to add yet one beta instead? > > CI was broken for few latest days, tests are not passed on my computer still > (and fail on some buildbots), updating What's New exposed new features which > need additional testing (and maybe fixing or reverting), and I'm not > comfortable about some changes which would be harder to fix after the release. it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures. We have another 24 hours until rc1 was planned to be tagged. Let's keep working on the known issues and we will make a decision then. -- Ned Deily n...@python.org -- [] ___ 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] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On May 23, 2018, at 09:13, Ned Deily wrote: > On May 23, 2018, at 07:45, Serhiy Storchaka wrote: >> Is it possible to add yet one beta instead? >> CI was broken for few latest days, tests are not passed on my computer still >> (and fail on some buildbots), updating What's New exposed new features which >> need additional testing (and maybe fixing or reverting), and I'm not >> comfortable about some changes which would be harder to fix after the >> release. > it is possible but there's no point in doing either another beta or a release > candidate until we understand and address the current blocking issues, like > the major buildbot failures. We have another 24 hours until rc1 was planned > to be tagged. Let's keep working on the known issues and we will make a > decision then. An update: thanks to a lot of effort over the past day by a number of people (including Victor, Serhiy, Christian, Zach, and others I'm sure I'm forgetting - my apologies), we have addressed all of the "release blocker" issues and all but one of the persistent failures on the 3.7 stable buildbots. We should have the couple of remaining "deferred blockers" including the remaining stable buildbots in green status by later today. At that point, we will be ready to tag 3.7.0rc1 and begin producing the release candidate artifacts. So this *is* really your last chance: if you know of any true releasing blocking issues for 3.7.0, you have about 12 more hours to log it in the bug tracker as a "release blocker". I'll send out an email once we start the release manufacturing. Any merges to the 3.7 branch after that will be released in 3.7.1 which we tentatively are planning to ship sometime before the end of July (< 2018-07-31). If you do find a critical problem in 3.7.0rc1 that you think needs to be fixed in 3.7.0, please merge a fix into 3.7 (and other appropriate branches), leave the issue open and marked as "release blocker", and add a note why you think the fix needs to be cherry-picked into 3.7.0. More later today! --Ned P.S. To address a few of the earlier comments on this thread: Antoine: > Also there's https://bugs.python.org/issue33612 which appears quite critical. Resolved Victor: > Can someone please have a look at my socketserver change? Reviewed and merged Victor: > I looked at buildbots and I confirm that many of the 3.x buildbots are red: Yes, but it's the 3.7 buildbots that are of interest now, not the 3.x ones :) And, as noted above, I believe we have cleaned up (or will shortly) the remaining 3.7 stable buildbot failures. Coincidentally, we've also fixed some of the 3.x (master -> 3.8) buildbots. Victor: > Ah, Python doesn't compile on Windows anymore :-) Stale files on one of the Windows buildbots -> cleaned up -- Ned Deily n...@python.org -- [] ___ 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] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On May 24, 2018, at 07:26, Victor Stinner wrote: > 2018-05-24 9:23 GMT+02:00 Ned Deily : >> Any merges to the 3.7 branch after >> that will be released in 3.7.1 which we tentatively are planning to >> ship sometime before the end of July (< 2018-07-31). > I recall that Python 3.6.0 was full of bugs, some functions like > os.waitpid() on Windows (if I recall correctly) were completely > broken. > > We can do our best to test as much as possible, hope that more and > more people use the "nightly" Python version to run their CI, but we > always miss bugs. We always get the most testers when the final x.y.0 > version is released. > > Why waiting two months to release bugfixes? We're not planning on waiting two months. First, 3.7.0 final is not planned to release until 2018-06-15; if necessary, there could be one or more emergency bug fixes in it. Second, "before the end of July (< 2018-07-31)" does not mean we have to wait until the end of July. If necessary, it could be near the beginning of the month, so closer to two weeks after the release. Right now, our focus should be on getting high-quality 3.7.0rc1 and 3.7.0 final releases out there to our users and then we can focus on what comes next. Getting close! -- Ned Deily n...@python.org -- [] ___ 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] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On May 24, 2018, at 11:35, Serhiy Storchaka wrote: > I have doubts about two issues. I feel the responsibility for them because I > had the opportunity to solve them before, but I lost it. [...] Serhiy, what are the bugs.python.org issue numbers for these? Are they marked as "release blocker"? -- Ned Deily n...@python.org -- [] ___ 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] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On May 24, 2018, at 12:26, Serhiy Storchaka wrote: > 24.05.18 19:02, Ned Deily пише: >> On May 24, 2018, at 11:35, Serhiy Storchaka wrote: >>> I have doubts about two issues. I feel the responsibility for them because >>> I had the opportunity to solve them before, but I lost it. >> [...] >> >> Serhiy, what are the bugs.python.org issue numbers for these? Are they >> marked as "release blocker"? > For docstring in AST: https://bugs.python.org/issue32911 > > Inada's patch looked complex (actually it mostly restored the code before his > previous change). We didn't know about IPython and we decided that it is not > worth to change this code at this stage (after beta2). And definitely it will > be later to do this after rc1. We have had many discussions about this issue earlier and, while there were arguments made for more than one approach, I believe we reached agreement that this was a deliberate incompatibility that we and our users could live with. The issue has been closed since 2018-03-18. At some point, we need to move on. However, if additional exposure downstream has identified significant new problems, then the issue should be re-opened and a specific proposal made. BTW, do we know what the iPython folks think about this? But there still seems to be disagreements about whether anything needs to be changed. As I commented yesterday, I *really* don't want to keep revisiting this but I am not going to make a technical call. Without an open "release blocker" issue, though, nothing is going to change for 3.7.0rc1. If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue. > For pickling of typing types: https://bugs.python.org/issue32873 > > Ivan fixed cases supported before 3.7. They now are backward and forward > compatible. But cases not supported before 3.7 (like List[int]) now produce > fragile pickles. That issue was closed by Ivan and there have been no comments on it since 2018-04-04. I'll defer to his recent reply in this thread. -- Ned Deily n...@python.org -- [] ___ 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] 3.7.0rc1 Delayed [was] FINAL WEEK FOR 3.7.0 CHANGES!
On May 24, 2018, at 03:23, Ned Deily wrote: > On May 23, 2018, at 09:13, Ned Deily wrote: >> On May 23, 2018, at 07:45, Serhiy Storchaka wrote: >>> Is it possible to add yet one beta instead? >>> CI was broken for few latest days, tests are not passed on my computer >>> still (and fail on some buildbots), updating What's New exposed new >>> features which need additional testing (and maybe fixing or reverting), and >>> I'm not comfortable about some changes which would be harder to fix after >>> the release. >> it is possible but there's no point in doing either another beta or a >> release candidate until we understand and address the current blocking >> issues, like the major buildbot failures. We have another 24 hours until >> rc1 was planned to be tagged. Let's keep working on the known issues and we >> will make a decision then. > An update: thanks to a lot of effort over the past day by a number of > people (including Victor, Serhiy, Christian, Zach, and others I'm sure > I'm forgetting - my apologies), we have addressed all of the "release > blocker" issues and all but one of the persistent failures on the 3.7 > stable buildbots. We should have the couple of remaining "deferred > blockers" including the remaining stable buildbots in green status by > later today. At that point, we will be ready to tag 3.7.0rc1 and begin > producing the release candidate artifacts. Further update: some good news and some changes. The good news is that we have resolutions for all of the previous release and deferred blockers. Thanks to a number of people for continuing to help get the remaining stable buildbot issues taken care of along with some lingering bugs. The not-quite-as-good news is that we have had more discussions about some unexpected incompatibilities that have shown up with downstream user testing with the AST docstrings changes in place (see bpo-32911). We have had some previous discussions about the expected user impact and, earlier in the beta phase, I encouraged us to stay the course with the feature as implemented. But I am now persuaded that we owe it to our users to take one more look at this to make sure we do not force them to make changes for 3.7 and then once again for 3.8. More details are in the bug tracker issue; I strongly encourage those of us who have been involved with this to "vote" there on the proposal to either (A) proceed with the release of the current implementation in 3.7.0 or (B) revert the feature in 3.7.0 and retarget for 3.8. Should the consensus be to revert (B), we will plan to have one more fast-track beta release (b5) prior to the release candidate, in order to allow downstream users to tes t their projects with the removal. PLEASE, keep the discussion about this on the bug tracker (and not here!) and keep it brief so we can move forward quickly. Because of the upcoming 3-day holiday weekend in some countries, I have set Tue 2018-05-29 18:00 UTC as a cutoff for "voting" but, if a clear consensus emerges earlier, we will likely cut the discussion short. So chime in now on the bug tracker if you have a stake in this issue. https://bugs.python.org/issue32911 This does mean that yesterday's "last chance" has been extended a bit, at most a few days. I will let you know as soon as we have made a decision about the feature and will provide updated 3.7.0 schedule info at that time. --Ned -- Ned Deily n...@python.org -- [] ___ 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] macOS: minimum supported version?
On May 28, 2018, at 05:05, Victor Stinner wrote: > Ned Deily closed old bugs reported on the macOS Tiger buildbot, since > this buildbot has been retired 3 months ago (the builders are still > visible online, but last builds were 3 months ago). Perhaps Zach or someone else can remove them from the list. > It seems like the oldest macOS buildbot is now macOS El Capitan (macOS > 10.11, 2015). Does it mean that the minimum officially supported macOS > version is now macOS 10.11 El Capitain? One way to answer that question is to look at the macOS versions we support with python.org installers. If you look at the current download pages for current releases, you'll see we provide installers that support macOS versions from 10.6 (Snow Leopard) theough the current 10.13 (High Sierrs) so we definitely support those versions. Earlier versions are supported on a best-effort basis. -- Ned Deily n...@python.org -- [] ___ 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] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
On May 28, 2018, at 13:19, Nathaniel Smith wrote: > > Isn't that what happens if someone enables the check box at Repository > Settings -> Branches -> Branch protection rules -> [pick a branch] -> Require > branches to be up to date before merging ? Hmm, for some some reason, it appears that, at the moment, the 2.7, 3.4, and 3.5 branches have that option set, while 3.6, 3.7, and master don't. I'm not sure how we got to that state. Any other reasons to prefer on versus off? On Mon, May 28, 2018, 09:11 Brett Cannon wrote: > Ryan is right that there's no special setting in GitHub at least which would > make merging more strict for certain branches as you're describing. > > On Mon, 28 May 2018 at 07:06 Ryan Gonzalez wrote: > AFAIK there's no setting like this available, and I've done this many times > on other repos with no trouble. Maybe it could be a GitHub bug? > > On May 28, 2018 4:59:03 AM Victor Stinner wrote: > > > Hi, > > > > Since one or two weeks, I noticed that it's difficult to merge pull > > requests into the 2.7 branch. If a different commit is pushed in the > > meanwhile (if a different PR has been merged), the 2.7 branch diverges > > and the PR is immediately marked as "This branch is out-of-date with > > the base branch" and the "Squash and Merge" button is disabled (grey). > > > > For example my PR https://github.com/python/cpython/pull/7120 which > > changes Lib/test/regrtest.py cannot be merged because a commit > > touching the documentation (Doc/ directory) has been merged after I > > posted my PR and before the CI completed. > > > > I don't see the same behavior on the master branch. Is the 2.7 branch > > configured as more strict? -- Ned Deily n...@python.org -- [] ___ 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] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
On May 28, 2018, at 17:42, Victor Stinner wrote: > 2018-05-28 19:47 GMT+02:00 Ned Deily : >> Hmm, for some some reason, it appears that, at the moment, the 2.7, 3.4, and >> 3.5 branches have that option set, while 3.6, 3.7, and master don't. I'm >> not sure how we got to that state. Any other reasons to prefer on versus >> off? > > As I wrote, it became very difficult to merge any PR on 2.7 because of > that. We all run a race to be the first one to merge a change into > 2.7. The next one will get a "conflict" even if the merged commit is > unrelated (as I described: two different unrelated directories). > > Please use the same configuration for 2.7, 3.6, 3.7 and master branches! Sounds reasonable. I've updated the 2.7 configuration to match the others and not require the PR branch be up to date before merging, meaning the CI test might be against an older view of the branch. If it proves to be a problem, we can revisit it for all of the branches. I am not going to change the settings for 3.5 and 3.4 as they are in security-fix mode and only their release manager can merge changes for those. -- Ned Deily n...@python.org -- [] ___ 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] Python 3.7.0 updated schedule: beta 5 cutoff in 24 hours
Here's an update on the 3.7.0 endgame. As announced several days ago, we made the difficult decision to hold back on 3.7.0rc1 due primarily to some unexpected difficulties being seen downstream due to changes in how docstrings were handled in 3.7.0 (details below). After some discussions about various approaches, we agreed on a solution that should minimize downstream impact without losing all the benefits of the existing 3.7 changes. Thanks to a lot of work over the long weekend by a number of people that solution is now merged in the 3.7 branch. In parallel with that, a number of people spent a lot of time looking at CI and buildbot test failures, mostly intermittent ones. As a result, a number of actual bugs were fixed and also problems with a number of tests were fixed which should make the test suite more robust. All this is good news. Primarily because of the important user-facing changes made with the AST docstring API, I feel we need to do one more beta release before we are ready for the release candidate. About 24 hours from now, approximately 2018-05-30 18:00UTC, I plan to tag and start manufacturing 3.7.0b5. This will be a short beta cycle, aimed mainly at users of the AST API so they can recheck that their packages with 3.7.0. Assuming all goes well, we will then plan to tag 3.7.0rc1 on 2018-06-11 and 3.7.0 final on 2017-06-27. I am also rescheduling 3.6.6rc1 and 3.6.6 final to match the new 3.7.0 dates. All fixes that have been merged into the 3.7 branch as of cutoff tomorrow will be in 3.7.0b5 and fixes merged afterwards will be in 3.7.0rc1 up to its cutoff point. After 3.7.0rc1 cutoff, 3.7 merges will appear in 3.7.1. Please continue to exercise diligence when deciding whether a change is appropriate for 3.7; as a rule of thumb, treat the 3.7 branch as if it were already released and in maintenance mode. Please also pay attention to CI test failures and buildbot test failures and see if you can help resolve them. I want to thank everyone who has been involved so far in helping us through this endgame and who have given up their personal time to work on making Python better. I, for one, am deeply grateful. 2018-05-30 3.7.0b5 2018-06-11 3.7.0rc1 & 3.6.6rc1 2018-06-27 3.7.0final & 3.6.6final --Ned On May 25, 2018, at 01:33, Ned Deily wrote: > On May 24, 2018, at 03:23, Ned Deily wrote: >> On May 23, 2018, at 09:13, Ned Deily wrote: >>> On May 23, 2018, at 07:45, Serhiy Storchaka wrote: >>>> Is it possible to add yet one beta instead? >>>> CI was broken for few latest days, tests are not passed on my computer >>>> still (and fail on some buildbots), updating What's New exposed new >>>> features which need additional testing (and maybe fixing or reverting), >>>> and I'm not comfortable about some changes which would be harder to fix >>>> after the release. >>> it is possible but there's no point in doing either another beta or a >>> release candidate until we understand and address the current blocking >>> issues, like the major buildbot failures. We have another 24 hours until >>> rc1 was planned to be tagged. Let's keep working on the known issues and >>> we will make a decision then. >> An update: thanks to a lot of effort over the past day by a number of >> people (including Victor, Serhiy, Christian, Zach, and others I'm sure >> I'm forgetting - my apologies), we have addressed all of the "release >> blocker" issues and all but one of the persistent failures on the 3.7 >> stable buildbots. We should have the couple of remaining "deferred >> blockers" including the remaining stable buildbots in green status by >> later today. At that point, we will be ready to tag 3.7.0rc1 and begin >> producing the release candidate artifacts. > Further update: some good news and some changes. > > The good news is that we have resolutions for all of the previous release and > deferred blockers. Thanks to a number of people for continuing to help get > the remaining stable buildbot issues taken care of along with some lingering > bugs. > > The not-quite-as-good news is that we have had more discussions about some > unexpected incompatibilities that have shown up with downstream user testing > with the AST docstrings changes in place (see bpo-32911). We have had some > previous discussions about the expected user impact and, earlier in the beta > phase, I encouraged us to stay the course with the feature as implemented. > But I am now persuaded that we owe it to our users to take one more look at > this to make sure we do not force them to make changes for 3.7 and then once > again for 3.8. More details are in the bug tracker issue; I strongly > encourage those of us who have been i
[Python-Dev] [RELEASE] Python 3.7.0b5 bonus beta!
A 3.7 update: Python 3.7.0b5 is now the final beta preview of Python 3.7, the next feature release of Python. 3.7.0b4 was intended to be the final beta but, due to some unexpected compatibility issues discovered during beta testing of third-party packages, we decided to revert some changes in how Python's 3.7 Abstract Syntax Tree parser deals with docstrings; 3.7.0b5 now behaves like 3.6.x and previous releases (refer to the 3.7.0b5 changelog for more information). **If your code makes use of the ast module, you are strongly encouraged to test (or retest) that code with 3.7.0b5, especially if you previously made changes to work with earlier preview versons of 3.7.0.** As always, please report issues found to bugs.python.org as soon as possible. Please keep in mind that this is a preview release and its use is not recommended for production environments. Attention macOS users: there is now a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default version when 3.7.0 releases. Check it out! The next (and final, we hope!) preview release will be the release candidate which is now planned for 2018-06-11, followed by the official release of 3.7.0, now planned for 2018-06-27. You can find Python 3.7.0b5 and more information here: https://www.python.org/downloads/release/python-370b5/ -- Ned Deily n...@python.org -- [] ___ 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] Unicode 11.0.0 released
On Jun 6, 2018, at 00:22, Benjamin Peterson wrote: > On Tue, Jun 5, 2018, at 12:17, MRAB wrote: >> Unicode 11.0.0 has been released. Will Python 3.7 be updated to it, or >> is it too late? > > https://github.com/python/cpython/pull/7439 will update 3.8. Generally, we've > considered updating the Unicode database to be a feature and not backported > updates to bugfix branches. Thus, tradition would seem to exclude Unicode > 11.0.0 from landing so late in 3.7's release cycle. That said, the update is > highly unlikely to break anything. It's up to Ned. I'd hate for 3.7 to fall behind in the emoji race :) Seriously, there are some important additions that will, no doubt, appear in platforms over the lifetime of 3.7 and the risk is very low. Thanks for pinging about it. https://github.com/python/cpython/pull/7470 -- Ned Deily n...@python.org -- [] ___ 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] 3.7.0rc1 and 3.6.6rc happening later today!
Short and sweet: thanks to a *lot* of work by a lot of people, we appear to be about ready to finally tag and manufacture the 3.7.0 release candidate! At the moment, we have no "release blocker" or "deferred blocker" issues open for 3.7 - a first! We also now have 21 out of 22 3.7 "production" buildbots consistently green or occasionally pink (meaning successful test retry) - also quite an accomplishment. (Only the 3.7 AIX PPC64 buildbot remains red but, since we really only support AIX on a "best effort" basis, we are not going to further delay 3.7.0 for it.) We have also had to make some tough decisions and defer some features to 3.8 and a few more complex bug resolutions to 2.7.1 or later. And releasing the "bonus beta", 3.7.0b5, resulted in some good feedback and squashing a few more issues. As you may recall, the most recently updated schedule calls for both 3.7.0rc1 and 3.6.6rc1 to be produced today, 2018-06-11, with the finals coming about two weeks later on 2018-06-27. I plan to start on 3.6.6rc1 in about 12 hours (around 22:00 UTC) with 3.7.0rc1 to follow soon thereafter. Feel free to use the remaining time to merge any last-minute documentation updates or minor bug fixes - but please do not break anything! When in doubt, ask. (I will be off-line for the next 8 hours or so.) After 3.7.0rc1 cutoff, new 3.7 merges will appear in 3.7.1, which should appear sometime next month (by the end of 2018-07). Likewise, new 3.6 merges will next appear in 3.6.7rc1, by the end of 2018-09. Please continue to exercise diligence when deciding whether a change is appropriate for 3.7; as a rule of thumb, treat the 3.7 branch as if it were already released and in maintenance mode. Please also pay attention to CI test failures and buildbot test failures and see if you can help resolve them. As always, if you think you may have found a critical problem at any time in either release candidate, please open (or reuse) an issue on bugs.python.org and mark it as "release blocker" priority. 3.7.0: here we come, thanks to you! --Ned -- Ned Deily n...@python.org -- [] ___ 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] 3.7.0rc1 and 3.6.6rc1 now tagged - on to final!
An update: 3.7.0rc1 and 3.6.6rc1 are now tagged and we now move on to the final stages for 3.7.0 and for 3.6.6. The source code has been shipped to our factory (in a tariff-free zone!) where the elves will produce the final bits for the release. They promise to be done soon so stay tuned for the release announcements later today. In the meantime, the 3.7 and 3.6 branches in the cpython repo are open for merges. As of the rc1 cutoffs (tags v3.7.0rc1 and v3.6.6rc1 in the cpython repo), expect merges to 3.7 to appear in 3.7.1 and merges to 3.6 to appear in 3.6.7. Please continue to treat the 3.7 branch as if it were already released and in maintenance mode. Please continue to pay attention to CI test failures and buildbot test failures and see if you can help resolve them. If you find something that may affect either final release, please make sure to open a new issue on bugs.python.org, or update an existing issue, and set the priority to "release blocker". As always, improving the documentation never ceases so keep those updates coming in. Prior to 3.7.0 final and 3.6.6 final, I will review doc changes that have been merged and consider cherry-picking them into the release materials. By the way, don't be fooled: if you build Python from the 3.7 branch at the moment, the version will be "3.7.0rc1+" but changes merged will be in 3.7.1; similarly for 3.6. The clock is now ticking: 15 days until the final releases. Please do what you can to encourage exposure and testing by ourselves and our downstream users. Once again, I want to thank everyone who has been involved so far in helping us through the 3.7 endgame and who have given up their personal time to work on making Python better. I remain deeply grateful. --Ned Upcoming dates: - 2018-06-27 3.7.0 final !!! and 3.6.6 final !! - 2018-07-xx 3.7.1 - 2018-09-xx 3.6.7 -- Ned Deily n...@python.org -- [] ___ 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] [RELEASE] Python 3.7.0rc1 and 3.6.6rc1 are now available
Python 3.7.0rc1 and 3.6.6rc1 are now available. 3.7.0rc1 is the final planned release preview of Python 3.7, the next feature release of Python. 3.6.6rc1 is the the release preview of the next maintenance release of Python 3.6, the current release of Python. Assuming no critical problems are found prior to *2018-06-27*, the scheduled release dates for 3.7.0 and 3.6.6, no code changes are planned between these release candidates and the final releases. These release candidates are intended to give you the opportunity to test the new features and bug fixes in 3.7.0 and 3.6.6 and to prepare your projects to support them. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that these are preview releases and, thus, their use is not recommended for production environments. Attention macOS users: there is now a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant will become the default version when 3.7.0 releases. Check it out! You can find these releases and more information here: https://www.python.org/downloads/release/python-370rc1/ https://www.python.org/downloads/release/python-366rc1/ -- Ned Deily n...@python.org -- [] ___ 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] 3.7.0 / 3.6.6 Update: all systems go for final releases!
A quick update: after many months we are at the finish line. We are on track (mixing metaphors) to release 3.7.0 (and 3.6.6) this week on 2018-06-27. Since 3.7.0rc1 shipped 2 weeks ago, I am aware of only two noteworthy regressions that have been identified and now fixed. Since the issues for both have the potential to impact some (but small) subsets of 3.7.0 users and the fixes for both are straightforward and appear to be low-risk, I am planning to cherry-pick the fixes for them into 3.7.0 final without either another release candidate cycle or waiting for 3.7.1. There may be some doc fixes that get cherry-picked as well. At the moment, there are no plans for any bug cherry-picks for 3.6.6 final. As you know, a new feature release is a big deal and something for all of us to be proud of. A new feature release also has various, mostly minor, impacts to lots of different parts of our development infrastructure: to multiple branches of the cpython repo, to documentation builds, to different parts of the python.org web site, etc. You will start to see some of the changes roll out over the next 24 to 36 hours and it may take some time until everything is in place. So please be patient until the official release announcement goes out before reporting release-related issues. Also be advised that over the same period, there may be a few brief periods where commit access to various cpython branches is blocked in order to do the necessary release engineering. If you run into this, for example when trying to merge a PR, please try again in a few hours. Thanks and more later! https://bugs.python.org/issue33851 https://bugs.python.org/issue33932 -- Ned Deily n...@python.org -- [] ___ 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] devguide: Updated dev guide to reflect the new workflow we're trying for 3.5.
In article <5560b054@udel.edu>, Terry Reedy wrote: > I somehow did not understand this last part before. Rather I thought > the need for pull requests would be highly restricted (and not affect me > ;-). 3.5 bugfixes (and idlelib patches, unclassified), especially those > applied to 3.4, should automatically be in the next 3.5 release. I > cannot imagine a reason not to so so. Otherwise, we could end up with > the awful anomaly that a bugfix (or Idle change) could be in 3.4.4 (the > final maintenance version that comes out after 3.5.0) but not in 3.5.0 > itself. The need for "pull requests" *is* highly restricted. Note that the "pull request" proposal appears in the Release Candidate section and only applies after 3.5.0rc1 is finalized. During the Beta phase that we're entering now, bugfixes should be checked into the new 3.5 branch and they will be released first in 3.5.0b2 or 3.5.0b3. After rc1, bugfixes checked into the 3.5 branch will be released first in 3.5.1 unless they are deemed release critical for 3.5.0 in which case the pull request would be needed. The goal is to have zero release critical fixes after rc1; usually there are very few. -- Ned Deily, n...@acm.org ___ 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] [RELEASED] Python 3.5.0b1 is now available
In article <20150525001522.GA30305@piedra>, Zero Piraeus wrote: > On Sun, May 24, 2015 at 04:39:00PM -0700, Larry Hastings wrote: > > You can find Python 3.5.0b1 here: > >https://www.python.org/downloads/release/python-350b1/ > Source tarballs (both .tgz and .tar.xz) are missing ... They seem to be there now. Are you still not able to download them? -- Ned Deily, n...@acm.org ___ 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] [Python-checkins] peps: We have a 3.6 release PEP.
> On Jun 1, 2015, at 11:04, Yury Selivanov wrote: > > It looks like we now have two 3.6 release PEPs: 494 & 495 Sorry about the confusion. The second checkin (for 495) has been reverted; PEP 494 will be the ongoing PEP. ___ 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
