Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

[Victor Stinner]

Hi,

Le 10 déc. 2017 05:48, "INADA Naoki"  a écrit :

Now I'm OK to accept the PEP, except one nitpick.


I got a private email about the same issue. I don't think that it's
nitpicking since many people were confused about the relationship between
the PEP 538 and PEP 540. So it seems like I was confused as well :-) I was
also confused because my PEP evolved quickly. With the additionnal
local.getpreferredenconding() change in my PEP, the two PEP became even
more similar.

> Locale coercion only impacts non-Python code like C libraries, whereas
> the Python UTF-8 Mode only impacts Python code: the two PEPs are
> complementary.
>

This sentence seems bit misleading.
If UTF-8 mode is disabled explicitly, locale coercion affects Python code
too.
locale.getpreferredencoding() is UTF-8, open()' s default encoding is UTF-8,
and stdio is UTF-8/surrogateescape.

So shouldn't this sentence is: "Locale coercion impacts both of Python code
and non-Python code like C libraries, whereas ..."?


Right. I will rephrase it.

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

[Python-Dev] Support of the Android platform

[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 14b*
  This release of the NDK is the first one to use `Unified headers`_ fixing
  numerous problems that had been fixed by updating the Python configure script
  until now (those changes have been reverted by now).

Android idiosyncrasies
==

* The default shell is ``/system/bin/sh``.
* The file system layout is not a traditional unix layout, there is no
  ``/tmp`` for example. Most directories have user restricted access,
  ``/sdcard`` is mounted as ``noexec`` for example.
* The (java) applications are allocated a unix user id and a subdirectory on
  ``/data/data``.
* SELinux is run in enforcing mode.
* Shared memory and semaphores are not supported.
* The default encoding is UTF-8.

Android build system


The Android build system is implemented at `bpo-30386`_ with `PR 1629`_ and
is documented by its `README`_. It provides the following features:

* To build a distribution for a device or an emulator with a given API level
  and a given architecture.
* To start the emulator and
+ install the distribution
+ start a remote interactive shell
+ or run remotely a python command
+ or run remotely the buildbottest
* Run gdb on the python process that is running on the emulator with python
  pretty-printing.

The build system adds the ``Android/`` directory and the ``configure-android``
script to the root of the Python source directory on the master branch without
modifying any other file. The build system can be installed, upgraded (i.e. the
SDK and NDK) and run remotely, through ssh for example.

The following external libraries, when they are configured in the build system,
are downloaded from the internet and cross-compiled (only once, on the first
run of the build system) before the cross-compilation of the extension modules:

* ``ncurses``
* ``readline``
* ``sqlite``
* ``libffi``
* ``openssl``, the cross-compilation of openssl fails on x86_64 and arm64 and
  this step is skipped on those architectures.

The following extension modules are disabled b

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

[Victor Stinner]

Ok, I fixed the effects of the locale coercion (PEP 538). Does it now
look good to you, Naoki?

https://www.python.org/dev/peps/pep-0540/#relationship-with-the-locale-coercion-pep-538

The commit:

https://github.com/python/peps/commit/71cda51fbb622ece63f7a9d3c8fa6cd33ce06b58

diff --git a/pep-0540.txt b/pep-0540.txt
index 0a9cbc1e..c163916d 100644
--- a/pep-0540.txt
+++ b/pep-0540.txt
@@ -144,9 +144,15 @@ The POSIX locale enables the locale coercion (PEP
538) and the UTF-8
 mode (PEP 540). When the locale coercion is enabled, enabling the UTF-8
 mode has no (additional) effect.

-Locale coercion only impacts non-Python code like C libraries, whereas
-the Python UTF-8 Mode only impacts Python code: the two PEPs are
-complementary.
+The UTF-8 has the same effect than locale coercion:
+``sys.getfilesystemencoding()`` returns ``'UTF-8'``,
+``locale.getpreferredencoding()`` returns ``UTF-8``, ``sys.stdin`` and
+``sys.stdout`` error handler set to ``surrogateescape``. These changes
+only affect Python code. But the locale coercion has addiditonal
+effects: the ``LC_CTYPE`` environment variable and the ``LC_CTYPE``
+locale are set to a UTF-8 locale like ``C.UTF-8``. The side effect is
+that non-Python code is also impacted by the locale coercion. The two
+PEPs are complementary.

 On platforms where locale coercion is not supported like Centos 7, the
 POSIX locale only enables the UTF-8 Mode. In this case, Python code uses

Victor


2017-12-10 5:47 GMT+01:00 INADA Naoki :
> Now I'm OK to accept the PEP, except one nitpick.
>
>>
>> Locale coercion only impacts non-Python code like C libraries, whereas
>> the Python UTF-8 Mode only impacts Python code: the two PEPs are
>> complementary.
>>
>
> This sentence seems bit misleading.
> If UTF-8 mode is disabled explicitly, locale coercion affects Python code too.
> locale.getpreferredencoding() is UTF-8, open()' s default encoding is UTF-8,
> and stdio is UTF-8/surrogateescape.
>
> So shouldn't this sentence is: "Locale coercion impacts both of Python code
> and non-Python code like C libraries, whereas ..."?
>
> INADA Naoki  
___
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 540: Add a new UTF-8 mode (v3)

[INADA Naoki]

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.

INADA Naoki  


On Mon, Dec 11, 2017 at 2:21 AM, Victor Stinner
 wrote:
> Ok, I fixed the effects of the locale coercion (PEP 538). Does it now
> look good to you, Naoki?
>
> https://www.python.org/dev/peps/pep-0540/#relationship-with-the-locale-coercion-pep-538
>
> The commit:
>
> https://github.com/python/peps/commit/71cda51fbb622ece63f7a9d3c8fa6cd33ce06b58
>
> diff --git a/pep-0540.txt b/pep-0540.txt
> index 0a9cbc1e..c163916d 100644
> --- a/pep-0540.txt
> +++ b/pep-0540.txt
> @@ -144,9 +144,15 @@ The POSIX locale enables the locale coercion (PEP
> 538) and the UTF-8
>  mode (PEP 540). When the locale coercion is enabled, enabling the UTF-8
>  mode has no (additional) effect.
>
> -Locale coercion only impacts non-Python code like C libraries, whereas
> -the Python UTF-8 Mode only impacts Python code: the two PEPs are
> -complementary.
> +The UTF-8 has the same effect than locale coercion:
> +``sys.getfilesystemencoding()`` returns ``'UTF-8'``,
> +``locale.getpreferredencoding()`` returns ``UTF-8``, ``sys.stdin`` and
> +``sys.stdout`` error handler set to ``surrogateescape``. These changes
> +only affect Python code. But the locale coercion has addiditonal
> +effects: the ``LC_CTYPE`` environment variable and the ``LC_CTYPE``
> +locale are set to a UTF-8 locale like ``C.UTF-8``. The side effect is
> +that non-Python code is also impacted by the locale coercion. The two
> +PEPs are complementary.
>
>  On platforms where locale coercion is not supported like Centos 7, the
>  POSIX locale only enables the UTF-8 Mode. In this case, Python code uses
>
> Victor
>
>
> 2017-12-10 5:47 GMT+01:00 INADA Naoki :
>> Now I'm OK to accept the PEP, except one nitpick.
>>
>>>
>>> Locale coercion only impacts non-Python code like C libraries, whereas
>>> the Python UTF-8 Mode only impacts Python code: the two PEPs are
>>> complementary.
>>>
>>
>> This sentence seems bit misleading.
>> If UTF-8 mode is disabled explicitly, locale coercion affects Python code 
>> too.
>> locale.getpreferredencoding() is UTF-8, open()' s default encoding is UTF-8,
>> and stdio is UTF-8/surrogateescape.
>>
>> So shouldn't this sentence is: "Locale coercion impacts both of Python code
>> and non-Python code like C libraries, whereas ..."?
>>
>> INADA Naoki  
___
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 540: Add a new UTF-8 mode (v3)

[Victor Stinner]

2017-12-10 18:46 GMT+01:00 INADA Naoki :
> Except one typo I commented on Github,

Fixed: 
https://github.com/python/peps/commit/08224bf6bdf16b539fb6f8136061877e5924476d

> I accept PEP 540.

Wow, thank you :-) Again, thank you for your very useful feedback
which helped to make the PEP 540 much better than its initial version.

