Mailman 3 December 2017 - Python-Dev

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)
by Nick Coghlan Dec. 14, 2017

Dec. 14, 2017

On 11 Dec. 2017 6:50 am, "INADA Naoki" <songofacandy(a)gmail.com> wrote: Except one typo I commented on Github, I accept PEP 540. Well done, Victor and Nick for PEP 540 and 538. Python 3.7 will be most UTF-8 friendly Python 3 than ever. And thank you for all of your work on reviewing them! The appropriate trade-offs between ease of use in common scenarios and an increased chance of emitting mojibake are hard to figure out, but I like where we've ended up :) Cheers, Nick.

1 0

Zero-width matching in regexes
by MRAB Dec. 13, 2017

Dec. 13, 2017

I've finally come to a conclusion as to what the "correct" behaviour of zero-width matches should be: """always return the first match, but never a zero-width match that is joined to a previous zero-width match""". If it's about to return a zero-width match that's joined to a previous zero-width match, then backtrack and keep on looking for a match. Example: >>> print([m.span() for m in re.finditer(r'|.', 'a')]) [(0, 0), (0, 1), (1, 1)] re.findall, re.split and re.sub should work accordingly. If re.finditer finds n matches, then re.split should return a list of n+1 strings and re.sub should make n replacements (excepting maxsplit, etc.).

4 7

