[Python-Dev] Getting ready for Python 3.5
[Apologies for the cross-posting! -BAW] For Ubuntu 15.10 (Wily Werewolf), we want to make Python 3.5 the default Python 3 version. It's currently undecided whether we will keep Python 3.4 as a supported version, but a lot of that depends on how easily an archive port to Python 3.5 goes. Ideally, we'd be able to make the switch to 3.5 now ahead of the planned 16.04 LTS release. As part of this work, we've done a partial test rebuild of packages in the archive that depend in some way on Python 3. For now, this is an x86 only partial rebuild in a PPA. In this PPA, we have Python 3.5 as the default Python 3 version, with 3.4 still enabled. You can see the results so far here: https://launchpad.net/~pythoneers/+archive/ubuntu/py35asdefault/+packages TL;DR: of 1065 uploads, we have ~64% success rate. Some caveats: * These are i386 and amd64 only, so we're still in the dark about other architectures. * These are build tests only. While many builds do run the package's test suite, not all packages have test suites, or not all are enabled. Also, we are not running what are called DEP-8 tests, which are various additional smoketests that are run after the package is built, on the built package (e.g. install the package and all its dependencies in a chroot and see if it can be imported in both Python 2 and 3). * Some failures are due to dependency build order, so a simple rebuild may succeed. * Some failures may not be new. Because a lot of packages don't get new uploads for every new Ubuntu version, they may be failing to build for reasons unrelated to Python 3.5. * We may have missed some packages which declare their build dependencies in a way that got past our rather simplistic filter. Our plan is get the success rate up on the PPA, filing and fixing bugs upstream where possible, then to set up a full archive test rebuild, again with 3.5 as default and 3.4 as enabled, to see what other failures may occur. This full archive rebuild will include all the other architectures, and it's possible packages will build on x86 but fail on some other platform. We're also planning on setting up a QA stack to run the DEP-8 tests for packages that have them. In the meantime, you can help! I've started a wiki page listing the backward compatibility breaks I've found so far. Feel free to add to this, or look into the linked issues. Contribute to the wiki or the linked issues. https://wiki.python.org/moin/PortingToPy3k/34to35 Build and install Python 3.5 from source and run your package's test suite in a virtual environment or in tox. (tox 2.1 supports Python 3.5 but it isn't yet available in Debian/Ubuntu - no worries, install tox in a virtualenv and use *that* to run your test suite.) Create a chroot with the py35asdefault PPA enabled, and do some porting there. Here's a good guideline on how to use a PPA. https://help.launchpad.net/Packaging/PPA https://launchpad.net/~pythoneers/+archive/ubuntu/py35asdefault Examine the build failures and see if you can identify or fix the problem. Start with the package details page https://launchpad.net/~pythoneers/+archive/ubuntu/py35asdefault/+packages and drill down into the console logs for specific failures by clicking on the 'amd64' or 'i386' links next to any big red X you see, then clicking on the 'buildlog' link. E.g. http://tinyurl.com/pnpjtv6 Scroll down near the bottom, which is where the failure will most likely be evident. Release new versions of your packages with Python 3.5 support to PyPI so the Debian maintainers and Ubuntu developers can begin to upload compatible versions. If you're a developer for other Linux distros or platforms, let's work together! (As is often the case, we'll trail blaze on Ubuntu and push the results upstream to Debian as much as possible.) Follow up here on any of the CC'd mailing lists, email me directly, or ping me on IRC (nick 'barry' on python-dev, ubuntu-release @ freenode, debian-python @ OFTC). Python 3.5 is in beta, with a final release scheduled for September 2015 (see PEP 478). There's still plenty of time to fix or adjust to issues we find but there are a ton of packages, so all help is greatly appreciated. Let's make Python 3.5 the easiest upgrade ever. Cheers, -Barry pgpWkfyWUfZ_r.pgp Description: OpenPGP digital signature ___ 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] Unbound locals in class scopes
On 23 June 2015 at 05:33, Nick Coghlan wrote: > > > Also, since classes inside functions are commonly used in unit tests (at > > least mine :-), I worry that *any* changes in this behavior might break > > working code (no matter how much that "working" could be considered an > > accident, it's still going to be a bear to debug if this happens to you). > > Agreed - I think any change here would need to go through a > deprecation period where we warned about cases where LOAD_NAME would > be changed to LOAD_CLASSDEREF and there was a nonlocal defined with > that name. > > Since it's trivial easy to workaround by renaming a local variable to > use a name that differs from the nested class attribute, I'd also be > entirely happy with leaving the current behaviour as an obscure quirk > - I'm only +0 on changing it, and also +0 on declaring it "not worth > the hassle of changing". > > This is also my attitude on this issue. Looks like everyone agrees that this is a strange behavior, but not strange enough to be changed. ___ 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] Backporting the 3.5+ Windows build project files to 2.7
Hi Zack, On 23.06.15 06:42, Zachary Ware wrote: > On Mon, Jun 22, 2015 at 10:37 PM, Nick Coghlan wrote: >> I'd suggest explicitly reaching out to the Stackless folks to get >> their feedback. As I believe the switched to a newer compiler and VC >> runtime for Windows a while back, I suspect it will make their lives >> easier rather than harder, but it's still worth asking for their >> input. > From a glance at the stackless repo, it looks like it still uses > VS2008's project files (which pretty much means using MSVC 9), but I > could have easily missed something. > > Christian, what say you? Would having the project files from 3.5 > backported to 2.7 (but still using MSVC 9) be positive, negative, or > indifferent for Stackless? > I am very positive about your efforts. We wanted to create a Stackless 2.8 version end of 2013 with support for newer compilers, to begin with. After a while, we stopped this, and I left the branch in a private, unmaintained repository. https://bitbucket.org/stackless-dev/stackless-private/branch/2.8-slp Maybe you can make use of this, use it as you like it. You will get an invitation. cheers - Chris -- Christian Tismer :^) tis...@stackless.com Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : http://www.pydica.net/ 14482 Potsdam: GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023 signature.asc Description: OpenPGP digital signature ___ 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] Backporting the 3.5+ Windows build project files to 2.7
On 22/06/2015 18:03, Zachary Ware wrote: > As you may know, Steve Dower put significant effort into rewriting the > project files used by the Windows build as part of moving to VC14 as > the official compiler for Python 3.5. Compared to the project files > for 3.4 (and older), the new project files are smaller, cleaner, > simpler, more easily extensible, and in some cases quite a bit more > correct. > > I'd like to backport those new project files to 2.7, and Intel is > willing to fund that work as part of making Python ICC compilable on > all platforms they support since it makes building Python 2.7 with ICC > much easier. Very much +1. Anything which eases building on Windows is good. I'd meant a while ago to put in a vote of thanks to you & Steve for the incremental improvements and tidy-ups to the build area, and I'd certainly like to see this proposed change go in. I'll try to find time to check out your branch and build from there, but unless you've done anything bizarre I'm sure I'll be happy with it. TJG ___ 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] speed.python.org
On 23.06.2015 03:58, Zachary Ware wrote: > On Thu, Jun 4, 2015 at 10:51 AM, Maciej Fijalkowski wrote: >> On Thu, Jun 4, 2015 at 4:32 PM, R. David Murray >> wrote: >>> OK, so what you are saying is that speed.python.org will run a buildbot >>> slave so that when a change is committed to cPython, a speed run will be >>> triggered? Is "the runner" a normal buildbot slave, or something >>> custom? In the normal case the master controls what the slave >>> runs...but regardless, you'll need to let us know how the slave >>> invocation needs to be configured on the master. >> >> Ideally nightly (benchmarks take a while). The setup for pypy looks like >> this: >> >> >> https://bitbucket.org/pypy/buildbot/src/5fa1f1a4990f842dfbee416c4c2e2f6f75d451c4/bot2/pypybuildbot/builds.py?at=default#cl-734 >> >> so fairly easy. This already generates a json file that you can plot. >> We can setup an upload automatically too. > > I've been looking at what it will take to set up the buildmaster for > this, and it looks like it's just a matter of checking out the > benchmarks, building Python, testing it, and running the benchmarks. > There is the question of which benchmark repo to use: > https://bitbucket.org/pypy/benchmarks or > https://hg.python.org/benchmarks; ideally, we should use > hg.python.org/benchmarks for CPython benchmarks, but it looks like > pypy/benchmarks has the necessary runner, so I suppose we'll be using > it for now. Is there interest from both sides to merge those > repositories? > > The big question for the buildmaster is what options to pass to the > benchmark runner. I suppose most of them should match the > CPythonBenchmark BuildFactory from the PyPy buildbot master > configuration, but otherwise I'm not sure. > > The other big question is where the benchmarks will be run. The > speed.python.org page makes it sound like there's a box intended for > that purpose (the one running the speed.python.org page?); can anyone > with access to it contact me to get the build slave set up? Yes, I believe the machine is currently only running that page. I've pinged the PSF Infra Team to get you access to it. Thank you for looking into this ! Cheers, -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ ___ 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
Hi, 2015-06-23 0:10 GMT+02:00 Nick Coghlan : > Chiming in again since I wasn't clear on this aspect last time: I'd also be > +1 on parallel APIs that handle the chaining. > > Since the auto-chaining idea seems largely unpopular, that suggests to me > that a parallel set of APIs would be the most readily accepted way forward. > > I nominate a "*Chained" suffix as my suggested colour for the bikeshed :) In the PEP, I proposed adding helpers in Alternatives, but I proposed to add *private* APIs: https://www.python.org/dev/peps/pep-0490/#new-helpers-to-chain-exceptions I would prefer to experiment these API during one cycle before making them public. Extending the public API has a cost on the maintenance, it's common to add 1 or 2 versions of the same function which makes the public API uglier and heavier to maintain (especially since we have the public ABI). Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