> Well done, Victor and Nick for PEP 540 and 538.
> Python 3.7 will be most UTF-8 friendly Python 3 than ever.

Yep. Once the PEP 540 will be implemented, we will need need to test
them as much as possible before 3.7 final!

https://bugs.python.org/issue29240
https://github.com/python/cpython/pull/855

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

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

[Toshio Kuratomi]

On Dec 9, 2017 8:53 PM, "INADA Naoki"  wrote:

> Earlier versions of PEP 538 thus included "en_US.UTF-8" on the
> candidate target locale list, but that turned out to cause assorted
> problems due to the "C -> en_US" part of the coercion.

Hm, but PEP 538 says:

> this PEP instead proposes to extend the "surrogateescape" default for
stdin and stderr error handling to also apply to the three potential
coercion target locales.

https://www.python.org/dev/peps/pep-0538/#defaulting-to-
surrogateescape-error-handling-on-the-standard-io-streams

I don't think en_US.UTF-8 should use surrogateescape error handler.


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.

-Toshio
___
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] Issues with PEP 526 Variable Notation at the class level

[Tin Tvrtković]

Hello,

I'm one of the attrs contributors, and the person who initially wrote the
slots functionality there.

We've given up on returning a new class always since this can conflict with
certain metaclasses (have you noticed you can't make a slots attrs class
inheriting from Generic[T]?) and with PEP 487. I think with PEP 487 it's
becoming especially evident class creation is not necessarily an idempotent
operation.

