Re: [Python-Dev] Support of the Android platform
2017-12-10 15:19 GMT+01:00 Xavier de Gaye : > 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`_. I still don't understand what is "Android". What is the license of Android? > * The Python test suite succeeds when run on Android emulators using > buildbot Great achievement! Congrats! I know that it has been a long travel to reach this point! (Fix each invidivual test failure, fix many tiny things.) > * 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. Do you have the hardware to host such worker? Or are you looking for a host somewhere? Which kind of hardware are you looking for? CPU, memory, network bandwidth, etc. > *API 24* > * API 21 is the first version to provide usable support for wide > characters > and where SELinux is run in enforcing mode. Some people are looking for API 19 support. Would it be doable, or would it require too many changes? I know that people are running heavily patched Python 2.7 and 3.5 on Android with API 19. I'm not asking for a "full support" for API 19, but more if it would be possible to get a "best effort" level of support, like accept patches if someone writes them. > The following extension modules are disabled by adding them to the > ``*disabled*`` section of ``Modules/Setup``: > > * ``_uuid``, Android has no uuid/uuid.h header. > * ``grp`` some grp.h functions are not declared. > * ``_crypt``, Android does not have crypt.h. > * ``_ctypes`` on x86_64 where all long double tests fail (`bpo-32202`_) and > on > arm64 (see `bpo-32203`_). That's a very short list, it's ok. It's not the most popular modules of the stdlib :-) ctypes would be nice to have, but it can be done later. Victor ___ Python-Dev mailing list [email protected] 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 12/10/2017 09:27 PM, Brett Cannon wrote: > 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? :) This is mainly a proposal written in the form of a PEP and open for discussion, not a PEP because it is not required by PEP 11 but it may become one. I guess the discussion may be about the choice of the API level, or whether the buildbot should run on emulators or on devices (not currently supported by the build system) or on any other subject. What is left to be done to support Android at this point is to merge the PR that implements the build system, make the change in the buildbot buildmaster-config repo and test it on a worker and then find the hardware to run all the workers for these architectures and set it up. Xavier ___ Python-Dev mailing list [email protected] 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 12/10/2017 10:27 PM, Skip Montanaro wrote: > I'm not familiar with software development on/for Android, but > wouldn't official support also involve suitable package creation or > does that just fall out for free from the build-for-emulator PR? > > Skip > The build-for-emulator PR allows building for a device but the packaging of an Android application into an installable APK (a zip file actually) is the responsability of the java application developer. Xavier ___ Python-Dev mailing list [email protected] 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 12/10/2017 11:07 PM, Ned Deily wrote: > 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. Yes this platform has few quirks especially when SELinux is involved and some tests are harder to write because of that :-( Xavier ___ Python-Dev mailing list [email protected] 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 12/11/2017 12:56 PM, Victor Stinner wrote: > 2017-12-10 15:19 GMT+01:00 Xavier de Gaye : >> * 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. > > Do you have the hardware to host such worker? Or are you looking for a > host somewhere? Which kind of hardware are you looking for? CPU, > memory, network bandwidth, etc. I cannot host the buildbots or any buildbot for that matter. I can maintain them. The host running the buildbots must be able to run 6 (i.e. 3 x (version 3.x + maintenance version)) emulators simultaneously, so with an eight core cpu, that will be 6 cores running at 100%. The armv7 and arm64 buildbot may be set to run only daily but the tests last a long time on these architectures anyway. >> *API 24* >>* API 21 is the first version to provide usable support for wide >> characters >> and where SELinux is run in enforcing mode. > > Some people are looking for API 19 support. Would it be doable, or > would it require too many changes? I know that people are running > heavily patched Python 2.7 and 3.5 on Android with API 19. > > I'm not asking for a "full support" for API 19, but more if it would > be possible to get a "best effort" level of support, like accept > patches if someone writes them. Not sure that python can be built on API 19. What I remember about API 19 at the time I started this project, is that wide characters support is not usable. If you look at the Android version history [1] on Wikipedia referred to in my initial post, the Kit Kat (API 19) share is 16 % now and will probably be 8 % next year. Another point to consider is that working on a change specific to Android is tedious: the test case must be ok on the build platform and on the emulator. The emulator must be started and an installation made from scratch, and after few file modifications on the emulator there is no 'git status' command to tell exactly what change you are running and you must re-install from scratch. Is there a way to browse these patches to get a better idea of the changes involved ? Xavier [1] https://en.wikipedia.org/wiki/Android_version_history ___ Python-Dev mailing list [email protected] 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
2017-12-11 14:58 GMT+01:00 Xavier de Gaye : > The host running the buildbots must be able to run 6 (i.e. 3 x (version 3.x > + maintenance version)) emulators simultaneously, so with an eight core cpu, > that will be 6 cores running at 100%. The armv7 and arm64 buildbot may be > set to run only daily but the tests last a long time on these architectures > anyway. What do you mean by "maintenance version"? Do you want to add Android support to Python 2.7 and 3.6 as well? I would prefer to only support Android since the master branch. Would it be possible to only run an emulator to run a test, and then stop it? So we could test many combo in the same host? Victor ___ Python-Dev mailing list [email protected] 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
I'm asking for precise hardware specifications since Red Hat may be able to provide one through the https://osci.io/ program. Victor 2017-12-11 15:40 GMT+01:00 Victor Stinner : > 2017-12-11 14:58 GMT+01:00 Xavier de Gaye : >> The host running the buildbots must be able to run 6 (i.e. 3 x (version 3.x >> + maintenance version)) emulators simultaneously, so with an eight core cpu, >> that will be 6 cores running at 100%. The armv7 and arm64 buildbot may be >> set to run only daily but the tests last a long time on these architectures >> anyway. > > What do you mean by "maintenance version"? Do you want to add Android > support to Python 2.7 and 3.6 as well? I would prefer to only support > Android since the master branch. > > Would it be possible to only run an emulator to run a test, and then > stop it? So we could test many combo in the same host? > > Victor ___ Python-Dev mailing list [email protected] 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 12/11/2017 03:40 PM, Victor Stinner wrote: > 2017-12-11 14:58 GMT+01:00 Xavier de Gaye : >> The host running the buildbots must be able to run 6 (i.e. 3 x (version 3.x >> + maintenance version)) emulators simultaneously, so with an eight core cpu, >> that will be 6 cores running at 100%. The armv7 and arm64 buildbot may be >> set to run only daily but the tests last a long time on these architectures >> anyway. > > What do you mean by "maintenance version"? Do you want to add Android > support to Python 2.7 and 3.6 as well? I would prefer to only support > Android since the master branch. Yes, today only the master branch, and when 3.8 is released then both 3.7 and 3.8 would be supported. That is what I (implicitly) meant. > Would it be possible to only run an emulator to run a test, and then > stop it? So we could test many combo in the same host? I may not understand your question. An emulator runs with an AVD image (Android Virtual Device) that is specific to the API and architecture (armv7, x86_64, ...), and that contains the data (file systems) and the configuration. The AVD image is created once and for all for each of the combinations (API, architecture). You start the emulator with the AVD that matches the type of the built python (API, architecture) and install that build. Multiple emulators can run simultaneously except that the build system imposes the restriction that no two identical (API, architecture) emulators can run concurrently except if they are not used for the same Python version (emulators are identified by their port numbers by the Android tools and the build system allocates those ports statically). Xavier ___ Python-Dev mailing list [email protected] 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 does Android support mean?
On 12/11/2017 03:58 PM, Carl Bordum Hansen wrote: > > I've been lurking at your progress with android support for about a year, and now that it is closing in I simply have to ask: what does it actually mean that android is supported? That Android apps > will be easy to develop in Python? That I can easily run Python script or a REPL on my phone? Hello Carl, It means that we will make sure that changes made to Python to fix it or to improve it will not break on Android for the supported API level and architectures. One can already run Python scripts or the interactive interpreter and install packages with pip using termux, a great application. Kivy can be used to develop in Python apps that work on Android and you may be interested in the Python Mobile SIG [1] mailing list or in the VOC [2] transpiler that converts Python code into Java bytecode. Xavier [1] https://www.python.org/community/sigs/current/mobile-sig/ [2] https://github.com/pybee/voc ___ Python-Dev mailing list [email protected] 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 static typing still optional?
. I see a couple of options: 1a: Use a default type annotation, if one is not is supplied. typing.Any would presumably make the most sense. 1b: Use None if not type is supplied. 2: Rework the code to not require annotations at all. I think I'd prefer 1a, since it's easy. 2) would be great :-) I find this bit of “typing creep” makes me nervous— Typing should Never be required! I understand that the intent here is that the user could ignore typing and have it all still work. But I’d rather is was not still there under the hood. Just because standardized way to do something is included in core Python doesn’t mean the standard library has to use it. However, typing is not currently imported by dataclasses.py. And there you have an actual reason besides my uneasiness :-) - CHB ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Last call for PEP approvals before the holidays
After this Friday I'm going to go on vacation for a couple of weeks. Anyone who has a PEP for which they're awaiting acceptance and that acceptance needs to happen before the 3.7 feature freeze (a.k.a. 3.7b1, scheduled for January 29 2018, see PEP 537) please ping me with a pointer to the thread on python-dev (or occasionally on another list). If acceptance waits until the new year it's less likely to happen in time. OTOH if your PEP is not time-sensitive it's probably better to wait until after the 3.7b1 release. PEPs I am already aware of: - 565 (DeprecationWarning) -- I'm going to accept it - 550 (Context) -- I'm waiting for a new (simpler) draft by Yury - 561 (type checker module search) -- not time-sensitive, I'm confident that the work is going well regardless of acceptance - 554 (multiple interpreters) -- postponed to 3.8 - 558 (locals()) -- I think this will have to be postponed -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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 540: Add a new UTF-8 mode (v3)
Congrats Victor! Thanks mr. Inada for reviewing this PEP (and 538). Thanks everyone else who participated in the lively discussion! On Sun, Dec 10, 2017 at 4:00 PM, INADA Naoki wrote: > > > > Could you explain why not? utf-8 seems like the common thread for using > > surrogateescape so I'm not sure what would make en_US.UTF-8 different > than > > C.UTF-8. > > > > Because there are many lang_COUNTRY.UTF-8 locales: > ja_JP.UTF-8, zh_TW.UTF-8, fr_FR.UTF-8, etc... > > If only en_US.UTF-8 should use surrogateescape, it may make confusing > situation > like: "This script works in English Linux desktop, but doesn't work in > Japanese Linux > desktop!" > > I accepted PEP 540. So even if failed to coerce locale, it is better > than Python 3.6. > > Regards, > > INADA Naoki > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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 static typing still optional?
On 12/10/2017 5:00 PM, Raymond Hettinger wrote: On Dec 10, 2017, at 1:37 PM, Eric V. Smith wrote: On 12/10/2017 4:29 PM, Ivan Levkivskyi wrote: On 10 December 2017 at 22:24, Raymond Hettinger mailto:[email protected]>> wrote: Without typing (only the first currently works): Point = namedtuple('Point', ['x', 'y', 'z']) # underlying store is a tuple Point = make_dataclass('Point', ['x', 'y', 'z']) # underlying store is an instance dict Hm, I think this is a bug in implementation. The second form should also work. Agreed. I have a bunch of pending changes for dataclasses. I'll add this. This is bpo-32278. I suggest two other fix-ups: 1) Let make_dataclass() pass through keyword arguments to _process_class(), so that this will work: Point = make_dataclass('Point', ['x', 'y', 'z'], order=True) This is bpo-32279. 2) Change the default value for "hash" from "None" to "False". This might take a little effort because there is currently an oddity where setting hash=False causes it to be hashable. I'm pretty sure this wasn't intended ;-) No time for this one yet. Soon! Eric. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Last call for PEP approvals before the holidays
There is also PEP 544 (Structural subtyping, a.k.a. static duck typing), but I think we discussed off-list that it is also not time sensitive, given the (limited) provisional status of typing module. (Also mypy already supports it, so the question is mainly when this support is official after polishing few remaining issues.) -- Ivan ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Last call for PEP approvals before the holidays
On 12 Dec. 2017 8:52 am, "Guido van Rossum" wrote: - 558 (locals()) -- I think this will have to be postponed +1 for deferring that one to 3.8. While I like where it's heading now, it isn't urgent, and we already have quite a few refactorings of low level internals landing in 3.7. Cheers, Nick. ___ Python-Dev mailing list [email protected] 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 static typing still optional?
On 11 Dec. 2017 12:26 pm, "Eric V. Smith" wrote: I see a couple of options: 1a: Use a default type annotation, if one is not is supplied. typing.Any would presumably make the most sense. 1b: Use None if not type is supplied. 2: Rework the code to not require annotations at all. 1c: annotate with the string "typing.Any" (this may require a tweak to the rules for evaluating lazy annotations, though) Cheers, Nick. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
