[Python-Dev] [RELEASED] Python 3.4.8rc1 and Python 3.5.5rc1 are now available
On behalf of the Python development community, I'm pleased to announce the availability of Python 3.4.8rc1 and Python 3.5.5rc1. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.8rc1 here: https://www.python.org/downloads/release/python-348rc1/ And you can find Python 3.5.5rc1 here: https://www.python.org/downloads/release/python-355rc1/ Happy Pythoning, //arry/ ___ 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 Mon, 22 Jan 2018 at 09:29 Victor Stinner wrote: > Hi, > > I'm still talking with Paul Peny (pmpp on IRC) who is trying to build > the master branch of Python on Android, using cross-compilation or > directly on an Android device. I started to took notes since Android > is a complex platforms and it's not easy for me to remember > everything. > > http://vstinner.readthedocs.io/python_android.html > > Paul would like to support Android 4.4 Kitkat (API 19) just because > it's possible to find cheap devices running Android, but usually only > with old Android versions. Technically, it doesn't see difficult to > support API 19+ (instead of 21+), a few tiny patches are needed. But I > don't want to have a "full support" of API 19+, only basic support > like "make sure that the compilation doesn't fail", not "all tests > must pass". > > It seems like sys.platform == 'android' would be more appropriate > since Android is not Linux: different libc, different filesystems, > etc. > I've had a similar thought myself. -Brett > > While Xavier promotes cross-compilation, Paul would like to build > Python directly on Android to get pip and wheels. > > Honestly, I have no strong opinion, since I don't know well Android. > I'm trying to help everybody working on the Android support. IMHO it's > fine to support multiple ways to build Python for Android. It's not > like there is very obvious option which has no drawback... Cross > compilation is complex, getting a C compiler on Android also seems to > be complex. From my point of view, compared to a common Fedora Linux, > Android doesn't seem easy to use to develop on CPython... > > Victor > > 2017-12-10 15:19 GMT+01:00 Xavier de Gaye : > > The following note is a proposal to add the support of the Android > platform. > > > > The note is easier to read with clickable links at > > https://github.com/xdegaye/cagibi/blob/master/doc/android_support.rst > > > > Motivations > > === > > > > * Android is ubiquitous. > > * This would be the first platform supported by Python that is > > cross-compiled, > > thanks to many contributors. > > * Although the Android operating system is linux, it is different from > most > > linux platforms, for example it does not use GNU libc and runs SELinux > in > > enforcing mode. Therefore supporting this platform would make Python > more > > robust and also would allow testing it on arm 64-bit processors. > > * Python running on Android is also a handheld calculator, a successor of > > the > > slide rule and the `HP 41`_. > > > > Current status > > == > > > > * The Python test suite succeeds when run on Android emulators using > > buildbot > > strenuous settings with the following architectures on API 24: x86, > > x86_64, > > armv7 and arm64. > > * The `Android build system`_ is described in another section. > > * The `buildmaster-config PR 26`_ proposes to update ``master.cfg`` to > > enable > > buildbots to run a given Android API and architecture on the emulators. > > * The Android emulator is actually ``qemu``, so the test suites for x86 > and > > x86_64 last about the same time as the test suite run natively when the > > processor of the build system is of the x86 family. The test suites for > > the > > arm architectures last much longer: about 8 hours for arm64 and 10 > hours > > for > > armv7 on a four years old laptop. > > * The changes that have been made to achieve this status are listed in > > `bpo-26865`_, the Android meta-issue. > > * Given the cpu resources required to run the test suite on the arm > > emulators, > > it may be difficult to find a contributed buildbot worker. So it > remains > > to > > find the hardware to run these buildbots. > > > > Proposal > > > > > > Support the Android platform on API 24 [1]_ for the x86_64, armv7 and > arm64 > > architectures built with NDK 14b. > > > > *API 24* > > * API 21 is the first version to provide usable support for wide > > characters > > and where SELinux is run in enforcing mode. > > > > * API 22 introduces an annoying bug on the linker that prints something > > like > > this when python is started:: > > > > ``WARNING: linker: libpython3.6m.so.1.0: unused DT entry: type > > 0x6ffe arg 0x14554``. > > > > The `termux`_ Android terminal emulator describes this problem at the > > end > > of its `termux-packages`_ gitlab page and has implemented a > > ``termux-elf-cleaner`` tool to strip the useless entries from the ELF > > header of executables. > > > > * API 24 is the first version where the `adb`_ shell is run on the > > emulator > > as a ``shell`` user instead of the ``root`` user previously, and the > > first > > version that supports arm64. > > > > *x86_64* > > It seems that no handheld device exists using that architecture. It is > > supported because the x86_64 Android emulator runs fast and therefore > is a > > good candidate as a buildbot worker. > > > > *NDK 1
Re: [Python-Dev] Support of the Android platform
Ok, I created https://bugs.python.org/issue32637 "Android: set sys.platform and os.name to android" Victor 2018-01-23 18:01 GMT+01:00 Brett Cannon : > > > On Mon, 22 Jan 2018 at 09:29 Victor Stinner > wrote: >> >> Hi, >> >> I'm still talking with Paul Peny (pmpp on IRC) who is trying to build >> the master branch of Python on Android, using cross-compilation or >> directly on an Android device. I started to took notes since Android >> is a complex platforms and it's not easy for me to remember >> everything. >> >> http://vstinner.readthedocs.io/python_android.html >> >> Paul would like to support Android 4.4 Kitkat (API 19) just because >> it's possible to find cheap devices running Android, but usually only >> with old Android versions. Technically, it doesn't see difficult to >> support API 19+ (instead of 21+), a few tiny patches are needed. But I >> don't want to have a "full support" of API 19+, only basic support >> like "make sure that the compilation doesn't fail", not "all tests >> must pass". >> >> It seems like sys.platform == 'android' would be more appropriate >> since Android is not Linux: different libc, different filesystems, >> etc. > > > I've had a similar thought myself. > > -Brett > >> >> >> While Xavier promotes cross-compilation, Paul would like to build >> Python directly on Android to get pip and wheels. >> >> Honestly, I have no strong opinion, since I don't know well Android. >> I'm trying to help everybody working on the Android support. IMHO it's >> fine to support multiple ways to build Python for Android. It's not >> like there is very obvious option which has no drawback... Cross >> compilation is complex, getting a C compiler on Android also seems to >> be complex. From my point of view, compared to a common Fedora Linux, >> Android doesn't seem easy to use to develop on CPython... >> >> Victor >> >> 2017-12-10 15:19 GMT+01:00 Xavier de Gaye : >> > The following note is a proposal to add the support of the Android >> > platform. >> > >> > The note is easier to read with clickable links at >> > https://github.com/xdegaye/cagibi/blob/master/doc/android_support.rst >> > >> > Motivations >> > === >> > >> > * Android is ubiquitous. >> > * This would be the first platform supported by Python that is >> > cross-compiled, >> > thanks to many contributors. >> > * Although the Android operating system is linux, it is different from >> > most >> > linux platforms, for example it does not use GNU libc and runs SELinux >> > in >> > enforcing mode. Therefore supporting this platform would make Python >> > more >> > robust and also would allow testing it on arm 64-bit processors. >> > * Python running on Android is also a handheld calculator, a successor >> > of >> > the >> > slide rule and the `HP 41`_. >> > >> > Current status >> > == >> > >> > * The Python test suite succeeds when run on Android emulators using >> > buildbot >> > strenuous settings with the following architectures on API 24: x86, >> > x86_64, >> > armv7 and arm64. >> > * The `Android build system`_ is described in another section. >> > * The `buildmaster-config PR 26`_ proposes to update ``master.cfg`` to >> > enable >> > buildbots to run a given Android API and architecture on the >> > emulators. >> > * The Android emulator is actually ``qemu``, so the test suites for x86 >> > and >> > x86_64 last about the same time as the test suite run natively when >> > the >> > processor of the build system is of the x86 family. The test suites >> > for >> > the >> > arm architectures last much longer: about 8 hours for arm64 and 10 >> > hours >> > for >> > armv7 on a four years old laptop. >> > * The changes that have been made to achieve this status are listed in >> > `bpo-26865`_, the Android meta-issue. >> > * Given the cpu resources required to run the test suite on the arm >> > emulators, >> > it may be difficult to find a contributed buildbot worker. So it >> > remains >> > to >> > find the hardware to run these buildbots. >> > >> > Proposal >> > >> > >> > Support the Android platform on API 24 [1]_ for the x86_64, armv7 and >> > arm64 >> > architectures built with NDK 14b. >> > >> > *API 24* >> > * API 21 is the first version to provide usable support for wide >> > characters >> > and where SELinux is run in enforcing mode. >> > >> > * API 22 introduces an annoying bug on the linker that prints >> > something >> > like >> > this when python is started:: >> > >> > ``WARNING: linker: libpython3.6m.so.1.0: unused DT entry: type >> > 0x6ffe arg 0x14554``. >> > >> > The `termux`_ Android terminal emulator describes this problem at >> > the >> > end >> > of its `termux-packages`_ gitlab page and has implemented a >> > ``termux-elf-cleaner`` tool to strip the useless entries from the >> > ELF >> > header of executables. >> > >> > * API 24 is the first version where the `adb`_ shell is run on the >> > emulator >> > as a ``shel
Re: [Python-Dev] Support of the Android platform
For this to move forward more rapidly it would really help if there were a utility VM appliance available with a ready-installed support an SDK. Or at least that would lower impedance to joining the development effort. Does any such beast by chance exist? S Steve Holden On Tue, Jan 23, 2018 at 5:17 PM, Victor Stinner wrote: > Ok, I created https://bugs.python.org/issue32637 > "Android: set sys.platform and os.name to android" > > Victor > > 2018-01-23 18:01 GMT+01:00 Brett Cannon : > > > > > > On Mon, 22 Jan 2018 at 09:29 Victor Stinner > > wrote: > >> > >> Hi, > >> > >> I'm still talking with Paul Peny (pmpp on IRC) who is trying to build > >> the master branch of Python on Android, using cross-compilation or > >> directly on an Android device. I started to took notes since Android > >> is a complex platforms and it's not easy for me to remember > >> everything. > >> > >> http://vstinner.readthedocs.io/python_android.html > >> > >> Paul would like to support Android 4.4 Kitkat (API 19) just because > >> it's possible to find cheap devices running Android, but usually only > >> with old Android versions. Technically, it doesn't see difficult to > >> support API 19+ (instead of 21+), a few tiny patches are needed. But I > >> don't want to have a "full support" of API 19+, only basic support > >> like "make sure that the compilation doesn't fail", not "all tests > >> must pass". > >> > >> It seems like sys.platform == 'android' would be more appropriate > >> since Android is not Linux: different libc, different filesystems, > >> etc. > > > > > > I've had a similar thought myself. > > > > -Brett > > > >> > >> > >> While Xavier promotes cross-compilation, Paul would like to build > >> Python directly on Android to get pip and wheels. > >> > >> Honestly, I have no strong opinion, since I don't know well Android. > >> I'm trying to help everybody working on the Android support. IMHO it's > >> fine to support multiple ways to build Python for Android. It's not > >> like there is very obvious option which has no drawback... Cross > >> compilation is complex, getting a C compiler on Android also seems to > >> be complex. From my point of view, compared to a common Fedora Linux, > >> Android doesn't seem easy to use to develop on CPython... > >> > >> Victor > >> > >> 2017-12-10 15:19 GMT+01:00 Xavier de Gaye : > >> > The following note is a proposal to add the support of the Android > >> > platform. > >> > > >> > The note is easier to read with clickable links at > >> > https://github.com/xdegaye/cagibi/blob/master/doc/android_support.rst > >> > > >> > Motivations > >> > === > >> > > >> > * Android is ubiquitous. > >> > * This would be the first platform supported by Python that is > >> > cross-compiled, > >> > thanks to many contributors. > >> > * Although the Android operating system is linux, it is different from > >> > most > >> > linux platforms, for example it does not use GNU libc and runs > SELinux > >> > in > >> > enforcing mode. Therefore supporting this platform would make Python > >> > more > >> > robust and also would allow testing it on arm 64-bit processors. > >> > * Python running on Android is also a handheld calculator, a successor > >> > of > >> > the > >> > slide rule and the `HP 41`_. > >> > > >> > Current status > >> > == > >> > > >> > * The Python test suite succeeds when run on Android emulators using > >> > buildbot > >> > strenuous settings with the following architectures on API 24: x86, > >> > x86_64, > >> > armv7 and arm64. > >> > * The `Android build system`_ is described in another section. > >> > * The `buildmaster-config PR 26`_ proposes to update ``master.cfg`` to > >> > enable > >> > buildbots to run a given Android API and architecture on the > >> > emulators. > >> > * The Android emulator is actually ``qemu``, so the test suites for > x86 > >> > and > >> > x86_64 last about the same time as the test suite run natively when > >> > the > >> > processor of the build system is of the x86 family. The test suites > >> > for > >> > the > >> > arm architectures last much longer: about 8 hours for arm64 and 10 > >> > hours > >> > for > >> > armv7 on a four years old laptop. > >> > * The changes that have been made to achieve this status are listed in > >> > `bpo-26865`_, the Android meta-issue. > >> > * Given the cpu resources required to run the test suite on the arm > >> > emulators, > >> > it may be difficult to find a contributed buildbot worker. So it > >> > remains > >> > to > >> > find the hardware to run these buildbots. > >> > > >> > Proposal > >> > > >> > > >> > Support the Android platform on API 24 [1]_ for the x86_64, armv7 and > >> > arm64 > >> > architectures built with NDK 14b. > >> > > >> > *API 24* > >> > * API 21 is the first version to provide usable support for wide > >> > characters > >> > and where SELinux is run in enforcing mode. > >> > > >> > * API 22 introduces an annoying bug on the linker
Re: [Python-Dev] Intention to accept PEP 567 (Context Variables)
On Tue, Jan 23, 2018 at 2:23 AM, Victor Stinner wrote: > The PEP 555 looks a competitor PEP of the PEP 567. Since the Yury's > PEP 567 was approved, I understand that Koos's PEP 555 should be > rejected, no? > > If Guido prefers to reject it, I assume he'll say so. Anyway, it's still waiting for me to add references to earlier discussions and perhaps summaries of some discussions. Personally, I need to find some time to properly catch up with the latest discussion to figure out why PEP 567 is better than PEP 555 (or similar with .set(..), or PEP 550), despite problems of reasoning about the scopes of variables and unset tokens. In any case, congrats, Yury! This hasn't been an easy one for any of us, and it seems like the implementation required quite a beastly patch too in the end. —Koos ___ 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] Intention to accept PEP 567 (Context Variables)
On 01/23/2018 09:56 AM, Koos Zevenhoven wrote: On Tue, Jan 23, 2018 at 2:23 AM, Victor Stinner mailto:victor.stin...@gmail.com>>wrote: The PEP 555 looks a competitor PEP of the PEP 567. Since the Yury's PEP 567 was approved, I understand that Koos's PEP 555 should be rejected, no? If Guido prefers to reject it, I assume he'll say so. Guido has already made his position clear: On 01/10/2018 08:21 AM, Guido van Rossum wrote: The current status of PEP 555 is "Withdrawn". I have no interest in considering it any more, so if you'd rather see a decision from me I'll be happy to change it to "Rejected". Yes, there is no future for PEP 555. //arry/ ___ 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