I'm currently brainstorming alternative APIs for slots. The best solution
would be for Python to actually offer a way to add slotness to a class
after it's been defined, and Guido has expressed approval (
https://github.com/ericvsmith/dataclasses/issues/60#issuecomment-348719029).

Personally I really like slot classes, both for their memory
characteristics and the fact the attributes need to be enumerated
beforehand and typos get turned into errors, so I'd welcome any development
on this front. :)


Date: Sat, 9 Dec 2017 08:52:15 -0500
> From: "Eric V. Smith" 
> To: Nathaniel Smith 
> Cc: Python Dev 
> Subject: Re: [Python-Dev] Issues with PEP 526 Variable Notation at the
> class level
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 12/8/2017 9:14 PM, Nathaniel Smith wrote:
> > On Dec 7, 2017 12:49, "Eric V. Smith"  > > wrote:
> >
> > The reason I didn't include it (as @dataclass(slots=True)) is
> > because it has to return a new class, and the rest of the dataclass
> > features just modifies the given class in place. I wanted to
> > maintain that conceptual simplicity. But this might be a reason to
> > abandon that. For what it's worth, attrs does have an
> > @attr.s(slots=True) that returns a new class with __slots__ set.
> >
> >
> > They actually switched to always returning a new class, regardless of
> > whether slots is set:
> >
> > https://github.com/python-attrs/attrs/pull/260
>
> In the end, it looks like that PR ended up just refactoring things, and
> the decision to always return a new class was deferred. I still haven't
> finished evaluating exactly what the refactoring does, though.
>
> Eric.
>
> > You'd have to ask Hynek to get the full rationale, but I believe it was
> > both for consistency with slot classes, and for consistency with regular
> > class definition. For example, type.__new__ actually does different
> > things depending on whether it sees an __eq__ method, so adding a method
> > after the fact led to weird bugs with hashing. That class of bug goes
> > away if you always set up the autogenerated methods and then call
> > type.__new__.
>
> They have a bunch of test cases that I'll have to review, too.
>
> Eric.
> -
>
___
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] Issues with PEP 526 Variable Notation at the class level