Re: [Python-Dev] [python/peps] PEP 567 review and copyedits (#503)
by Chris Angelico Dec. 13, 2017

Dec. 13, 2017

Redirecting comments from the PR to the ML. Everything that was tightly bound to the PR has been dropped. On Wed, Dec 13, 2017 at 12:15 PM, Yury Selivanov <notifications(a)github.com> wrote: > Most of your questions should be asked on python-dev. I'll answer them here, but if you have any follow-ups, please raise the on the ml. > >> What happens if you set, set again, then reset from the first one's token? > > The context will be reset to the state it was in before the first set, w.r.t. that variable's value. > >> A peek at the implementation shows that it simply resets the value, so aside from having magic that allows it to represent "no value", the token buys nothing that you couldn't get by simply returning the old value - which is a valuable API to have. Am I reading this correctly? > > "no value" is the main feature of Token, it what makes the PEP future compatible with PEP 550. A lot of APIs are built to return the old value, not wrapped in any sort of opaque token. If the "no value" magic were to be exposed (contextvars.NO_VALUE as a specific sentinel value), this would allow deliberate use of "previous value" as an actual part of the API. Does futureproofing require that the token be opaque? >> Implementation, _ContextData class - I don't often see "self.__mapping" in PEPs unless the name mangling is actually needed. Is it used here? Would "self._mapping" be as effective? > > __ is used to highlight the fact that all those attributes are private and inaccessible for Python code. Just to clarify, then: this is an artifact of the Python reference implementation being unable to perfectly represent the behaviour of C code, but had you been writing this for actual implementation in the stdlib, you'd have used a single underscore? >> The HAMT for Context boasts O(log N) 'set' operations. What is N? Number of variables used? Number of times they get set? Number of times set w/o being reset? > > Number of ContextVars set in the context. Thanks. Might be worth mentioning that; with the semantically-equivalent Python code, it's obvious that the cost of the copy scales with the number of unique variables, but without knowing what the actual HAMT does, it's not so obvious that that's true there too. The net result is that repeatedly setting the same variable doesn't increase the cost - right? Most of my questions were fairly straightforwardly answered in Yury's response on the PR. One question about formatting has been subsequently fixed, so all's well on that front too. The PEP looks pretty good to me. ChrisA

2 1

PEP 565: Show DeprecationWarning in __main__
by Nick Coghlan Dec. 12, 2017

Dec. 12, 2017

I've written a short(ish) PEP for the proposal to change the default warnings filters to show DeprecationWarning in __main__: https://www.python.org/dev/peps/pep-0565/ The core proposal itself is just the idea in https://bugs.python.org/issue31975 (i.e. adding "default::DeprecationWarning:__main__" to the default filter set), but the PEP fills in some details on the motivation for the original change to the defaults, and why the current proposal is to add a new filter for __main__, rather than dropping the default DeprecationWarning filter entirely. The PEP also proposes repurposing the existing FutureWarning category to explicitly mean "backwards compatibility warnings that should be shown to users of Python applications" since: - we don't tend to use FutureWarning for its original nominal purpose (changes that will continue to run but will do something different) - FutureWarning was added in 2.3, so it's available in all still supported versions of Python, and is shown by default in all of them - it's at least arguably a less-jargony spelling of DeprecationWarning, and hence more appropriate for displaying to end users that may not have encountered the specific notion of "API deprecation" Cheers, Nick. ============== PEP: 565 Title: Show DeprecationWarning in __main__ Author: Nick Coghlan <ncoghlan(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 12-Nov-2017 Python-Version: 3.7 Post-History: 12-Nov-2017 Abstract ======== In Python 2.7 and Python 3.2, the default warning filters were updated to hide DeprecationWarning by default, such that deprecation warnings in development tools that were themselves written in Python (e.g. linters, static analysers, test runners, code generators) wouldn't be visible to their users unless they explicitly opted in to seeing them. However, this change has had the unfortunate side effect of making DeprecationWarning markedly less effective at its primary intended purpose: providing advance notice of breaking changes in APIs (whether in CPython, the standard library, or in third party libraries) to users of those APIs. To improve this situation, this PEP proposes a single adjustment to the default warnings filter: displaying deprecation warnings attributed to the main module by default. This change will mean that code entered at the interactive prompt and code in single file scripts will revert to reporting these warnings by default, while they will continue to be silenced by default for packaged code distributed as part of an importable module. The PEP also proposes a number of small adjustments to the reference interpreter and standard library documentation to help make the warnings subsystem more approachable for new Python developers. Specification ============= The current set of default warnings filters consists of:: ignore::DeprecationWarning ignore::PendingDeprecationWarning ignore::ImportWarning ignore::BytesWarning ignore::ResourceWarning The default ``unittest`` test runner then uses ``warnings.catch_warnings()`` ``warnings.simplefilter('default')`` to override the default filters while running test cases. The change proposed in this PEP is to update the default warning filter list to be:: default::DeprecationWarning:__main__ ignore::DeprecationWarning ignore::PendingDeprecationWarning ignore::ImportWarning ignore::BytesWarning ignore::ResourceWarning This means that in cases where the nominal location of the warning (as determined by the ``stacklevel`` parameter to ``warnings.warn``) is in the ``__main__`` module, the first occurrence of each DeprecationWarning will once again be reported. This change will lead to DeprecationWarning being displayed by default for: * code executed directly at the interactive prompt * code executed directly as part of a single-file script While continuing to be hidden by default for: * code imported from another module in a ``zipapp`` archive's ``__main__.py`` file * code imported from another module in an executable package's ``__main__`` submodule * code imported from an executable script wrapper generated at installation time based on a ``console_scripts`` or ``gui_scripts`` entry point definition As a result, API deprecation warnings encountered by development tools written in Python should continue to be hidden by default for users of those tools While not its originally intended purpose, the standard library documentation will also be updated to explicitly recommend the use of ``FutureWarning`` (rather than ``DeprecationWarning``) for backwards compatibility warnings that are intended to be seen by *users* of an application. This will give the following three distinct categories of backwards compatibility warning, with three different intended audiences: * ``PendingDeprecationWarning``: reported by default only in test runners that override the default set of warning filters. The intended audience is Python developers that take an active interest in ensuring the future compatibility of their software (e.g. professional Python application developers with specific support obligations). * ``DeprecationWarning``: reported by default for code that runs directly in the ``__main__`` module (as such code is considered relatively unlikely to have a dedicated test suite), but relies on test suite based reporting for code in other modules. The intended audience is Python developers that are at risk of upgrades to their dependencies (including upgrades to Python itself) breaking their software (e.g. developers using Python to script environments where someone else is in control of the timing of dependency upgrades). * ``FutureWarning``: always reported by default. The intended audience is users of applications written in Python, rather than other Python developers (e.g. warning about use of a deprecated setting in a configuration file format). Given its presence in the standard library since Python 2.3, ``FutureWarning`` would then also have a secondary use case for libraries and frameworks that support multiple Python versions: as a more reliably visible alternative to ``DeprecationWarning`` in Python 2.7 and versions of Python 3.x prior to 3.7. Motivation ========== As discussed in [1_] and mentioned in [2_], Python 2.7 and Python 3.2 changed the default handling of ``DeprecationWarning`` such that: * the warning was hidden by default during normal code execution * the `unittest`` test runner was updated to re-enable it when running tests The intent was to avoid cases of tooling output like the following:: $ devtool mycode/ /usr/lib/python3.6/site-packages/devtool/cli.py:1: DeprecationWarning: 'async' and 'await' will become reserved keywords in Python 3.7 async = True ... actual tool output ... Even when `devtool` is a tool specifically for Python programmers, this is not a particularly useful warning, as it will be shown on every invocation, even though the main helpful step an end user can take is to report a bug to the developers of ``devtool``. The warning is even less helpful for general purpose developer tools that are used across more languages than just Python. However, this change proved to have unintended consequences for the following audiences: * anyone using a test runner other than the default one built into ``unittest`` (since the request for third party test runners to change their default warnings filters was never made explicitly) * anyone using the default ``unittest`` test runner to test their Python code in a subprocess (since even ``unittest`` only adjusts the warnings settings in the current process) * anyone writing Python code at the interactive prompt or as part of a directly executed script that didn't have a Python level test suite at all In these cases, ``DeprecationWarning`` ended up become almost entirely equivalent to ``PendingDeprecationWarning``: it was simply never seen at all. Limitations on PEP Scope ======================== This PEP exists specifically to explain both the proposed addition to the default warnings filter for 3.7, *and* to more clearly articulate the rationale for the original change to the handling of DeprecationWarning back in Python 2.7 and 3.2. This PEP does not solve all known problems with the current approach to handling deprecation warnings. Most notably: * the default ``unittest`` test runner does not currently report deprecation warnings emitted at module import time, as the warnings filter override is only put in place during test execution, not during test discovery and loading. * the default ``unittest`` test runner does not currently report deprecation warnings in subprocesses, as the warnings filter override is applied directly to the loaded ``warnings`` module, not to the ``PYTHONWARNINGS`` environment variable. * the standard library doesn't provide a straightforward way to opt-in to seeing all warnings emitted *by* a particular dependency prior to upgrading it (the third-party ``warn`` module [3_] does provide this, but enabling it involves monkeypatching the standard library's ``warnings`` module). * re-enabling deprecation warnings by default in __main__ doesn't help in handling cases where software has been factored out into support modules, but those modules still have little or no automated test coverage. Near term, the best currently available answer is to run such applications with ``PYTHONWARNINGS=default::DeprecationWarning`` or ``python -W default::DeprecationWarning`` and pay attention to their ``stderr`` output. Longer term, this is really a question for researchers working on static analysis of Python code: how to reliably find usage of deprecated APIs, and how to infer that an API or parameter is deprecated based on ``warnings.warn`` calls, without actually running either the code providing the API or the code accessing it While these are real problems with the status quo, they're excluded from consideration in this PEP because they're going to require more complex solutions than a single additional entry in the default warnings filter, and resolving them at least potentially won't require going through the PEP process. For anyone interested in pursuing them further, the first two would be ``unittest`` module enhancement requests, the third would be a ``warnings`` module enhancement request, while the last would only require a PEP if inferring API deprecations from their contents was deemed to be an intractable code analysis problem, and an explicit function and parameter marker syntax in annotations was proposed instead. References ========== .. [1] stdlib-sig thread proposing the original default filter change (https://mail.python.org/pipermail/stdlib-sig/2009-November/000789.html) .. [2] Python 2.7 notification of the default warnings filter change (https://docs.python.org/3/whatsnew/2.7.html#changes-to-the-handling-of-depr…) .. [3] Emitting warnings based on the location of the warning itself (https://pypi.org/project/warn/) Copyright ========= This document has been placed in the public domain. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

11 42

What's the status of PEP 505: None-aware operators?
by Lukasz Langa Dec. 12, 2017

Dec. 12, 2017

Hi Mark, it looks like the PEP is dormant for over two years now. I had multiple people ask me over the past few days about it though, so I wanted to ask if this is moving forward. I also cc python-dev to see if anybody here is strongly in favor or against this inclusion. If the idea itself is uncontroversial, I could likely find somebody interested in implementing it. If not for 3.7 then at least for 3.8. - Ł

25 37

Re: [Python-Dev] Last call for PEP approvals before the holidays
by Nick Coghlan Dec. 12, 2017

Dec. 12, 2017

On 12 Dec. 2017 8:52 am, "Guido van Rossum" <guido(a)python.org> 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.

1 0

Last call for PEP approvals before the holidays
by Guido van Rossum Dec. 11, 2017

Dec. 11, 2017

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)

2 1

PEP 540: Add a new UTF-8 mode (v3)
by Victor Stinner Dec. 11, 2017

Dec. 11, 2017

Hi, I made the following two changes to the PEP 540: * open() error handler remains "strict" * remove the "Strict UTF8 mode" which doesn't make much sense anymore I wrote the Strict UTF-8 mode when open() used surrogateescape error handler in the UTF-8 mode. I don't think that a Strict UTF-8 mode is required just to change the error handler of stdin and stdout. Well, read the "Passthough undecodable bytes: surrogateescape" section of the PEP rationale :-) https://www.python.org/dev/peps/pep-0540/ Victor PEP: 540 Title: Add a new UTF-8 mode Version: $Revision$ Last-Modified: $Date$ Author: Victor Stinner <victor.stinner(a)gmail.com> BDFL-Delegate: INADA Naoki Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 5-January-2016 Python-Version: 3.7 Abstract ======== Add a new UTF-8 mode to ignore the locale, use the UTF-8 encoding, and change ``stdin`` and ``stdout`` error handlers to ``surrogateescape``. This mode is enabled by default in the POSIX locale, but otherwise disabled by default. The new ``-X utf8`` command line option and ``PYTHONUTF8`` environment variable are added to control the UTF-8 mode. Rationale ========= Locale encoding and UTF-8 ------------------------- Python 3.6 uses the locale encoding for filenames, environment variables, standard streams, etc. The locale encoding is inherited from the locale; the encoding and the locale are tightly coupled. Many users inherit the ASCII encoding from the POSIX locale, aka the "C" locale, but are unable change the locale for different reasons. This encoding is very limited in term of Unicode support: any non-ASCII character is likely to cause troubles. It is not easy to get the expected locale. Locales don't get the exact same name on all Linux distributions, FreeBSD, macOS, etc. Some locales, like the recent ``C.UTF-8`` locale, are only supported by a few platforms. For example, a SSH connection can use a different encoding than the filesystem or terminal encoding of the local host. On the other side, Python 3.6 is already using UTF-8 by default on macOS, Android and Windows (PEP 529) for most functions, except of ``open()``. UTF-8 is also the default encoding of Python scripts, XML and JSON file formats. The Go programming language uses UTF-8 for strings. When all data are stored as UTF-8 but the locale is often misconfigured, an obvious solution is to ignore the locale and use UTF-8. PEP 538 attempts to mitigate this problem by coercing the C locale to a UTF-8 based locale when one is available, but that isn't a universal solution. For example, CentOS 7's container images default to the POSIX locale, and don't include the C.UTF-8 locale, so PEP 538's locale coercion is ineffective. Passthough undecodable bytes: surrogateescape --------------------------------------------- When decoding bytes from UTF-8 using the ``strict`` error handler, which is the default, Python 3 raises a ``UnicodeDecodeError`` on the first undecodable byte. Unix command line tools like ``cat`` or ``grep`` and most Python 2 applications simply do not have this class of bugs: they don't decode data, but process data as a raw bytes sequence. Python 3 already has a solution to behave like Unix tools and Python 2: the ``surrogateescape`` error handler (:pep:`383`). It allows to process data "as bytes" but uses Unicode in practice (undecodable bytes are stored as surrogate characters). The UTF-8 mode uses the ``surrogateescape`` error handler for ``stdin`` and ``stdout`` since these streams as commonly associated to Unix command line tools. However, users have a different expectation on files. Files are expected to be properly encoded. Python is expected to fail early when ``open()`` is called with the wrong options, like opening a JPEG picture in text mode. The ``open()`` default error handler remains ``strict`` for these reasons. No change by default for best backward compatibility ---------------------------------------------------- While UTF-8 is perfect in most cases, sometimes the locale encoding is actually the best encoding. This PEP changes the behaviour for the POSIX locale since this locale usually gives the ASCII encoding, whereas UTF-8 is a much better choice. It does not change the behaviour for other locales to prevent any risk or regression. As users are responsible to enable explicitly the new UTF-8 mode, they are responsible for any potential mojibake issues caused by this mode. Proposal ======== Add a new UTF-8 mode to ignore the locale, use the UTF-8 encoding, and change ``stdin`` and ``stdout`` error handlers to ``surrogateescape``. This mode is enabled by default in the POSIX locale, but otherwise disabled by default. The new ``-X utf8`` command line option and ``PYTHONUTF8`` environment variable are added. The UTF-8 mode is enabled by ``-X utf8`` or ``PYTHONUTF8=1``. The POSIX locale enables the UTF-8 mode. In this case, the UTF-8 mode can be explicitly disabled by ``-X utf8=0`` or ``PYTHONUTF8=0``. For standard streams, the ``PYTHONIOENCODING`` environment variable has priority over the UTF-8 mode. On Windows, the ``PYTHONLEGACYWINDOWSFSENCODING`` environment variable (:pep:`529`) has the priority over the UTF-8 mode. Backward Compatibility ====================== The only backward incompatible change is that the UTF-8 encoding is now used for the POSIX locale. Annex: Encodings And Error Handlers =================================== The UTF-8 mode changes the default encoding and error handler used by ``open()``, ``os.fsdecode()``, ``os.fsencode()``, ``sys.stdin``, ``sys.stdout`` and ``sys.stderr``. Encoding and error handler -------------------------- ============================ ======================= ========================== Function Default UTF-8 mode or POSIX locale ============================ ======================= ========================== open() locale/strict **UTF-8**/strict os.fsdecode(), os.fsencode() locale/surrogateescape **UTF-8**/surrogateescape sys.stdin, sys.stdout locale/strict **UTF-8/surrogateescape** sys.stderr locale/backslashreplace **UTF-8**/backslashreplace ============================ ======================= ========================== By comparison, Python 3.6 uses: ============================ ======================= ========================== Function Default POSIX locale ============================ ======================= ========================== open() locale/strict locale/strict os.fsdecode(), os.fsencode() locale/surrogateescape locale/surrogateescape sys.stdin, sys.stdout locale/strict locale/**surrogateescape** sys.stderr locale/backslashreplace locale/backslashreplace ============================ ======================= ========================== Encoding and error handler on Windows ------------------------------------- On Windows, the encodings and error handlers are different: ============================ ======================= ========================== ========================== Function Default Legacy Windows FS encoding UTF-8 mode ============================ ======================= ========================== ========================== open() mbcs/strict mbcs/strict **UTF-8**/strict os.fsdecode(), os.fsencode() UTF-8/surrogatepass **mbcs/replace** UTF-8/surrogatepass sys.stdin, sys.stdout UTF-8/surrogateescape UTF-8/surrogateescape UTF-8/surrogateescape sys.stderr UTF-8/backslashreplace UTF-8/backslashreplace UTF-8/backslashreplace ============================ ======================= ========================== ========================== By comparison, Python 3.6 uses: ============================ ======================= ========================== Function Default Legacy Windows FS encoding ============================ ======================= ========================== open() mbcs/strict mbcs/strict os.fsdecode(), os.fsencode() UTF-8/surrogatepass **mbcs/replace** sys.stdin, sys.stdout UTF-8/surrogateescape UTF-8/surrogateescape sys.stderr UTF-8/backslashreplace UTF-8/backslashreplace ============================ ======================= ========================== The "Legacy Windows FS encoding" is enabled by the ``PYTHONLEGACYWINDOWSFSENCODING`` environment variable. If stdin and/or stdout is redirected to a pipe, ``sys.stdin`` and/or ``sys.output`` use ``mbcs`` encoding by default rather than UTF-8. But in the UTF-8 mode, ``sys.stdin`` and ``sys.stdout`` always use the UTF-8 encoding. .. note: There is no POSIX locale on Windows. The ANSI code page is used to the locale encoding, and this code page never uses the ASCII encoding. Annex: Differences between PEP 538 and PEP 540 ============================================== PEP 538's locale coercion is only effective if a suitable UTF-8 based locale is available as a coercion target. PEP 540's UTF-8 mode can be enabled even for operating systems that don't provide a suitable platform locale (such as CentOS 7). PEP 538 only changes the interpreter's behaviour for the C locale. While the new UTF-8 mode of this PEP is only enabled by default in the C locale, it can also be enabled manually for any other locale. PEP 538 is implemented with ``setlocale(LC_CTYPE, "<coercion target>")`` and ``setenv("LC_CTYPE", "<coercion target>")``, so any non-Python code running in the process and any subprocesses that inherit the environment is impacted by the change. PEP 540 is implemented in Python internals and ignores the locale: non-Python running in the same process is not aware of the "Python UTF-8 mode". The benefit of the PEP 538 approach is that it helps ensure that encoding handling in binary extension modules and subprocesses is consistent with CPython's encoding handling. The upside of the PEP 540 approach is that it allows an embedding application to change the interpreter's behaviour without having to change the process global locale settings. Links ===== * `bpo-29240: Implementation of the PEP 540: Add a new UTF-8 mode <http://bugs.python.org/issue29240>`_ * `PEP 538 <https://www.python.org/dev/peps/pep-0538/>`_: "Coercing the legacy C locale to C.UTF-8" * `PEP 529 <https://www.python.org/dev/peps/pep-0529/>`_: "Change Windows filesystem encoding to UTF-8" * `PEP 528 <https://www.python.org/dev/peps/pep-0528/>`_: "Change Windows console encoding to UTF-8" * `PEP 383 <https://www.python.org/dev/peps/pep-0383/>`_: "Non-decodable Bytes in System Character Interfaces" Post History ============ * 2017-12: `[Python-Dev] PEP 540: Add a new UTF-8 mode <https://mail.python.org/pipermail/python-dev/2017-December/151054.html>`_ * 2017-04: `[Python-Dev] Proposed BDFL Delegate update for PEPs 538 & 540 (assuming UTF-8 for *nix system boundaries) <https://mail.python.org/pipermail/python-dev/2017-April/147795.html>`_ * 2017-01: `[Python-ideas] PEP 540: Add a new UTF-8 mode <https://mail.python.org/pipermail/python-ideas/2017-January/044089.html>`_ * 2017-01: `bpo-28180: Implementation of the PEP 538: coerce C locale to C.utf-8 (msg284764) <https://bugs.python.org/issue28180#msg284764>`_ * 2016-08-17: `bpo-27781: Change sys.getfilesystemencoding() on Windows to UTF-8 (msg272916) <https://bugs.python.org/issue27781#msg272916>`_ -- Victor proposed ``-X utf8`` for the :pep:`529` (Change Windows filesystem encoding to UTF-8) Copyright ========= This document has been placed in the public domain.

