Re: [Python-Dev] Positional-only parameters in Python

[Nick Coghlan]

On 20 January 2018 at 15:00, Guido van Rossum  wrote:
> On Fri, Jan 19, 2018 at 8:47 PM, Nick Coghlan  wrote:
>>
>> On 20 January 2018 at 07:49, Mario Corchero  wrote:
>> > I am happy to put some work into this (and Pablo Galindo in CC offered
>> > to
>> > pair on it) but it is not clear for me whether the next step is drafting
>> > a
>> > new PEP or this is just blocked on "re-evaluating" the current one.
>>
>> I think that would be a question for Larry,
>
> I think you meant for Guido. It's not Larry's language (yet :-).

I did mean Larry, but I was unduly vague about the specific question I
was referring to (I wasn't sure if Larry might want to repurpose PEP
457 itself for this proposal).

It sounds like we're going to go with the option of a new PEP though,
crediting Larry with the design, which seems like a good option to me.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Unique loader per module

[Nick Coghlan]

On 21 January 2018 at 01:56, Barry Warsaw  wrote:
> On Jan 05, 2018, at 05:12 PM, Nick Coghlan wrote:
>
>>I think the main reason you're seeing a problem here is because
>>ResourceReader has currently been designed to be implemented directly
>>by loaders, rather than being a subcomponent that you can request
>>*from* a loader.
>>
>>If you instead had an indirection API (that could optionally return
>>self in the case of non-shared loaders), you'd keep the current
>>resource reader method signatures, but the way you'd access the itself
>>would be:
>>
>>resources = module.__spec__.loader.get_resource_reader(module)
>># resources implements the ResourceReader ABC
>
> BTW, just as a quick followup, this API suggestion was brilliant, Nick.  It
> solved the problem nicely, and let me add support for ResourceReader to
> zipimport with only touching the bare minimum of zipimport.c. :)

As API design rules of thumb go, "Prefer composition to inheritance"
is one I've come to respect a *lot* :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

[Nick Coghlan]

On 22 January 2018 at 20:57, Victor Stinner  wrote:
> I created an issue with more information:
> https://bugs.python.org/issue32620

We shouldn't be requiring a pre-existing Python to build CPython
anyway, so it would be nice if we could just delete that step
entirely.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

[Larry Hastings]

On 01/22/2018 07:51 AM, Brett Cannon wrote:
I can switch off the requirement that holds admins to having to pass 
the same status checks as everyone else (there's still a big warning 
when you exercise this power), that way you can override the merge if 
you want. Not sure if you want to ignore the CI in that case as well.


Yes, please.  I'll make you a deal: I'll download and apply the patches 
manually and run the test suite.  I'll only merge if the patch doesn't 
cause test failures.


It'd be swell if we could actually fix the builds on Travis CI 
naturally.  I assume that will happen eventually, but I don't want to 
hold up the rc's for that.


Thanks,


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Intention to accept PEP 567 (Context Variables)

[Ethan Furman]

On 01/22/2018 03:52 PM, Guido van Rossum wrote:


I am hereby *accepting* the latest version of PEP 567[1]. Congrats!


Congratulations, Yury!

--
~Ethan~

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Intention to accept PEP 567 (Context Variables)

[Victor Stinner]

The PEP 555 looks a competitor PEP of the PEP 567. Since the Yury's
PEP 567 was approved, I understand that Koos's PEP 555 should be
rejected, no?

Victor

2018-01-23 0:52 GMT+01:00 Guido van Rossum :
> Yury,
>
> I am hereby *accepting* the latest version of PEP 567[1]. Congrats!
>
> --Guido
>
> [1]
> https://github.com/python/peps/commit/a459539920b9b8c8394ef61058e88a076ef8b133#diff-9d0ccdec754459da5f665cc6c6b2cc06
>
> On Fri, Jan 19, 2018 at 9:30 AM, Guido van Rossum  wrote:
>>
>> There has been useful and effective discussion on several of the finer
>> points of PEP 567. I think we've arrived at a solid specification, where
>> every part of the design is well motivated. I plan to accept it on Monday,
>> unless someone brings up something significant that we've overlooked before
>> then. Please don't rehash issues that have already been debated -- we're
>> unlikely to reach a different conclusion upon revisiting the same issue
>> (read the Rejected Ideas section first).
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>
>
>
>
> --
> --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/victor.stinner%40gmail.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] Intention to accept PEP 567 (Context Variables)

[Yury Selivanov]

Yay! Thank you, Guido!

Yury