[Antoine Pitrou]

Hi,

On Sun, 10 Dec 2017 19:17:25 +
Tin Tvrtković  wrote:
> Hello,
> 
> I'm one of the attrs contributors, and the person who initially wrote the
> slots functionality there.
> 
> We've given up on returning a new class always since this can conflict with
> certain metaclasses (have you noticed you can't make a slots attrs class
> inheriting from Generic[T]?) and with PEP 487. I think with PEP 487 it's
> becoming especially evident class creation is not necessarily an idempotent
> operation.

Hmm... I understand you may be restricted by backwards compatibility
here.  But dataclasses don't have that issue, so we could decide we're
incompatible with certain dataclasses from day 1.

> I'm currently brainstorming alternative APIs for slots. The best solution
> would be for Python to actually offer a way to add slotness to a class
> after it's been defined, and Guido has expressed approval (
> https://github.com/ericvsmith/dataclasses/issues/60#issuecomment-348719029).

The problem is less the API but the implementation.  As Guido pointed
out, this means the instance layout may now change after class
definition.  One possibility would be to allow changing the layout
before the first instance (or even subclass) is instantiated, after
which it would raise an error.

Regards

Antoine.


___
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

[Brett Cannon]

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? :)

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.
>
> 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 14b*
>This release of the NDK is the first one to use `Unified headers`_
> fixing
>numerous problems that had been fixed by updating the Python configure
> script
>until now (those changes have been reverted by now).
>
> Android idiosyncrasies
> ==
>
> * The default shell is ``/system/bin/sh``.
> * The file system layout is not a traditional unix layout, there is no
>``/tmp`` for example. Most directories have user restricted access,
>``/sdcard`` is mounted as ``noexec`` for example.
> * The (java) applications are allocated a unix user id and a subdirectory
> on
>``/data/data``.
> * SELinux is run in enforcing mode.
> * Shared memory and semaphores are not supported.
> * The default encoding is UTF-8.
>
> Android build system
> 
>
> The Android build system is implemented at `bpo-30386`_ with `PR 1629`_ and
> is documented by its `README`_. It provides the following features:
>
> * To build a distribution for a device or an emulator with a given API
> level
>and a given architecture.
> * To start the emulator and
>  + install the distribution
>  + start a remote interactive shell
>  + or run remotely a python command
>  + or run remotely the buildbottest
> * Run gdb on the python process that is running on the emulator with python
>pretty-printing.
>
> The build system adds the ``Android/`` directory and the
> ``configure-android``
> script to the root of the Python source di

Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level

[Antoine Pitrou]

On Sun, 10 Dec 2017 20:47:45 +0100
Antoine Pitrou  wrote:

> Hi,
> 
> On Sun, 10 Dec 2017 19:17:25 +
> Tin Tvrtković  wrote:
> > Hello,
> > 
> > I'm one of the attrs contributors, and the person who initially wrote the
> > slots functionality there.
> > 
> > We've given up on returning a new class always since this can conflict with
> > certain metaclasses (have you noticed you can't make a slots attrs class
> > inheriting from Generic[T]?) and with PEP 487. I think with PEP 487 it's
> > becoming especially evident class creation is not necessarily an idempotent
> > operation.  
> 
> Hmm... I understand you may be restricted by backwards compatibility
> here.  But dataclasses don't have that issue, so we could decide we're
> incompatible with certain dataclasses from day 1.

Sorry... make that "incompatible with certain metaclasses" ;-)

Regards

Antoine.


___
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] Issues with PEP 526 Variable Notation at the class level

[Guido van Rossum]

OTOH daytaclass is a decorator for *better* metaclass compatibility.

On Dec 10, 2017 13:17, "Antoine Pitrou"  wrote:

> On Sun, 10 Dec 2017 20:47:45 +0100
> Antoine Pitrou  wrote:
>
> > Hi,
> >
> > On Sun, 10 Dec 2017 19:17:25 +
> > Tin Tvrtković  wrote:
> > > Hello,
> > >
> > > I'm one of the attrs contributors, and the person who initially wrote
> the
> > > slots functionality there.
> > >
> > > We've given up on returning a new class always since this can conflict
> with
> > > certain metaclasses (have you noticed you can't make a slots attrs
> class
> > > inheriting from Generic[T]?) and with PEP 487. I think with PEP 487
> it's
> > > becoming especially evident class creation is not necessarily an
> idempotent
> > > operation.
> >
> > Hmm... I understand you may be restricted by backwards compatibility
> > here.  But dataclasses don't have that issue, so we could decide we're
> > incompatible with certain dataclasses from day 1.
>
> Sorry... make that "incompatible with certain metaclasses" ;-)
>
> Regards
>
> Antoine.
>
>
> ___
> 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/
> guido%40python.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] Is static typing still optional?

[Raymond Hettinger]

The make_dataclass() factory function in the dataclasses module currently 
requires type declarations. It would be nice if the type declarations were 
optional.

With typing (currently works):

Point = NamedTuple('Point', [('x', float), ('y', float), ('z', float)])
Point = make_dataclass('Point', [('x', float), ('y', float), ('z', float)])

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

This proposal would make it easy to cleanly switch between the immutable 
tuple-based container and the instancedict-based optionally-frozen container. 
The proposal would make it possible for instructors to teach dataclasses 
without having to teach typing as a prerequisite. And, it would make 
dataclasses usable for projects that have elected not to use static typing.


Raymond

___
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

[Guido van Rossum]

Maybe it should be a PEP?

On Dec 10, 2017 12:29, "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? :)
>
> 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.
>>
>> 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 14b*
>>This release of the NDK is the first one to use `Unified headers`_
>> fixing
>>numerous problems that had been fixed by updating the Python configure
>> script
>>until now (those changes have been reverted by now).
>>
>> Android idiosyncrasies
>> ==
>>
>> * The default shell is ``/system/bin/sh``.
>> * The file system layout is not a traditional unix layout, there is no
>>``/tmp`` for example. Most directories have user restricted access,
>>``/sdcard`` is mounted as ``noexec`` for example.
>> * The (java) applications are allocated a unix user id and a subdirectory
>> on
>>``/data/data``.
>> * SELinux is run in enforcing mode.
>> * Shared memory and semaphores are not supported.
>> * The default encoding is UTF-8.
>>
>> Android build system
>> 
>>
>> The Android build system is implemented at `bpo-30386`_ with `PR 1629`_
>> and
>> is documented by its `README`_. It provides the following features:
>>
>> * To build a distribution for a device or an emulator with a given API
>> level
>>and a given architecture.
>> * To start the emulator and
>>  + install the distribution
>>  + start a remote interactive shell
>>  + or run remotely a python command
>>  + or run remotely the buildbottest
>> * Run

Re: [Python-Dev] Is static typing still optional?

[Ivan Levkivskyi]

On 10 December 2017 at 22:24, Raymond Hettinger  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.

--
Ivan
___
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

[Skip Montanaro]

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
___
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 static typing still optional?

[Eric V. Smith]

On 12/10/2017 4:29 PM, Ivan Levkivskyi wrote:
On 10 December 2017 at 22:24, Raymond Hettinger 
mailto:raymond.hettin...@gmail.com>> 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.

Eric.

___
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 static typing still optional?

[Raymond Hettinger]

> 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:raymond.hettin...@gmail.com>> 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.
> 
> Eric.

Thanks Eric and Ivan.  You're both very responsive.  I appreciate the enormous 
efforts you're putting in to getting this right.

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)

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 ;-)


Raymond


___
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

[Ned Deily]

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

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

[Guido van Rossum]

Sure. I think it's a good idea to make this a guaranteed language behavior,
and it doesn't need a PEP.

On Sun, Dec 10, 2017 at 1:52 PM, Larry Hastings  wrote:

>
> Can I get a ruling on this?  I got +1s from the community, but as it's a
> (minor) language thing I feel like you're the only one who can actually
> okay it.
>
>
> */arry*
>
>
>  Forwarded Message 
> Subject: Can Python guarantee the order of keyword-only parameters?
> Date: Mon, 27 Nov 2017 09:05:57 -0800
> From: Larry Hastings  
> To: Python-Dev  
>
>
>
> First, a thirty-second refresher, so we're all using the same terminology:
>
> A *parameter* is a declared input variable to a function.
> An *argument* is a value passed into a function.  (*Arguments* are stored
> in *parameters.*)
>
> So in the example "def foo(clonk): pass; foo(3)", clonk is a parameter,
> and 3 is an argument. ++
>
>
> Keyword-only arguments were conceived of as being unordered.  They're
> stored in a dictionary--by convention called **kwargs--and dictionaries
> didn't preserve order.  But knowing the order of arguments is occasionally
> very useful.  PEP 468 proposed that Python preserve the order of
> keyword-only arguments in kwargs.  This became easy with the
> order-preserving dictionaries added to Python 3.6.  I don't recall the
> order of events, but in the end PEP 468 was accepted, and as of 3.6 Python
> guarantees order in **kwargs.
>
> But that's arguments.  What about parameters?
>
> Although this isn't as directly impactful, the order of keyword-only
> parameters *is* visible to the programmer.  The best way to see a
> function's parameters is with inspect.signature, although there's also the
> deprecated inspect.getfullargspec; in CPython you can also directly examine
> fn.__code__.co_varnames.  Two of these methods present their data in a way
> that preserves order for all parameters, including keyword-only
> parameters--and the third one is deprecated.
>
> Python must (and does) guarantee the order of positional and
> positional-or-keyword parameters, because it uses position to map arguments
> to parameters when the function is called.  But conceptually this isn't
> necessary for keyword-only parameters because their position is
> irrelevant.  I only see one place in the language & library that addresses
> the ordering of keyword-only parameters, by way of omission.  The PEP for
> inspect.signature (PEP 362) says that when comparing two signatures for
> equality, their positional and positional-or-keyword parameters must be in
> the same order.  It makes a point of *not* requiring that the two
> functions' keyword-only parameters be in the same order.
>
> For every currently supported version of Python 3, inspect.signature and
> fn.__code__.co_varnames preserve the order of keyword-only parameters.
> This isn't surprising; it's basically the same code path implementing those
> as the two types of positional-relevant parameters, so the most
> straightforward implementation would naturally preserve their order.  It's
> just not guaranteed.
>
> I'd like inspect.signature to guarantee that the order of keyword-only
> parameters always matches the order they were declared in.  Technically
> this isn't a language feature, it's a library feature.  But making this
> guarantee would require that CPython internally cooperate, so it's kind of
> a language feature too.
>
> Does this sound reasonable?  Would it need a PEP?  I'm hoping for "yes"
> and "no", respectively.
>
>
> Three final notes:
>
>- Yes, I do have a use case.  I'm using inspect.signature metadata to
>mechanically map arguments from an external domain (command-line arguments)
>to a Python function.  Relying on the declaration order of keyword-only
>parameters would elegantly solve one small problem.
>- I asked Armin Rigo about PyPy's support for Python 3.  He said it
>should already maintain the order of keyword-only parameters, and if I ever
>catch it not maintaining them in order I should file a bug.  I assert that
>making this guarantee would be nearly zero effort for any Python
>implementation--I bet they all already behave this way, all they need is a
>test case and some documentation.
>- One can extend this concept to functools.partial and
>inspect.Signature.bind: should its transformations of keyword-only
>parameters also maintain order in a consistent way?  I suspect the answer
>there is much the same--there's an obvious way it should behave, it almost
>certainly already behaves that way, but it doesn't guarantee it.  I don't
>think I need this for my use case.
>
>
>
> */arry*
>
> ++ Yes, that means "Argument Clinic" should really have been called
> "Parameter Clinic".  But the "Parameter Clinic" sketch is nowhere near as
> funny.
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho

Re: [Python-Dev] Support of the Android platform

[Guido van Rossum]

I think someone may have to mentor Xavier on how to get this accepted. The
note already looks a bit like a PEP, but I suspect that Xavier is not
sufficiently familiar with our process to realize the difference.

On Sun, Dec 10, 2017 at 2:07 PM, Ned Deily  wrote:

> 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 -- []
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
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 static typing still optional?

[Eric V. Smith]

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:raymond.hettin...@gmail.com>> 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.

Eric.


Thanks Eric and Ivan.  You're both very responsive.  I appreciate the enormous 
efforts you're putting in to getting this right.


Thank you for your feedback. It's very helpful.

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. However, typing is not currently 
imported by dataclasses.py. There's an argument that it really needs to 
be, and I should just bite the bullet and live with it. Possibly with 
Ivan's PEP 560 work my concern on importing typing goes away.


1b would be easy, but I don't like using non-types for annotations. 2 
would be okay, but then that would be the only time __annotations__ 
wouldn't be set on a dataclass.



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)


Agreed.


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 ;-)


It's sufficiently confusing that I need to sit down when I have some 
free time and noodle this through. But it's still on my radar.


Eric.

___
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

[Victor Stinner]

Xavier is working on fixing random issues specific to Android since 2
years. He is almost done, the last step is just to add a build infra to get
a buildbot.

https://github.com/python/cpython/pull/1629
https://bugs.python.org/issue30386

It's a set of scripts to cross compile Python from Linux to Android.

>From the ones who missed it, Xavier is a core dev and will maintain this
stuff ;-)

Since these changes add a new directory without touching the rest of the
code, I don't see a reason to not add it.

Victor

Le 10 déc. 2017 21:29, "Brett Cannon"  a écrit :

> 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? :)
>
> 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.
>>
>> 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 14b*
>>This release of the NDK is the first one to use `Unified headers`_
>> fixing
>>numerous problems that had been fixed by updating the Python configure
>> script
>>until now (those changes have been reverted by now).
>>
>> Android idiosyncrasies
>> ==
>>
>> * The default shell is ``/system/bin/sh``.
>> * The file system layout is not a traditional unix layout, there is no
>>``/tmp`` for example. Most directories have user restricted access,
>>``/sdcard`` is mounted as ``noexec`` for example.
>> * The (java) applications are allocated a unix user id and a subdirectory
>> on
>>``/data/data``.
>> * SELinux is run in enforcing mode.
>> * Shared memory and semaphores are not supported.
>> * The default encoding is UTF-8.
>>
>> Android build system
>> 

Re: [Python-Dev] Support of the Android platform

[Victor Stinner]

Le 10 déc. 2017 23:10, "Ned Deily"  a écrit :
> But on the other, it does add a large non-zero burden to all core
developers (...)

I reviewed some of the Android' pull requests. Most changes are small and
self contained.

> 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.

Xavier is a core dev and wants to add a buildbot to finish to support of
Android.

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

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

[INADA Naoki]

>
> 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
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] Mostly Official Python Development Container Image

[Barry Warsaw]

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.yml

We welcome contributors on the ci-images GitLab project!

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Mostly Official Python Development Container Image

[Ryan Gonzalez]

Question: why is this using GitLab while CPython itself is using GitHub + 
Travis?

On December 10, 2017 6:13:53 PM CST, Barry Warsaw  wrote:
>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.yml
>
>We welcome contributors on the ci-images GitLab project!
>
>Cheers,
>-Barry

--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/___
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] Mostly Official Python Development Container Image

[Barry Warsaw]

On Dec 10, 2017, at 19:36, Ryan Gonzalez  wrote:
> 
> Question: why is this using GitLab while CPython itself is using GitHub + 
> Travis?

Mostly because Brett gave me the option to use GitLab for importlib_resources, 
and this grew out of that.  Enjoy!

overturn-pep-507-ly y’rs,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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