7 21

Re: [Python-Dev] What does Android support mean?
by Xavier de Gaye Dec. 11, 2017

Dec. 11, 2017

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

1 0

Mostly Official Python Development Container Image
by Barry Warsaw Dec. 11, 2017

Dec. 11, 2017

As part of our work on importlib_resources, and with some fantastic help from Abhilash Raj, we now have a mostly official Python development container image that you can use for CI testing and other development purposes. This image is based on Ubuntu 16.04 LTS and provides the latest stable releases of Python 2.7, and 3.4-3.6, along with a mostly up-to-date git checkout of master, currently Python 3.7 of course. Once 3.7 is released to beta, we intend to track its release tarballs too. Note that these are pristine builds of upstream releases, so they don’t have any of the Ubuntu or Debian platform changes. We also install a few other commonly needed tools, like pip, git, unzip, wget, mypy, and tox. We do *not* recommend this image for application deployment purposes; use this for development and testing only, please. Here’s the project repo: https://gitlab.com/python-devs/ci-images We’re publishing this image automatically to quay.io, so you can pull the image in a .gitlab-ci.yml file to run tests against all these versions of Python. Here’s an example from the importlib_resources project: https://gitlab.com/python-devs/importlib_resources/blob/master/.gitlab-ci.y… We welcome contributors on the ci-images GitLab project! Cheers, -Barry

2 2