On Mon, Jan 22, 2018 at 6:52 PM, Guido van Rossum  wrote:
> Yury,
>
> I am hereby *accepting* the latest version of PEP 567[1]. Congrats!
>
> --Guido
>
> [1]
> https://github.com/python/peps/commit/a459539920b9b8c8394ef61058e88a076ef8b133#diff-9d0ccdec754459da5f665cc6c6b2cc06
>
> On Fri, Jan 19, 2018 at 9:30 AM, Guido van Rossum  wrote:
>>
>> There has been useful and effective discussion on several of the finer
>> points of PEP 567. I think we've arrived at a solid specification, where
>> every part of the design is well motivated. I plan to accept it on Monday,
>> unless someone brings up something significant that we've overlooked before
>> then. Please don't rehash issues that have already been debated -- we're
>> unlikely to reach a different conclusion upon revisiting the same issue
>> (read the Rejected Ideas section first).
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>
>
>
>
> --
> --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/yselivanov.ml%40gmail.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] Intention to accept PEP 567 (Context Variables)

[Guido van Rossum]

Yury,

I am hereby *accepting* the latest version of PEP 567[1]. Congrats!

--Guido

[1]
https://github.com/python/peps/commit/a459539920b9b8c8394ef61058e88a076ef8b133#diff-9d0ccdec754459da5f665cc6c6b2cc06

On Fri, Jan 19, 2018 at 9:30 AM, Guido van Rossum  wrote:

> There has been useful and effective discussion on several of the finer
> points of PEP 567. I think we've arrived at a solid specification, where
> every part of the design is well motivated. I plan to accept it on Monday,
> unless someone brings up something significant that we've overlooked before
> then. Please don't rehash issues that have already been debated -- we're
> unlikely to reach a different conclusion upon revisiting the same issue
> (read the Rejected Ideas section first).
>
> --
> --Guido van Rossum (python.org/~guido)
>



-- 
--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] Unexpected bytecode difference

[Alexander Belopolsky]

On Fri, Jan 19, 2018 at 7:18 PM, Victor Stinner
 wrote:
> It seems like the EXTENDED_ARG doc wasn't updated.

I've opened  to update the dis
module documentation.

I have also found a patch (mkfu4.patch) attached to issue 27095 where
EXTENDED_ARG is described as

 .. opcode:: EXTENDED_ARG (ext)

   EXTENDED_ARG adds ``*ext* * 256`` to the next instruction's argument.
   This is used for arguments exceeding a byte in size, and can be chained
   to create 4-byte arguments.

I am not sure this is correct.  First, multiple EXTENDED_ARG codes
seem to add ext * 256 ** i or bit-append ext to arg. Second, it looks
like this mechanism allows forming arguments of arbitrary bit length,
not just 4-byte arguments.
___
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] Drop support for old unsupported FreeBSD and Linux kernels?

[Victor Stinner]

I asked if we should drop support for Linux kernel 2.6. I now consider
that no, we should not. It's not worth it.

A colleague proposed to setup a RHEL 6 buildbot which would test
Python on Linux 2.6.


2018-01-19 10:26 GMT+01:00 Antoine Pitrou :
> What is the problem with supporting Linux 2.6?

It increases the code size base. This compatibility code has to be
maintained. It would even be better to make sure that it's tested ;-)


> Do we need to rely on newer features? (which ones?)

My pull request which removed support for FreeBSD 9 and older was
quite large and so it was interesting to do it:
https://github.com/python/cpython/commit/13ff24582c99dfb439b1af7295b401415e7eb05b

According to reactions on this thread, I'm not sure anymore that
removing a few lines of C code is worth it compared to loosing support
for Linux 2.6 which seems to be important for many users.

Python has some fallback code for "recent" Linux features like
SOCK_CLOEXEC, accept4(), getrandom(), epoll_create1(), open() and
O_CLOEXEC, etc.

The worst part is that Python has to check once per process that
open() doesn't ignore O_CLOEXEC flag. It requires one extra syscall.
But well, compared to the total number of syscalls just for "python3
-c pass", this syscall is likely negligible :-)

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] Drop support for old unsupported FreeBSD and Linux kernels?

[Victor Stinner]

2018-01-18 21:27 GMT+01:00 Victor Stinner :
> I proposed: "Drop FreeBSD 9 and older support:"
>
>   https://bugs.python.org/issue32593
>   https://github.com/python/cpython/pull/5232
>
> FreeBSD 9 supported ended 1 year ago (December 2016).
>
> FreeBSD support:
>
>   https://www.freebsd.org/security/
>   https://www.freebsd.org/security/unsupported.html

FYI I merged this PR. I'm open to discuss reverting this change if
anyone complains.

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] Support of the Android platform

[Victor Stinner]

Hi,

I'm still talking with Paul Peny (pmpp on IRC) who is trying to build
the master branch of Python on Android, using cross-compilation or
directly on an Android device. I started to took notes since Android
is a complex platforms and it's not easy for me to remember
everything.

http://vstinner.readthedocs.io/python_android.html

Paul would like to support Android 4.4 Kitkat (API 19) just because
it's possible to find cheap devices running Android, but usually only
with old Android versions. Technically, it doesn't see difficult to
support API 19+ (instead of 21+), a few tiny patches are needed. But I
don't want to have a "full support" of API 19+, only basic support
like "make sure that the compilation doesn't fail", not "all tests
must pass".

It seems like sys.platform == 'android' would be more appropriate
since Android is not Linux: different libc, different filesystems,
etc.

While Xavier promotes cross-compilation, Paul would like to build
Python directly on Android to get pip and wheels.

Honestly, I have no strong opinion, since I don't know well Android.
I'm trying to help everybody working on the Android support. IMHO it's
fine to support multiple ways to build Python for Android. It's not
like there is very obvious option which has no drawback... Cross
compilation is complex, getting a C compiler on Android also seems to
be complex. From my point of view, compared to a common Fedora Linux,
Android doesn't seem easy to use to develop on CPython...

Victor

2017-12-10 15:19 GMT+01:00 Xavier de Gaye :
> The following note is a proposal to add the support of the Android platform.
>
> The note is easier to read with clickable links at
> https://github.com/xdegaye/cagibi/blob/master/doc/android_support.rst
>
> Motivations
> ===
>
> * Android is ubiquitous.
> * This would be the first platform supported by Python that is
> cross-compiled,
>   thanks to many contributors.
> * Although the Android operating system is linux, it is different from most
>   linux platforms, for example it does not use GNU libc and runs SELinux in
>   enforcing mode. Therefore supporting this platform would make Python more
>   robust and also would allow testing it on arm 64-bit processors.
> * Python running on Android is also a handheld calculator, a successor of
> the
>   slide rule and the `HP 41`_.
>
> Current status
> ==
>
> * The Python test suite succeeds when run on Android emulators using
> buildbot
>   strenuous settings with the following architectures on API 24: x86,
> x86_64,
>   armv7 and arm64.
> * The `Android build system`_ is described in another section.
> * The `buildmaster-config PR 26`_ proposes to update ``master.cfg`` to
> enable
>   buildbots to run a given Android API and architecture on the emulators.
> * The Android emulator is actually ``qemu``, so the test suites for x86 and
>   x86_64 last about the same time as the test suite run natively when the
>   processor of the build system is of the x86 family. The test suites for
> the
>   arm architectures last much longer: about 8 hours for arm64 and 10 hours
> for
>   armv7 on a four years old laptop.
> * The changes that have been made to achieve this status are listed in
>   `bpo-26865`_, the Android meta-issue.
> * Given the cpu resources required to run the test suite on the arm
> emulators,
>   it may be difficult to find a contributed buildbot worker. So it remains
> to
>   find the hardware to run these buildbots.
>
> Proposal
> 
>
> Support the Android platform on API 24 [1]_ for the x86_64, armv7 and arm64
> architectures built with NDK 14b.
>
> *API 24*
>   * API 21 is the first version to provide usable support for wide
> characters
> and where SELinux is run in enforcing mode.
>
>   * API 22 introduces an annoying bug on the linker that prints something
> like
> this when python is started::
>
>   ``WARNING: linker: libpython3.6m.so.1.0: unused DT entry: type
> 0x6ffe arg 0x14554``.
>
> The `termux`_ Android terminal emulator describes this problem at the
> end
> of its `termux-packages`_ gitlab page and has implemented a
> ``termux-elf-cleaner`` tool to strip the useless entries from the ELF
> header of executables.
>
>   * API 24 is the first version where the `adb`_ shell is run on the
> emulator
> as a ``shell`` user instead of the ``root`` user previously, and the
> first
> version that supports arm64.
>
> *x86_64*
>   It seems that no handheld device exists using that architecture. It is
>   supported because the x86_64 Android emulator runs fast and therefore is a
>   good candidate as a buildbot worker.
>
> *NDK 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 

Re: [Python-Dev] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

[Brett Cannon]

I can switch off the requirement that holds admins to having to pass the
same status checks as everyone else (there's still a big warning when you
exercise this power), that way you can override the merge if you want. Not
sure if you want to ignore the CI in that case as well.

On Mon, 22 Jan 2018 at 02:33 Larry Hastings  wrote:

>
>
> I have three PRs for Python 3.5.5rc1:
>
> https://github.com/python/cpython/pull/4656
> https://github.com/python/cpython/pull/5197
> https://github.com/python/cpython/pull/5201
>
> I can't merge them because Travis CI is unhappy.  All three CI tests fail
> in the same way, reporting this error:
>
> The command "pyenv global system 3.5" failed and exited with 1 during .
>
> Since Travis CI is a "required check", Github won't let me merge the PR.
> Yes I could manually merge the patches by hand but I'm hoping it doesn't
> come to that.
>
> I'm slipping 3.4.8rc1 because I prefer to do both releases at once.
>
> I'm hoping this problem will be resolved quickly; if we only slip the RCs
> by a day or two I won't slip the final releases (in about two weeks).
>
>
> PLS SND HALP,
>
>
> */arry*
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%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

Re: [Python-Dev] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

[Stéfane Fermigier]

On Mon, Jan 22, 2018 at 11:33 AM, Larry Hastings  wrote:

>
>
> I have three PRs for Python 3.5.5rc1:
>
> https://github.com/python/cpython/pull/4656
> https://github.com/python/cpython/pull/5197
> https://github.com/python/cpython/pull/5201
>
> I can't merge them because Travis CI is unhappy.  All three CI tests fail
> in the same way, reporting this error:
>
> The command "pyenv global system 3.5" failed and exited with 1 during .
>
>
This seems to be related to
https://github.com/travis-ci/travis-ci/issues/8363

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
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] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

[Joni Orponen]

On Mon, Jan 22, 2018 at 11:59 AM, Oleg Broytman  wrote:

> On Mon, Jan 22, 2018 at 02:33:01AM -0800, Larry Hastings <
> la...@hastings.org> wrote:
> > All ... CI tests fail in
> > the same way, reporting this error:
> >
> >The command "pyenv global system 3.5" failed and exited with 1 during
> .
>
>Seems there is a slow workaround (install python 3.5):
>
> https://github.com/travis-ci/travis-ci/issues/8363#issuecomment-354857845
>
> which python3.5 || (pyenv install 3.5.4 && pyenv use system 3.5.4)
>

There is also https://github.com/praekeltfoundation/travis-pyenv I've found
useful when one needs excactness and also to decouple oneself from the
Travis side rolling releases of Python. Also caches the Python version for
you.

See
https://github.com/plone/plone.intelligenttext/blob/a71bdc5b485b1562b2e320f5c41a15286f205f98/.travis.yml
for a usage example.

-- 
Joni Orponen
___
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] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

[Oleg Broytman]

On Mon, Jan 22, 2018 at 02:33:01AM -0800, Larry Hastings  
wrote:
> All ... CI tests fail in
> the same way, reporting this error:
> 
>The command "pyenv global system 3.5" failed and exited with 1 during .

   Seems there is a slow workaround (install python 3.5):

https://github.com/travis-ci/travis-ci/issues/8363#issuecomment-354857845

which python3.5 || (pyenv install 3.5.4 && pyenv use system 3.5.4)

> //arry/

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

[Victor Stinner]

I created an issue with more information:
https://bugs.python.org/issue32620

Victor

2018-01-22 11:33 GMT+01:00 Larry Hastings :
>
>
> I have three PRs for Python 3.5.5rc1:
>
> https://github.com/python/cpython/pull/4656
> https://github.com/python/cpython/pull/5197
> https://github.com/python/cpython/pull/5201
>
> I can't merge them because Travis CI is unhappy.  All three CI tests fail in
> the same way, reporting this error:
>
> The command "pyenv global system 3.5" failed and exited with 1 during .
>
> Since Travis CI is a "required check", Github won't let me merge the PR.
> Yes I could manually merge the patches by hand but I'm hoping it doesn't
> come to that.
>
> I'm slipping 3.4.8rc1 because I prefer to do both releases at once.
>
> I'm hoping this problem will be resolved quickly; if we only slip the RCs by
> a day or two I won't slip the final releases (in about two weeks).
>
>
> PLS SND HALP,
>
>
> /arry
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.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

[Python-Dev] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

[Larry Hastings]

I have three PRs for Python 3.5.5rc1:

   https://github.com/python/cpython/pull/4656
   https://github.com/python/cpython/pull/5197
   https://github.com/python/cpython/pull/5201

I can't merge them because Travis CI is unhappy.  All three CI tests 
fail in the same way, reporting this error:


   The command "pyenv global system 3.5" failed and exited with 1 during .

Since Travis CI is a "required check", Github won't let me merge the 
PR.  Yes I could manually merge the patches by hand but I'm hoping it 
doesn't come to that.


I'm slipping 3.4.8rc1 because I prefer to do both releases at once.

I'm hoping this problem will be resolved quickly; if we only slip the 
RCs by a day or two I won't slip the final releases (in about two weeks).



PLS SND HALP,


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com