From ncoghlan at gmail.com  Tue Sep  1 00:23:27 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 1 Sep 2015 08:23:27 +1000
Subject: [Python-Dev] PEP 498: Literal String Interpolation
In-Reply-To: <55E4C837.40103@trueblade.com>
References: <55E3080F.9030601@trueblade.com>
 <CADiSq7dXdfsoa-r_UCMN30MMXN4Dthu7mfG5OMNb2oPtFA-GWA@mail.gmail.com>
 <55E4B459.9030000@gmail.com> <55E4C226.9020205@trueblade.com>
 <55E4C837.40103@trueblade.com>
Message-ID: <CADiSq7dD0Z0mKR_j+3RAZ6B=LQfS6J8K7w5E+cFuaUgk9A+sPw@mail.gmail.com>

On 1 Sep 2015 07:35, "Eric V. Smith" <eric at trueblade.com> wrote:
>
> But back to PEP 498: I can't imagine accepting either PEP 501 or 502
> without also accepting PEP 498. And once you've accepted 498, are i- or
> e-strings sufficiently powerful and useful enough, and are they likely
> to be used in the correct way? I think that's the question.

Exactly, 498 should now be considered independently, with 501 & 502 as
potential answers to questions like:

* how can we mitigate the increased risk of code injection vulnerabilities
that comes with native interpolation support?
* how can we handle cases where delaying interpolation would be helpful,
like event logging or i18n?
* how can we support adaptation of the interpolation syntax to cases like
SQL Alchemy's "text" API, which consumes an SQL expression in text form and
converts it to SQL Alchemy objects?

Writing 501 has satisfied me that those questions *can* be addressed, *if*
we decide they should be, and that it can be done in such a way that it can
be presented to folks learning Python in the future as an implementation
detail of the native string formatting support (that is, folks would be
taught formatted strings early, and only later be taught that you can use
an interpolation template to split up the template interpolation and
template rendering steps.

That all adds up to thinking it's fine to defer answering those questions
to later, rather than expecting 498 to address them immediately. We have
plenty of time until 3.6 rolls around :)

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150901/d0e4b700/attachment.html>

From oscar.j.benjamin at gmail.com  Tue Sep  1 16:47:19 2015
From: oscar.j.benjamin at gmail.com (Oscar Benjamin)
Date: Tue, 1 Sep 2015 15:47:19 +0100
Subject: [Python-Dev] Building Extensions for Python 3.5 on Windows
In-Reply-To: <55DDE5CF.7030604@python.org>
References: <55DCB147.9020604@python.org> <mrjgo3$frn$1@ger.gmane.org>
 <55DDE5CF.7030604@python.org>
Message-ID: <CAHVvXxRnz7L0_9Uvvx5_h-h0-XeDdcEbodi3_Hkmduag8DoFYQ@mail.gmail.com>

On 26 August 2015 at 17:14, Steve Dower <steve.dower at python.org> wrote:
>> On 8/25/2015 2:17 PM, Steve Dower wrote:
>>>
>>> I've written up a long technical blog post about the compiler and CRT
>>> changes in Python 3.5, which will be of interest to those who build and
>>> distribute native extensions for Windows.
>>>
>>> http://stevedower.id.au/blog/building-for-python-3-5/
>>>
>
> * MinGW walkthrough for building extensions via distutils or directly (I'll
> need some help with this one)

Thanks for the detailed writeup Steve. Do you know how these changes
to the python.org Windows binaries would impact on people building
extension modules with MinGW?

I think that some extension module authors use MinGW for their Windows
binaries because then a single compiler installation can compile for
multiple Python versions and link against whichever msvcrtXX.dll is
needed. For example in the numpy release notes [1]:
"The MinGW compilers used to build the official Numpy binary
installers for 32-bit Python on Windows can be found in
https://github.com/numpy/numpy-vendor."

Perhaps it would be good to verify that the numpy MinGW build
instructions still work?

[1] https://github.com/numpy/numpy/blob/master/INSTALL.txt#L118

--
Oscar

From steve.dower at python.org  Tue Sep  1 18:15:56 2015
From: steve.dower at python.org (Steve Dower)
Date: Tue, 1 Sep 2015 09:15:56 -0700
Subject: [Python-Dev] Building Extensions for Python 3.5 on Windows
In-Reply-To: <CAHVvXxRnz7L0_9Uvvx5_h-h0-XeDdcEbodi3_Hkmduag8DoFYQ@mail.gmail.com>
References: <55DCB147.9020604@python.org> <mrjgo3$frn$1@ger.gmane.org>
 <55DDE5CF.7030604@python.org>
 <CAHVvXxRnz7L0_9Uvvx5_h-h0-XeDdcEbodi3_Hkmduag8DoFYQ@mail.gmail.com>
Message-ID: <55E5CF3C.5000406@python.org>

On 01Sep2015 0747, Oscar Benjamin wrote:
> Thanks for the detailed writeup Steve. Do you know how these changes
> to the python.org Windows binaries would impact on people building
> extension modules with MinGW?

Currently, no version of MinGW AFAIK will link against the UCRT, so 
they'll suffer from the same mixed-CRT issues as with any other 
arrangement. There is some work going towards making mingw-w64 work with 
UCRT, but I am not following it closely despite occasional contact with 
the dev(s) working on it.

> I think that some extension module authors use MinGW for their Windows
> binaries because then a single compiler installation can compile for
> multiple Python versions and link against whichever msvcrtXX.dll is
> needed. For example in the numpy release notes [1]:
> "The MinGW compilers used to build the official Numpy binary
> installers for 32-bit Python on Windows can be found in
> https://github.com/numpy/numpy-vendor."
>
> Perhaps it would be good to verify that the numpy MinGW build
> instructions still work?

I'd love it for someone to do that. My MinGW skills are so poor though 
that all I'd be verifying is whether I messed up or not :). Certainly 
most of numpy builds fine with MSVC - it's just the optimized Fortran 
pieces that require either Intel's compiler (to link against MSVC) or a 
complete switch to gcc.

Cheers,
Steve

> [1] https://github.com/numpy/numpy/blob/master/INSTALL.txt#L118
>
> --
> Oscar
>


From p.f.moore at gmail.com  Wed Sep  2 12:16:30 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 2 Sep 2015 11:16:30 +0100
Subject: [Python-Dev] Building Extensions for Python 3.5 on Windows
In-Reply-To: <55E5CF3C.5000406@python.org>
References: <55DCB147.9020604@python.org> <mrjgo3$frn$1@ger.gmane.org>
 <55DDE5CF.7030604@python.org>
 <CAHVvXxRnz7L0_9Uvvx5_h-h0-XeDdcEbodi3_Hkmduag8DoFYQ@mail.gmail.com>
 <55E5CF3C.5000406@python.org>
Message-ID: <CACac1F8XZ+ZoCcmQfYcEtZxMhJEDhd=4fdoOSeQA+xyNztqJcw@mail.gmail.com>

On 1 September 2015 at 17:15, Steve Dower <steve.dower at python.org> wrote:
> On 01Sep2015 0747, Oscar Benjamin wrote:
>>
>> Thanks for the detailed writeup Steve. Do you know how these changes
>> to the python.org Windows binaries would impact on people building
>> extension modules with MinGW?
>
>
> Currently, no version of MinGW AFAIK will link against the UCRT, so they'll
> suffer from the same mixed-CRT issues as with any other arrangement. There
> is some work going towards making mingw-w64 work with UCRT, but I am not
> following it closely despite occasional contact with the dev(s) working on
> it.

One thing that I hit when trying to build vim with VS2015 is that it
appears that even compiled object code isn't linkable with the ucrt. I
don't know the correct terminology here, so let me explain in a bit
more detail (I'm doing this from memory, so some symbol names might be
wrong, but you'll get the idea, I hope).

If source code refers to FILE* objects, then previously the compiled
object file (compiled with mingw) would be linkable with any of the
various C runtimes (msvcrt, msvcr10, etc). The object referred to a
symbol __iob_base which is present in all the CRTs. If the actual code
using the library doesn't actually use any of the functions that refer
to stdio, then whether the actual use of that symbol is broken doesn't
(seem to) matter in practice.

That's likely to be luck, to a certain extent - there's no guarantee
that the internals of the FILE* abstraction are compatible between
CRTs, but it has been true thus far, and so use of object libraries
built with mingw are typically OK, as long as you avoid using things
that need the CRT types like FILE*.

But with VS 2015 and the ucrt, there is no __iob_base symbol, and so
linking to code that refers to stdio fails.

The consequence of this (I believe) is that not only does mingw need
to be able to link against the ucrt, but it also needs to *compile*
with ucrt-compatible headers. In particular, when compiling for the
ucrt, mingw needs to use a version of <stdio.h> that doesn't reference
__iob_base. As the mingw developers maintain their own headers by some
process of "clean room" reimplementation (to satisfy the needs of the
GPL, as I understand it) updating the headers to cater for the ucrt
could be a non-trivial issue for them. I have no idea what their plans
are in this regard.

The other side of this is that it means that all object libraries you
use need to be recompiled to target ucrt, you can't simply use
existing compiled libraries and relink.

I hope this makes sense, and my interpretation is accurate - if I've
misunderstood the implications of the switch to the ucrt, then please
let me know. And if I'm wrong about not being able to use existing
compiled libraries, I would definitely appreciate someone telling me
what I'm doing wrong, because at the moment I'm unable to build my own
copy of vim with VS 2015 because I can't rebuild the xpm library :-(

Paul

PS My ultimate goal with building Vim with VS 2015 is to create a
build that uses the new embeddable distribution of Python 3.5 to
create a self-contained copy of Vim with Python 3.5 support enabled.
Something I think would be awesome :-)

From p.f.moore at gmail.com  Wed Sep  2 14:38:37 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 2 Sep 2015 13:38:37 +0100
Subject: [Python-Dev] Building Extensions for Python 3.5 on Windows
In-Reply-To: <CAGGsPMx8pW6zMudnQpnD4Tthwgna5ahFx606r8u-+TZVqYwVDA@mail.gmail.com>
References: <55DCB147.9020604@python.org> <mrjgo3$frn$1@ger.gmane.org>
 <55DDE5CF.7030604@python.org>
 <CAHVvXxRnz7L0_9Uvvx5_h-h0-XeDdcEbodi3_Hkmduag8DoFYQ@mail.gmail.com>
 <55E5CF3C.5000406@python.org>
 <CACac1F8XZ+ZoCcmQfYcEtZxMhJEDhd=4fdoOSeQA+xyNztqJcw@mail.gmail.com>
 <CAGGsPMx8pW6zMudnQpnD4Tthwgna5ahFx606r8u-+TZVqYwVDA@mail.gmail.com>
Message-ID: <CACac1F8MOmW43LhyHEbxrfmRorft34pNc=KZzd7icLsnX1RWAQ@mail.gmail.com>

On 2 September 2015 at 13:01, Carl Kleffner <cmkleffner at gmail.com> wrote:
> that is https://bugs.python.org/msg248716 see also
> http://rt.openssl.org/Ticket/Display.html?id=3390&user=guest&pass=guest

Interesting. But it does confirm that object files have to be rebuilt,
and there's no way to use existing object files. So if your source
only builds with mingw, it needs mingw's headers updating before you
can do that rebuild.

FWIW, in the case I hit with xpm, the xpm library only uses FILE*
internally - the external APIs are purely in terms of filenames. And
it only uses FILE* via the standard C APIs for it. So it's not a
simple case of "avoid using CRT types in external APIs".

So unless I'm misunderstanding, *any* object code used in a project
(whether directly or from a 3rd party library) has to be build using a
compiler that supports the ucrt (which, given that mingw doesn't have
that support yet, means VS 2015 only).

Note: I understand why the move to the ucrt is good, and I view this
as very much a short term transitional issue, but it is real and I
think it's important people understand the implications.

Paul

From cmkleffner at gmail.com  Wed Sep  2 14:01:48 2015
From: cmkleffner at gmail.com (Carl Kleffner)
Date: Wed, 2 Sep 2015 14:01:48 +0200
Subject: [Python-Dev] Building Extensions for Python 3.5 on Windows
In-Reply-To: <CACac1F8XZ+ZoCcmQfYcEtZxMhJEDhd=4fdoOSeQA+xyNztqJcw@mail.gmail.com>
References: <55DCB147.9020604@python.org> <mrjgo3$frn$1@ger.gmane.org>
 <55DDE5CF.7030604@python.org>
 <CAHVvXxRnz7L0_9Uvvx5_h-h0-XeDdcEbodi3_Hkmduag8DoFYQ@mail.gmail.com>
 <55E5CF3C.5000406@python.org>
 <CACac1F8XZ+ZoCcmQfYcEtZxMhJEDhd=4fdoOSeQA+xyNztqJcw@mail.gmail.com>
Message-ID: <CAGGsPMx8pW6zMudnQpnD4Tthwgna5ahFx606r8u-+TZVqYwVDA@mail.gmail.com>

Hi,

that is https://bugs.python.org/msg248716 see also
http://rt.openssl.org/Ticket/Display.html?id=3390&user=guest&pass=guest

Steve: is there more of that in the new universal runtimes?

Carl

2015-09-02 12:16 GMT+02:00 Paul Moore <p.f.moore at gmail.com>:

> On 1 September 2015 at 17:15, Steve Dower <steve.dower at python.org> wrote:
> > On 01Sep2015 0747, Oscar Benjamin wrote:
> >>
> >> Thanks for the detailed writeup Steve. Do you know how these changes
> >> to the python.org Windows binaries would impact on people building
> >> extension modules with MinGW?
> >
> >
> > Currently, no version of MinGW AFAIK will link against the UCRT, so
> they'll
> > suffer from the same mixed-CRT issues as with any other arrangement.
> There
> > is some work going towards making mingw-w64 work with UCRT, but I am not
> > following it closely despite occasional contact with the dev(s) working
> on
> > it.
>
> One thing that I hit when trying to build vim with VS2015 is that it
> appears that even compiled object code isn't linkable with the ucrt. I
> don't know the correct terminology here, so let me explain in a bit
> more detail (I'm doing this from memory, so some symbol names might be
> wrong, but you'll get the idea, I hope).
>
> If source code refers to FILE* objects, then previously the compiled
> object file (compiled with mingw) would be linkable with any of the
> various C runtimes (msvcrt, msvcr10, etc). The object referred to a
> symbol __iob_base which is present in all the CRTs. If the actual code
> using the library doesn't actually use any of the functions that refer
> to stdio, then whether the actual use of that symbol is broken doesn't
> (seem to) matter in practice.
>
> That's likely to be luck, to a certain extent - there's no guarantee
> that the internals of the FILE* abstraction are compatible between
> CRTs, but it has been true thus far, and so use of object libraries
> built with mingw are typically OK, as long as you avoid using things
> that need the CRT types like FILE*.
>
> But with VS 2015 and the ucrt, there is no __iob_base symbol, and so
> linking to code that refers to stdio fails.
>
> The consequence of this (I believe) is that not only does mingw need
> to be able to link against the ucrt, but it also needs to *compile*
> with ucrt-compatible headers. In particular, when compiling for the
> ucrt, mingw needs to use a version of <stdio.h> that doesn't reference
> __iob_base. As the mingw developers maintain their own headers by some
> process of "clean room" reimplementation (to satisfy the needs of the
> GPL, as I understand it) updating the headers to cater for the ucrt
> could be a non-trivial issue for them. I have no idea what their plans
> are in this regard.
>
> The other side of this is that it means that all object libraries you
> use need to be recompiled to target ucrt, you can't simply use
> existing compiled libraries and relink.
>
> I hope this makes sense, and my interpretation is accurate - if I've
> misunderstood the implications of the switch to the ucrt, then please
> let me know. And if I'm wrong about not being able to use existing
> compiled libraries, I would definitely appreciate someone telling me
> what I'm doing wrong, because at the moment I'm unable to build my own
> copy of vim with VS 2015 because I can't rebuild the xpm library :-(
>
> Paul
>
> PS My ultimate goal with building Vim with VS 2015 is to create a
> build that uses the new embeddable distribution of Python 3.5 to
> create a self-contained copy of Vim with Python 3.5 support enabled.
> Something I think would be awesome :-)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150902/f81fc7ac/attachment.html>

From cmkleffner at gmail.com  Wed Sep  2 14:51:37 2015
From: cmkleffner at gmail.com (Carl Kleffner)
Date: Wed, 2 Sep 2015 14:51:37 +0200
Subject: [Python-Dev] Building Extensions for Python 3.5 on Windows
In-Reply-To: <CACac1F8MOmW43LhyHEbxrfmRorft34pNc=KZzd7icLsnX1RWAQ@mail.gmail.com>
References: <55DCB147.9020604@python.org> <mrjgo3$frn$1@ger.gmane.org>
 <55DDE5CF.7030604@python.org>
 <CAHVvXxRnz7L0_9Uvvx5_h-h0-XeDdcEbodi3_Hkmduag8DoFYQ@mail.gmail.com>
 <55E5CF3C.5000406@python.org>
 <CACac1F8XZ+ZoCcmQfYcEtZxMhJEDhd=4fdoOSeQA+xyNztqJcw@mail.gmail.com>
 <CAGGsPMx8pW6zMudnQpnD4Tthwgna5ahFx606r8u-+TZVqYwVDA@mail.gmail.com>
 <CACac1F8MOmW43LhyHEbxrfmRorft34pNc=KZzd7icLsnX1RWAQ@mail.gmail.com>
Message-ID: <CAGGsPMyKW2JHcYj5My__DEgPUqim8Cb3t_TuXdw7Cku_Ki0ZSQ@mail.gmail.com>

There are more semantic surprises as well. Some Math functions like powf,
acosf and so on are available only with the help of the VS 2015 math.h
include file (32 bit case). With exporting symbols names from the universal
dll's and creating import libraries you are not done yet.

Carl

2015-09-02 14:38 GMT+02:00 Paul Moore <p.f.moore at gmail.com>:

> On 2 September 2015 at 13:01, Carl Kleffner <cmkleffner at gmail.com> wrote:
> > that is https://bugs.python.org/msg248716 see also
> > http://rt.openssl.org/Ticket/Display.html?id=3390&user=guest&pass=guest
>
> Interesting. But it does confirm that object files have to be rebuilt,
> and there's no way to use existing object files. So if your source
> only builds with mingw, it needs mingw's headers updating before you
> can do that rebuild.
>
> FWIW, in the case I hit with xpm, the xpm library only uses FILE*
> internally - the external APIs are purely in terms of filenames. And
> it only uses FILE* via the standard C APIs for it. So it's not a
> simple case of "avoid using CRT types in external APIs".
>
> So unless I'm misunderstanding, *any* object code used in a project
> (whether directly or from a 3rd party library) has to be build using a
> compiler that supports the ucrt (which, given that mingw doesn't have
> that support yet, means VS 2015 only).
>
> Note: I understand why the move to the ucrt is good, and I view this
> as very much a short term transitional issue, but it is real and I
> think it's important people understand the implications.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150902/26d500f7/attachment.html>

From steve.dower at python.org  Wed Sep  2 15:07:41 2015
From: steve.dower at python.org (Steve Dower)
Date: Wed, 2 Sep 2015 06:07:41 -0700
Subject: [Python-Dev] Building Extensions for Python 3.5 on Windows
In-Reply-To: <CACac1F8MOmW43LhyHEbxrfmRorft34pNc=KZzd7icLsnX1RWAQ@mail.gmail.com>
References: <55DCB147.9020604@python.org>	<mrjgo3$frn$1@ger.gmane.org>
 <55DDE5CF.7030604@python.org>
 <CAHVvXxRnz7L0_9Uvvx5_h-h0-XeDdcEbodi3_Hkmduag8DoFYQ@mail.gmail.com>
 <55E5CF3C.5000406@python.org>
 <CACac1F8XZ+ZoCcmQfYcEtZxMhJEDhd=4fdoOSeQA+xyNztqJcw@mail.gmail.com>
 <CAGGsPMx8pW6zMudnQpnD4Tthwgna5ahFx606r8u-+TZVqYwVDA@mail.gmail.com>
 <CACac1F8MOmW43LhyHEbxrfmRorft34pNc=KZzd7icLsnX1RWAQ@mail.gmail.com>
Message-ID: <E1ZX7lQ-0006S0-09@se2-syd.hostedmail.net.au>

You can also build existing object or static libraries into their own DLL with the old compiler and dynamically link to them. It's not perfect, but it's no worse than trying to link them in directly.

Otherwise, your analysis is correct. The OpenSSL issue was because they directly referred to __iob_func in their own code. It submitted a patch for it months ago and they fixed it, but possibly only in 1.0.2.

Cheers,
Steve

Top-posted from my Windows Phone

-----Original Message-----
From: "Paul Moore" <p.f.moore at gmail.com>
Sent: ?9/?2/?2015 5:38
To: "Carl Kleffner" <cmkleffner at gmail.com>
Cc: "Steve Dower" <steve.dower at python.org>; "Python Dev" <python-dev at python.org>
Subject: Re: [Python-Dev] Building Extensions for Python 3.5 on Windows

On 2 September 2015 at 13:01, Carl Kleffner <cmkleffner at gmail.com> wrote:
> that is https://bugs.python.org/msg248716 see also
> http://rt.openssl.org/Ticket/Display.html?id=3390&user=guest&pass=guest

Interesting. But it does confirm that object files have to be rebuilt,
and there's no way to use existing object files. So if your source
only builds with mingw, it needs mingw's headers updating before you
can do that rebuild.

FWIW, in the case I hit with xpm, the xpm library only uses FILE*
internally - the external APIs are purely in terms of filenames. And
it only uses FILE* via the standard C APIs for it. So it's not a
simple case of "avoid using CRT types in external APIs".

So unless I'm misunderstanding, *any* object code used in a project
(whether directly or from a 3rd party library) has to be build using a
compiler that supports the ucrt (which, given that mingw doesn't have
that support yet, means VS 2015 only).

Note: I understand why the move to the ucrt is good, and I view this
as very much a short term transitional issue, but it is real and I
think it's important people understand the implications.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150902/770d2542/attachment.html>

From anniina.kottila at personaseo.org  Wed Sep  2 09:54:29 2015
From: anniina.kottila at personaseo.org (Anniina Kottila)
Date: Wed, 2 Sep 2015 07:54:29 +0000
Subject: [Python-Dev] =?utf-8?b?dHnDtnNrZW5uZWxsw6TDpG4geWhkZXNzw6Q=?=
Message-ID: <3n5dRF14RbzNL5@mail.python.org>

Hei,

Nimeni on Anniina Kottila ja haluaisin kertoa miten bugs.python.org
voi sijoittua viel&auml; paremmin Googlessa.

Olen hakukoneoptimoinnin asiantuntija ja ty&ouml;skentelen Finland SEO &ndash;yrityksess&auml;.
Tehdess&auml;ni tutkimusta er&auml;ille kollegoilleni, l&ouml;ysin s&auml;hk&ouml;postiosoitteesi
ja p&auml;&auml;tin ottaa yhteytt&auml; v&auml;litt&ouml;m&auml;sti.

Jos olet kiinnostunut, l&auml;hett&auml;isin mielell&auml;ni lis&auml;tietoa ja yksityiskohtia
yhteisty&ouml;n toteuttamisesta.

Kiitt&auml;en,

Anniina Kottila
http://finlandseo.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150902/04e3b81f/attachment.html>

From p.f.moore at gmail.com  Wed Sep  2 17:03:07 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 2 Sep 2015 16:03:07 +0100
Subject: [Python-Dev] Building Extensions for Python 3.5 on Windows
In-Reply-To: <E1ZX7lQ-0006S0-09@se2-syd.hostedmail.net.au>
References: <55DCB147.9020604@python.org> <mrjgo3$frn$1@ger.gmane.org>
 <55DDE5CF.7030604@python.org>
 <CAHVvXxRnz7L0_9Uvvx5_h-h0-XeDdcEbodi3_Hkmduag8DoFYQ@mail.gmail.com>
 <55E5CF3C.5000406@python.org>
 <CACac1F8XZ+ZoCcmQfYcEtZxMhJEDhd=4fdoOSeQA+xyNztqJcw@mail.gmail.com>
 <CAGGsPMx8pW6zMudnQpnD4Tthwgna5ahFx606r8u-+TZVqYwVDA@mail.gmail.com>
 <CACac1F8MOmW43LhyHEbxrfmRorft34pNc=KZzd7icLsnX1RWAQ@mail.gmail.com>
 <E1ZX7lQ-0006S0-09@se2-syd.hostedmail.net.au>
Message-ID: <CACac1F_ZoMmzT+zRrSgM5AYHpZu-oEvnKgd-k1osqRkizu=Kbg@mail.gmail.com>

On 2 September 2015 at 14:07, Steve Dower <steve.dower at python.org> wrote:
> You can also build existing object or static libraries into their own DLL
> with the old compiler and dynamically link to them. It's not perfect, but
> it's no worse than trying to link them in directly.

Interesting approach. "gcc -shared -o xpm.dll xpm.a" does about what I
want. Some thoughts:

1. This dynamically links to msvcrt.dll. Is that OK? I guess the
answer is "it's no worse than using such a DLL with Python 3.4 would
be" :-)
2. I presumably need an import lib. I can get gcc to generate a .a
format one, I'll need to see if VC 2015 can handle those, or if
there's a way to convert them (I'm sure there is, but it's been a long
time since I had to do that...)

Anyway, thanks for the response.

Just one further question if I may - on going the other way. Is it
acceptable to embed Python 3.5 (via fully runtime
LoadLibrary/GetProcAddress calls to load python35.dll) in an
application that uses an older CRT? My initial instinct is that it
probably isn't, but I can't think it through - my head's definitely
hurting by now :-)

Paul

From steve.dower at python.org  Wed Sep  2 20:42:01 2015
From: steve.dower at python.org (Steve Dower)
Date: Wed, 2 Sep 2015 11:42:01 -0700
Subject: [Python-Dev] Building Extensions for Python 3.5 on Windows
In-Reply-To: <CACac1F_ZoMmzT+zRrSgM5AYHpZu-oEvnKgd-k1osqRkizu=Kbg@mail.gmail.com>
References: <55DCB147.9020604@python.org> <mrjgo3$frn$1@ger.gmane.org>
 <55DDE5CF.7030604@python.org>
 <CAHVvXxRnz7L0_9Uvvx5_h-h0-XeDdcEbodi3_Hkmduag8DoFYQ@mail.gmail.com>
 <55E5CF3C.5000406@python.org>
 <CACac1F8XZ+ZoCcmQfYcEtZxMhJEDhd=4fdoOSeQA+xyNztqJcw@mail.gmail.com>
 <CAGGsPMx8pW6zMudnQpnD4Tthwgna5ahFx606r8u-+TZVqYwVDA@mail.gmail.com>
 <CACac1F8MOmW43LhyHEbxrfmRorft34pNc=KZzd7icLsnX1RWAQ@mail.gmail.com>
 <E1ZX7lQ-0006S0-09@se2-syd.hostedmail.net.au>
 <CACac1F_ZoMmzT+zRrSgM5AYHpZu-oEvnKgd-k1osqRkizu=Kbg@mail.gmail.com>
Message-ID: <55E742F9.8060505@python.org>

On 02Sep2015 0803, Paul Moore wrote:
> On 2 September 2015 at 14:07, Steve Dower <steve.dower at python.org> wrote:
>> You can also build existing object or static libraries into their own DLL
>> with the old compiler and dynamically link to them. It's not perfect, but
>> it's no worse than trying to link them in directly.
>
> Interesting approach. "gcc -shared -o xpm.dll xpm.a" does about what I
> want. Some thoughts:
>
> 1. This dynamically links to msvcrt.dll. Is that OK? I guess the
> answer is "it's no worse than using such a DLL with Python 3.4 would
> be" :-)

Yeah, "no worse" is the answer here.

> 2. I presumably need an import lib. I can get gcc to generate a .a
> format one, I'll need to see if VC 2015 can handle those, or if
> there's a way to convert them (I'm sure there is, but it's been a long
> time since I had to do that...)

I'm fairly sure there's a dumpbin.exe/lib.exe dance you can do, but it's 
been a long time since I've had to do it too.

> Anyway, thanks for the response.
>
> Just one further question if I may - on going the other way. Is it
> acceptable to embed Python 3.5 (via fully runtime
> LoadLibrary/GetProcAddress calls to load python35.dll) in an
> application that uses an older CRT? My initial instinct is that it
> probably isn't, but I can't think it through - my head's definitely
> hurting by now :-)

The answer is "yes, but", where the but depends on what you're sharing 
between the application and Python. As long as you're careful to let 
Python do its memory management and the app do its own and their paths 
never cross, you'll probably be okay.

Cheers,
Steve

> Paul
>


From Linda.Ryan at tenstep.com  Wed Sep  2 22:57:12 2015
From: Linda.Ryan at tenstep.com (Linda Ryan)
Date: Wed, 2 Sep 2015 20:57:12 +0000
Subject: [Python-Dev] python programmer
Message-ID: <D6FE6B06E0E62B498C7A30A1D72C429014B018@mbx026-w1-ca-4.exch026.domain.local>

Dear Admin,

I am an IT/Project Management recruiter looking to increase the available pool of talent for available job placements.
Currently I have an opening for a python programmer/developer.  Could I post opportunities to your member list?

Thank you,

Linda Ryan
Business Development Manager
770-313-2739 cell

TenStep Inc
www.TenStep.com<http://www.TenStep.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150902/f0a47d6f/attachment.html>

From mark at hotpy.org  Wed Sep  2 23:53:47 2015
From: mark at hotpy.org (Mark Shannon)
Date: Wed, 02 Sep 2015 22:53:47 +0100
Subject: [Python-Dev] python programmer
In-Reply-To: <D6FE6B06E0E62B498C7A30A1D72C429014B018@mbx026-w1-ca-4.exch026.domain.local>
References: <D6FE6B06E0E62B498C7A30A1D72C429014B018@mbx026-w1-ca-4.exch026.domain.local>
Message-ID: <55E76FEB.7010607@hotpy.org>

In a word, No.
Try https://www.python.org/jobs/

On 02/09/15 21:57, Linda Ryan wrote:
> Dear Admin,
>
> I am an IT/Project Management recruiter looking to increase the
> available pool of talent for available job placements.
> Currently I have an opening for a python programmer/developer.  Could I
> post opportunities to your member list?
>
> Thank you,
>
> Linda Ryan
> Business Development Manager
> 770-313-2739 cell
>
> TenStep Inc
> www.TenStep.com <http://www.TenStep.com>
>
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/mark%40hotpy.org
>

From ethan at stoneleaf.us  Wed Sep  2 23:59:15 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 02 Sep 2015 14:59:15 -0700
Subject: [Python-Dev] python programmer
In-Reply-To: <55E76FEB.7010607@hotpy.org>
References: <D6FE6B06E0E62B498C7A30A1D72C429014B018@mbx026-w1-ca-4.exch026.domain.local>
 <55E76FEB.7010607@hotpy.org>
Message-ID: <55E77133.7020206@stoneleaf.us>

On 09/02/2015 02:53 PM, Mark Shannon wrote:
> On 02/09/15 21:57, Linda Ryan wrote:
>>
>> Could I post opportunities to your member list?
>
> In a word, No.
> Try https://www.python.org/jobs/

But thank you for asking first.  :)  Good luck!

--
~Ethan~

From rosuav at gmail.com  Wed Sep  2 23:54:54 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 3 Sep 2015 07:54:54 +1000
Subject: [Python-Dev] python programmer
In-Reply-To: <D6FE6B06E0E62B498C7A30A1D72C429014B018@mbx026-w1-ca-4.exch026.domain.local>
References: <D6FE6B06E0E62B498C7A30A1D72C429014B018@mbx026-w1-ca-4.exch026.domain.local>
Message-ID: <CAPTjJmpNeDdf3Z+biAwKCseuH0g36GkECYQ3-spEuAN6yfmaDA@mail.gmail.com>

On Thu, Sep 3, 2015 at 6:57 AM, Linda Ryan <Linda.Ryan at tenstep.com> wrote:
> I am an IT/Project Management recruiter looking to increase the available
> pool of talent for available job placements.
> Currently I have an opening for a python programmer/developer.  Could I post
> opportunities to your member list?

Hi! Not to this list, as such, but there is a job board that accepts
such postings:

https://www.python.org/jobs/

People around the world read that board (myself included), so if
you're willing to work with telecommuters, your pool of talent can be
pretty broad!

ChrisA

From yselivanov.ml at gmail.com  Thu Sep  3 04:03:50 2015
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Wed, 2 Sep 2015 22:03:50 -0400
Subject: [Python-Dev] What's New editing
In-Reply-To: <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
Message-ID: <55E7AA86.7020504@gmail.com>



On 2015-07-06 11:38 AM, David Mertz wrote:
> Hi Folks,
>
> I hereby volunteer to write "What's New for Python 3.5?" if folks on 
> python-dev are fine with me taking the job (i.e. I ran it by Travis, 
> my boss at Continuum, and he's happy to allow me to do that work 
> within my salaried hours... so having time isn't a problem).
>
> If this is OK with the powers-that-be, I'll coordinate with David 
> Murray on how best to take over this task from him.

Hi David,

Are you still going to work on what's new for 3.5?

Yury


From stefan_ml at behnel.de  Thu Sep  3 08:32:06 2015
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 03 Sep 2015 08:32:06 +0200
Subject: [Python-Dev] python programmer
In-Reply-To: <CAPTjJmpNeDdf3Z+biAwKCseuH0g36GkECYQ3-spEuAN6yfmaDA@mail.gmail.com>
References: <D6FE6B06E0E62B498C7A30A1D72C429014B018@mbx026-w1-ca-4.exch026.domain.local>
 <CAPTjJmpNeDdf3Z+biAwKCseuH0g36GkECYQ3-spEuAN6yfmaDA@mail.gmail.com>
Message-ID: <ms8ph6$un0$1@ger.gmane.org>

Chris Angelico schrieb am 02.09.2015 um 23:54:
> On Thu, Sep 3, 2015 at 6:57 AM, Linda Ryan wrote:
>> I am an IT/Project Management recruiter looking to increase the available
>> pool of talent for available job placements.
>> Currently I have an opening for a python programmer/developer.  Could I post
>> opportunities to your member list?
> 
> Hi! Not to this list, as such, but there is a job board that accepts
> such postings:
> 
> https://www.python.org/jobs/
> 
> People around the world read that board (myself included), so if
> you're willing to work with telecommuters, your pool of talent can be
> pretty broad!

And if not, then your target audience might still read it there. However,
depending on where your position is, you might also be able to find a more
local or at least national job board, or a local Python User Group that
might be able to tell you where best to publish job offers for your target
group. Searching for "Python User Group" and your (closest bigger) city
name might reveal something there.

Good luck!

Stefan



From victor.stinner at gmail.com  Thu Sep  3 12:31:42 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 3 Sep 2015 12:31:42 +0200
Subject: [Python-Dev] Is hg.python.org out of memory?
Message-ID: <CAMpsgwbD7V+-fJafgNqywEMpQEFUOugs6KAEN=SryTV3GRs-sw@mail.gmail.com>

Hi,

I got HTTP 503 errors when trying to access http://hg.python.org/ and
I got errors when trying to push changes with "hg push" (to
ssh://hg at hg.python.org/cpython).

I even got this error from "hg push":
--
remote: abort: /srv/hg/lib/python/mercurial/mpatch.so: failed to map
segment from shared object: Cannot allocate memory!
--

Is someone available to check what happened on hg.python.org?
Buildbots slowly become red because hg.python.org is no more
avaialble.

Victor

From tisdall at gmail.com  Thu Sep  3 16:18:46 2015
From: tisdall at gmail.com (Tim Tisdall)
Date: Thu, 3 Sep 2015 10:18:46 -0400
Subject: [Python-Dev] Is hg.python.org out of memory?
In-Reply-To: <CAMpsgwbD7V+-fJafgNqywEMpQEFUOugs6KAEN=SryTV3GRs-sw@mail.gmail.com>
References: <CAMpsgwbD7V+-fJafgNqywEMpQEFUOugs6KAEN=SryTV3GRs-sw@mail.gmail.com>
Message-ID: <CAGxYWpa+JTZqNXHWeEZF-qvzGMuXg=Au2NmOHqYmYijjWdNA1A@mail.gmail.com>

I just get a refused connection from https://hg.python.org/ myself.

On 3 September 2015 at 06:31, Victor Stinner <victor.stinner at gmail.com>
wrote:

> Hi,
>
> I got HTTP 503 errors when trying to access http://hg.python.org/ and
> I got errors when trying to push changes with "hg push" (to
> ssh://hg at hg.python.org/cpython).
>
> I even got this error from "hg push":
> --
> remote: abort: /srv/hg/lib/python/mercurial/mpatch.so: failed to map
> segment from shared object: Cannot allocate memory!
> --
>
> Is someone available to check what happened on hg.python.org?
> Buildbots slowly become red because hg.python.org is no more
> avaialble.
>
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/tisdall%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150903/6044be6e/attachment.html>

From tisdall at gmail.com  Thu Sep  3 16:38:35 2015
From: tisdall at gmail.com (Tim Tisdall)
Date: Thu, 3 Sep 2015 10:38:35 -0400
Subject: [Python-Dev] Is hg.python.org out of memory?
In-Reply-To: <CAGxYWpa+JTZqNXHWeEZF-qvzGMuXg=Au2NmOHqYmYijjWdNA1A@mail.gmail.com>
References: <CAMpsgwbD7V+-fJafgNqywEMpQEFUOugs6KAEN=SryTV3GRs-sw@mail.gmail.com>
 <CAGxYWpa+JTZqNXHWeEZF-qvzGMuXg=Au2NmOHqYmYijjWdNA1A@mail.gmail.com>
Message-ID: <CAGxYWpZEXci5_RRVEYcx4SgA3oktFOt2X8BX7L9ayJNZzU-7WQ@mail.gmail.com>

...  and we're back.

On 3 September 2015 at 10:18, Tim Tisdall <tisdall at gmail.com> wrote:

> I just get a refused connection from https://hg.python.org/ myself.
>
> On 3 September 2015 at 06:31, Victor Stinner <victor.stinner at gmail.com>
> wrote:
>
>> Hi,
>>
>> I got HTTP 503 errors when trying to access http://hg.python.org/ and
>> I got errors when trying to push changes with "hg push" (to
>> ssh://hg at hg.python.org/cpython).
>>
>> I even got this error from "hg push":
>> --
>> remote: abort: /srv/hg/lib/python/mercurial/mpatch.so: failed to map
>> segment from shared object: Cannot allocate memory!
>> --
>>
>> Is someone available to check what happened on hg.python.org?
>> Buildbots slowly become red because hg.python.org is no more
>> avaialble.
>>
>> Victor
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/tisdall%40gmail.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150903/fb7656e8/attachment.html>

From valentine.sinitsyn at gmail.com  Thu Sep  3 09:23:48 2015
From: valentine.sinitsyn at gmail.com (Valentine Sinitsyn)
Date: Thu, 3 Sep 2015 12:23:48 +0500
Subject: [Python-Dev] tp_finalize vs tp_del sematics
In-Reply-To: <CAMSv6X2JqPbEX7q2QVmkeun7optrimS=GDKMcE9om=1dtk5cjA@mail.gmail.com>
References: <55D4360B.6010400@gmail.com>
 <CAMSv6X2RibK8FaG2Msd92+tVJJ7dQ4sRtb_XUUwotWU-AAGMvg@mail.gmail.com>
 <55DB65CD.9060505@gmail.com>
 <CAMSv6X2B03ezsRijrq8Kk7cbxAvqC1wdPA81hk+aTpk0z7fdcw@mail.gmail.com>
 <55DC1FB6.1010700@gmail.com>
 <CAMSv6X2JqPbEX7q2QVmkeun7optrimS=GDKMcE9om=1dtk5cjA@mail.gmail.com>
Message-ID: <55E7F584.9030207@gmail.com>

Hi Armin,

On 25.08.2015 13:00, Armin Rigo wrote:
> Hi Valentine,
>
> On 25 August 2015 at 09:56, Valentine Sinitsyn
> <valentine.sinitsyn at gmail.com> wrote:
>>> Yes, I think so.  There is a *highly obscure* corner case: __del__
>>> will still be called several times if you declare your class with
>>> "__slots__=()".
>>
>> Even on "post-PEP-0442" Python 3.4+? Could you share a link please?
>
> class X(object):
>      __slots__=()     # <= try with and without this
>      def __del__(self):
>          global revive
>          revive = self
>          print("hi")
>
> X()
> revive = None
> revive = None
> revive = None
By accident, I found a solution to this puzzle:

class X(object):
     __slots__ = ()

class Y(object):
     pass

import gc
gc.is_tracked(X())  # False
gc.is_tracked(Y())  # True

An object with _empty_ slots is naturally untracked, as it can't create 
back references.

Valentine

From chenzhuo8804 at gmail.com  Thu Sep  3 09:15:20 2015
From: chenzhuo8804 at gmail.com (Zhuo Chen)
Date: Thu, 3 Sep 2015 01:15:20 -0600
Subject: [Python-Dev] Request a builedbot username and password
Message-ID: <CD3551B1-2569-433A-82AE-BA073AD57042@gmail.com>

Hi I am interested in setting up a builedbot machine for python, I have a 2011 MacBook Pro with custom ssd and OS X Yosemite


From zachary.ware+pydev at gmail.com  Thu Sep  3 17:36:39 2015
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Thu, 3 Sep 2015 10:36:39 -0500
Subject: [Python-Dev] Request a builedbot username and password
In-Reply-To: <CD3551B1-2569-433A-82AE-BA073AD57042@gmail.com>
References: <CD3551B1-2569-433A-82AE-BA073AD57042@gmail.com>
Message-ID: <CAKJDb-PTOC2WYvBaVL-LzY3R=_1bPV7+-i3-Lko77q9-qDHOzg@mail.gmail.com>

On Thu, Sep 3, 2015 at 2:15 AM, Zhuo Chen <chenzhuo8804 at gmail.com> wrote:
> Hi I am interested in setting up a builedbot machine for python, I have a 2011 MacBook Pro with custom ssd and OS X Yosemite

Responding off-list.

-- 
Zach

From fijall at gmail.com  Thu Sep  3 21:08:07 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 3 Sep 2015 21:08:07 +0200
Subject: [Python-Dev] tp_finalize vs tp_del sematics
In-Reply-To: <55E7F584.9030207@gmail.com>
References: <55D4360B.6010400@gmail.com>
 <CAMSv6X2RibK8FaG2Msd92+tVJJ7dQ4sRtb_XUUwotWU-AAGMvg@mail.gmail.com>
 <55DB65CD.9060505@gmail.com>
 <CAMSv6X2B03ezsRijrq8Kk7cbxAvqC1wdPA81hk+aTpk0z7fdcw@mail.gmail.com>
 <55DC1FB6.1010700@gmail.com>
 <CAMSv6X2JqPbEX7q2QVmkeun7optrimS=GDKMcE9om=1dtk5cjA@mail.gmail.com>
 <55E7F584.9030207@gmail.com>
Message-ID: <CAK5idxR5OfyBcPB9LeKoj7e24G2ti3XkzbNxhKtbMoJFiqrAZA@mail.gmail.com>

On Thu, Sep 3, 2015 at 9:23 AM, Valentine Sinitsyn
<valentine.sinitsyn at gmail.com> wrote:
> Hi Armin,
>
> On 25.08.2015 13:00, Armin Rigo wrote:
>>
>> Hi Valentine,
>>
>> On 25 August 2015 at 09:56, Valentine Sinitsyn
>> <valentine.sinitsyn at gmail.com> wrote:
>>>>
>>>> Yes, I think so.  There is a *highly obscure* corner case: __del__
>>>> will still be called several times if you declare your class with
>>>> "__slots__=()".
>>>
>>>
>>> Even on "post-PEP-0442" Python 3.4+? Could you share a link please?
>>
>>
>> class X(object):
>>      __slots__=()     # <= try with and without this
>>      def __del__(self):
>>          global revive
>>          revive = self
>>          print("hi")
>>
>> X()
>> revive = None
>> revive = None
>> revive = None
>
> By accident, I found a solution to this puzzle:
>
> class X(object):
>     __slots__ = ()
>
> class Y(object):
>     pass
>
> import gc
> gc.is_tracked(X())  # False
> gc.is_tracked(Y())  # True
>
> An object with _empty_ slots is naturally untracked, as it can't create back
> references.
>
> Valentine
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com

That does not make it ok to have del called several time, does it?

From valentine.sinitsyn at gmail.com  Thu Sep  3 21:15:34 2015
From: valentine.sinitsyn at gmail.com (Valentine Sinitsyn)
Date: Fri, 4 Sep 2015 00:15:34 +0500
Subject: [Python-Dev] tp_finalize vs tp_del sematics
In-Reply-To: <CAK5idxR5OfyBcPB9LeKoj7e24G2ti3XkzbNxhKtbMoJFiqrAZA@mail.gmail.com>
References: <55D4360B.6010400@gmail.com>
 <CAMSv6X2RibK8FaG2Msd92+tVJJ7dQ4sRtb_XUUwotWU-AAGMvg@mail.gmail.com>
 <55DB65CD.9060505@gmail.com>
 <CAMSv6X2B03ezsRijrq8Kk7cbxAvqC1wdPA81hk+aTpk0z7fdcw@mail.gmail.com>
 <55DC1FB6.1010700@gmail.com>
 <CAMSv6X2JqPbEX7q2QVmkeun7optrimS=GDKMcE9om=1dtk5cjA@mail.gmail.com>
 <55E7F584.9030207@gmail.com>
 <CAK5idxR5OfyBcPB9LeKoj7e24G2ti3XkzbNxhKtbMoJFiqrAZA@mail.gmail.com>
Message-ID: <55E89C56.5070906@gmail.com>

Hi Maciej,

On 04.09.2015 00:08, Maciej Fijalkowski wrote:
> On Thu, Sep 3, 2015 at 9:23 AM, Valentine Sinitsyn
> <valentine.sinitsyn at gmail.com> wrote:
>> Hi Armin,
>>
>> On 25.08.2015 13:00, Armin Rigo wrote:
>>>
>>> Hi Valentine,
>>>
>>> On 25 August 2015 at 09:56, Valentine Sinitsyn
>>> <valentine.sinitsyn at gmail.com> wrote:
>>>>>
>>>>> Yes, I think so.  There is a *highly obscure* corner case: __del__
>>>>> will still be called several times if you declare your class with
>>>>> "__slots__=()".
>>>>
>>>>
>>>> Even on "post-PEP-0442" Python 3.4+? Could you share a link please?
>>>
>>>
>>> class X(object):
>>>       __slots__=()     # <= try with and without this
>>>       def __del__(self):
>>>           global revive
>>>           revive = self
>>>           print("hi")
>>>
>>> X()
>>> revive = None
>>> revive = None
>>> revive = None
>>
>> By accident, I found a solution to this puzzle:
>>
>> class X(object):
>>      __slots__ = ()
>>
>> class Y(object):
>>      pass
>>
>> import gc
>> gc.is_tracked(X())  # False
>> gc.is_tracked(Y())  # True
>>
>> An object with _empty_ slots is naturally untracked, as it can't create back
>> references.
>>
>> Valentine
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>
> That does not make it ok to have del called several time, does it?
That's a tricky question. Python's data model [1,2] doesn't say anything 
about how many times __del__ can be called. PEP-0442 guarantees it will 
be called only once, but it implicitly covers GC-objects only.

For me, it looks like destructor behaviour for non-GC object is 
undefined, but I agree it makes sense to call them exactly once as well.

1. https://docs.python.org/3/reference/datamodel.html
2. https://docs.python.org/2/reference/datamodel.html

--
Valentine

From arigo at tunes.org  Thu Sep  3 23:29:16 2015
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 3 Sep 2015 23:29:16 +0200
Subject: [Python-Dev] tp_finalize vs tp_del sematics
In-Reply-To: <55E89C56.5070906@gmail.com>
References: <55D4360B.6010400@gmail.com>
 <CAMSv6X2RibK8FaG2Msd92+tVJJ7dQ4sRtb_XUUwotWU-AAGMvg@mail.gmail.com>
 <55DB65CD.9060505@gmail.com>
 <CAMSv6X2B03ezsRijrq8Kk7cbxAvqC1wdPA81hk+aTpk0z7fdcw@mail.gmail.com>
 <55DC1FB6.1010700@gmail.com>
 <CAMSv6X2JqPbEX7q2QVmkeun7optrimS=GDKMcE9om=1dtk5cjA@mail.gmail.com>
 <55E7F584.9030207@gmail.com>
 <CAK5idxR5OfyBcPB9LeKoj7e24G2ti3XkzbNxhKtbMoJFiqrAZA@mail.gmail.com>
 <55E89C56.5070906@gmail.com>
Message-ID: <CAMSv6X0x+FjMHG5OAg+MSRKWC_4dEjkOpsyM_OMhCyx42-c5cA@mail.gmail.com>

Hi Valentine,

On Thu, Sep 3, 2015 at 9:15 PM, Valentine Sinitsyn
<valentine.sinitsyn at gmail.com> wrote:
>> That does not make it ok to have del called several time, does it?
>
> That's a tricky question.

If the Python documentation now says something like ``the __del__
method is never called more than once on the same instance'' without
acknowledging this corner case, then it could be regarded as
documentation bug.  I didn't check, though.  But feel free to open an
issue and mention everything I said above, if you want to.


A bient?t,

Armin.

From larry at hastings.org  Fri Sep  4 07:31:03 2015
From: larry at hastings.org (Larry Hastings)
Date: Thu, 03 Sep 2015 22:31:03 -0700
Subject: [Python-Dev] Creating server-side clones on hg.python.org is broken
	right now
Message-ID: <55E92C97.9020104@hastings.org>


Howdy.  I went here:

    https://hg.python.org/cpython/

I clicked on "Server-side clone".  I filled out the form.  I clicked on 
the "clone" button.  I was rewarded with this error message:

    error

    An error occurred while processing your request:

    no such method: rclone



HALP PLS FX,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150903/f7fa19b6/attachment.html>

From valentine.sinitsyn at gmail.com  Fri Sep  4 08:13:59 2015
From: valentine.sinitsyn at gmail.com (Valentine Sinitsyn)
Date: Fri, 4 Sep 2015 11:13:59 +0500
Subject: [Python-Dev] tp_finalize vs tp_del sematics
In-Reply-To: <CAMSv6X0x+FjMHG5OAg+MSRKWC_4dEjkOpsyM_OMhCyx42-c5cA@mail.gmail.com>
References: <55D4360B.6010400@gmail.com>
 <CAMSv6X2RibK8FaG2Msd92+tVJJ7dQ4sRtb_XUUwotWU-AAGMvg@mail.gmail.com>
 <55DB65CD.9060505@gmail.com>
 <CAMSv6X2B03ezsRijrq8Kk7cbxAvqC1wdPA81hk+aTpk0z7fdcw@mail.gmail.com>
 <55DC1FB6.1010700@gmail.com>
 <CAMSv6X2JqPbEX7q2QVmkeun7optrimS=GDKMcE9om=1dtk5cjA@mail.gmail.com>
 <55E7F584.9030207@gmail.com>
 <CAK5idxR5OfyBcPB9LeKoj7e24G2ti3XkzbNxhKtbMoJFiqrAZA@mail.gmail.com>
 <55E89C56.5070906@gmail.com>
 <CAMSv6X0x+FjMHG5OAg+MSRKWC_4dEjkOpsyM_OMhCyx42-c5cA@mail.gmail.com>
Message-ID: <55E936A7.10006@gmail.com>

Hi Armin,

On 04.09.2015 02:29, Armin Rigo wrote:
> Hi Valentine,
>
> On Thu, Sep 3, 2015 at 9:15 PM, Valentine Sinitsyn
> <valentine.sinitsyn at gmail.com> wrote:
>>> That does not make it ok to have del called several time, does it?
>>
>> That's a tricky question.
>
> If the Python documentation now says something like ``the __del__
> method is never called more than once on the same instance'' without
> acknowledging this corner case, then it could be regarded as
> documentation bug.  I didn't check, though.  But feel free to open an
> issue and mention everything I said above, if you want to.
I've checked the places I remembered, but didn't find any guarantees for 
__del__ to be called exactly once in general. Looks like it was only 
important to ensure safe finalization.

Looks a bit inconsistent though so it's probably appropriate to file the 
report.

Valentine

From status at bugs.python.org  Fri Sep  4 18:08:29 2015
From: status at bugs.python.org (Python tracker)
Date: Fri,  4 Sep 2015 18:08:29 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20150904160829.B7272567EC@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2015-08-28 - 2015-09-04)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    5057 (+15)
  closed 31704 (+33)
  total  36761 (+48)

Open issues with patches: 2257 


Issues opened (28)
==================

#24954: No way to generate or parse timezone as produced by datetime.i
http://bugs.python.org/issue24954  opened by gvanrossum

#24955: webbrowser broken on Mac OS X when using the BROWSER variable
http://bugs.python.org/issue24955  opened by sconseil

#24956: Default value for an argument that is not in the choices list 
http://bugs.python.org/issue24956  opened by Sworddragon

#24957: python3 -mpdb gets stuck in an unexitable infinite prompt loop
http://bugs.python.org/issue24957  opened by shlomif

#24959: unittest swallows part of stack trace when raising AssertionEr
http://bugs.python.org/issue24959  opened by chris.jerdonek

#24960: Can't use pip or easy_install with embeddable zip file.
http://bugs.python.org/issue24960  opened by Oleg N

#24964: Add tunnel CONNECT response headers to httplib / http.client
http://bugs.python.org/issue24964  opened by Thomas

#24965: Implement PEP 498: Literal String Formatting
http://bugs.python.org/issue24965  opened by eric.smith

#24966: shutil.get_terminal_size() throws ValueError if stdout is deta
http://bugs.python.org/issue24966  opened by rsc1975

#24969: functools.lru_cache: a way to set decorator arguments at runti
http://bugs.python.org/issue24969  opened by Marek Otahal

#24970: Make distutils.Command an ABC
http://bugs.python.org/issue24970  opened by Antony.Lee

#24972: IDLE: revisit text highlighting for inactive windows on win32
http://bugs.python.org/issue24972  opened by markroseman

#24973: CFLAGS for Visual Studio
http://bugs.python.org/issue24973  opened by christopher.hogan

#24977: shutil copy to non-existant directory
http://bugs.python.org/issue24977  opened by TheOrangeOne

#24978: Contributing to Python 2x and 3x Documentation. Translation to
http://bugs.python.org/issue24978  opened by overr1de

#24980: Allow for providing 'on_new_thread' callback to 'concurrent.fu
http://bugs.python.org/issue24980  opened by harlowja

#24981: Add a test which uses the ast module to compile the stdlib
http://bugs.python.org/issue24981  opened by brett.cannon

#24982: shutil.make_archive doesn't archive empty directories
http://bugs.python.org/issue24982  opened by eugenek

#24984: document AF_BLUETOOTH socket address formats
http://bugs.python.org/issue24984  opened by Tim.Tisdall

#24985: Python install test fails - OpenSSL - "dh key too small"
http://bugs.python.org/issue24985  opened by nagle

#24988: IDLE: debugger context menus not working on Mac
http://bugs.python.org/issue24988  opened by markroseman

#24990: Foreign language support in turtle module
http://bugs.python.org/issue24990  opened by Al.Sweigart

#24991: Define instance mutability explicitly on type objects
http://bugs.python.org/issue24991  opened by ncoghlan

#24995: better exception message when an unsupported object is passed 
http://bugs.python.org/issue24995  opened by yselivanov

#24996: IDLE: debugger local/global vars should not be editable
http://bugs.python.org/issue24996  opened by markroseman

#24997: mock.call_args compares as equal and not equal
http://bugs.python.org/issue24997  opened by akaptur

#24999: Segfault in test_re.test_sre_character_class_literals() when P
http://bugs.python.org/issue24999  opened by haypo

#25000: _mock_call does not properly grab args and kwargs
http://bugs.python.org/issue25000  opened by paetling



Most recent 15 issues with no replies (15)
==========================================

#24997: mock.call_args compares as equal and not equal
http://bugs.python.org/issue24997

#24985: Python install test fails - OpenSSL - "dh key too small"
http://bugs.python.org/issue24985

#24972: IDLE: revisit text highlighting for inactive windows on win32
http://bugs.python.org/issue24972

#24970: Make distutils.Command an ABC
http://bugs.python.org/issue24970

#24960: Can't use pip or easy_install with embeddable zip file.
http://bugs.python.org/issue24960

#24954: No way to generate or parse timezone as produced by datetime.i
http://bugs.python.org/issue24954

#24942: Remove domain from ipaddress.reverse_pointer property and add 
http://bugs.python.org/issue24942

#24940: RotatingFileHandler uses tell in non-binary mode to determine 
http://bugs.python.org/issue24940

#24936: Idle: handle 'raise' properly when running with subprocess (2.
http://bugs.python.org/issue24936

#24925: Allow doctest to find line number of __test__ strings if forma
http://bugs.python.org/issue24925

#24924: _posixsubprocess.c: sysconf() might not be async-signal-safe
http://bugs.python.org/issue24924

#24923: Append system paths in setup.py instead of prepending
http://bugs.python.org/issue24923

#24922: assertWarnsRegex doesn't allow multiple warning messages
http://bugs.python.org/issue24922

#24917: time_strftime() Buffer Over-read
http://bugs.python.org/issue24917

#24916: In sysconfig, don't rely on sys.version format
http://bugs.python.org/issue24916



Most recent 15 issues waiting for review (15)
=============================================

#24988: IDLE: debugger context menus not working on Mac
http://bugs.python.org/issue24988

#24984: document AF_BLUETOOTH socket address formats
http://bugs.python.org/issue24984

#24980: Allow for providing 'on_new_thread' callback to 'concurrent.fu
http://bugs.python.org/issue24980

#24973: CFLAGS for Visual Studio
http://bugs.python.org/issue24973

#24965: Implement PEP 498: Literal String Formatting
http://bugs.python.org/issue24965

#24955: webbrowser broken on Mac OS X when using the BROWSER variable
http://bugs.python.org/issue24955

#24938: Measure if _warnings.c is still worth having
http://bugs.python.org/issue24938

#24937: Multiple problems in getters & setters in capsulethunk.h
http://bugs.python.org/issue24937

#24934: django_v2 benchmark not working in Python 3.6
http://bugs.python.org/issue24934

#24930: test_ssl broker was fixed
http://bugs.python.org/issue24930

#24927: multiprocessing.Pool hangs forever on segfault
http://bugs.python.org/issue24927

#24925: Allow doctest to find line number of __test__ strings if forma
http://bugs.python.org/issue24925

#24923: Append system paths in setup.py instead of prepending
http://bugs.python.org/issue24923

#24917: time_strftime() Buffer Over-read
http://bugs.python.org/issue24917

#24916: In sysconfig, don't rely on sys.version format
http://bugs.python.org/issue24916



Top 10 most discussed issues (10)
=================================

#24912: The type of cached objects is mutable
http://bugs.python.org/issue24912  43 msgs

#23517: datetime.utcfromtimestamp rounds results incorrectly
http://bugs.python.org/issue23517  23 msgs

#7175: Define a standard location and API for configuration files
http://bugs.python.org/issue7175  15 msgs

#23406: interning and list comprehension leads to unexpected behavior
http://bugs.python.org/issue23406  12 msgs

#23630: support multiple hosts in create_server/start_server
http://bugs.python.org/issue23630  12 msgs

#17849: Missing size argument in readline() method for httplib's class
http://bugs.python.org/issue17849  10 msgs

#24966: shutil.get_terminal_size() throws ValueError if stdout is deta
http://bugs.python.org/issue24966  10 msgs

#22798: time.mktime doesn't update time.tzname
http://bugs.python.org/issue22798   7 msgs

#24984: document AF_BLUETOOTH socket address formats
http://bugs.python.org/issue24984   7 msgs

#24635: test_typing is flaky
http://bugs.python.org/issue24635   6 msgs



Issues closed (30)
==================

#7739: time.strftime may hung while trying to open /etc/localtime but
http://bugs.python.org/issue7739  closed by belopolsky

#23332: datetime.isoformat() -> explicitly mark UTC string as such
http://bugs.python.org/issue23332  closed by belopolsky

#23375: test_py3kwarn fails on Windows
http://bugs.python.org/issue23375  closed by haypo

#23623: Python 3.5 docs need to clarify how to set PATH, etc
http://bugs.python.org/issue23623  closed by paul.moore

#24707: Assertion failed in pymonotonic_new
http://bugs.python.org/issue24707  closed by haypo

#24881: _pyio checks that `os.name == 'win32'` instead of 'nt'
http://bugs.python.org/issue24881  closed by serhiy.storchaka

#24891: race condition in initstdio() (python aborts running under noh
http://bugs.python.org/issue24891  closed by haypo

#24913: deque.index() overruns deque boundary
http://bugs.python.org/issue24913  closed by larry

#24931: _asdict breaks when inheriting from a namedtuple
http://bugs.python.org/issue24931  closed by rhettinger

#24952: stack_size([size]) is actually stack_size(size=0)
http://bugs.python.org/issue24952  closed by martin.panter

#24953: ICC and version should be in COMPILER string when built with I
http://bugs.python.org/issue24953  closed by python-dev

#24958: Segfault in REPL after pressing "r" and PgUp twice (on Mageia 
http://bugs.python.org/issue24958  closed by r.david.murray

#24961: shell stdout broken after exiting interactive python prompt
http://bugs.python.org/issue24961  closed by ned.deily

#24962: Unnecessary space in using/mac
http://bugs.python.org/issue24962  closed by python-dev

#24963: ipaddress.IPv6Network doc typo
http://bugs.python.org/issue24963  closed by python-dev

#24967: add errors='ignore' to print kwargs
http://bugs.python.org/issue24967  closed by brett.cannon

#24968: Python 3 raises Unicode errors with the xxx.UTF-8 locale
http://bugs.python.org/issue24968  closed by haypo

#24971: os.environ.get() does not return the Environment Value in Linu
http://bugs.python.org/issue24971  closed by r.david.murray

#24974: ICC on Windows 8.1: _decimal fails to compile with default fp 
http://bugs.python.org/issue24974  closed by python-dev

#24975: Python 3.5 can't compile AST involving PEP 448 unpacking
http://bugs.python.org/issue24975  closed by yselivanov

#24976: Arithmetic/precision bug when using floating-point numbers
http://bugs.python.org/issue24976  closed by ezio.melotti

#24979: Allow timezone offsets greater than 24 hours
http://bugs.python.org/issue24979  closed by belopolsky

#24983: Wrong AttributeError propagation
http://bugs.python.org/issue24983  closed by martin.panter

#24986: It should be possible to build successfully without external l
http://bugs.python.org/issue24986  closed by python-dev

#24987: subprocess.Popen with shell=True doesn't create socket
http://bugs.python.org/issue24987  closed by asduj

#24989: scan_eol() Buffer Over-read
http://bugs.python.org/issue24989  closed by larry

#24992: collections.OrderedDict constructor (odict_new) doesn't handle
http://bugs.python.org/issue24992  closed by haypo

#24993: The C function PyCodec_NameReplaceErrors doesn't handle PyCaps
http://bugs.python.org/issue24993  closed by haypo

#24994: Python 3.4.2 64-bit Installer error (Please insert the disk:)
http://bugs.python.org/issue24994  closed by zach.ware

#24998: docs: subprocess.Popen example has extra/invalid parameter
http://bugs.python.org/issue24998  closed by r.david.murray

From victor.stinner at gmail.com  Sat Sep  5 00:45:52 2015
From: victor.stinner at gmail.com (haypo s)
Date: Sat, 5 Sep 2015 00:45:52 +0200
Subject: [Python-Dev] Should we use getentropy() for os.urandom()?
Message-ID: <CAMpsgwb2j-dHX4BQ76Xgg8uHxB0XY6b2mt6s+7gNhQmYHmfcwA@mail.gmail.com>

Hi,

I followed discussions on the new systems getrandom() on Linux and
getentropy() on OpenBSD. I wanted to use them in Python to avoid the
need of a file descriptor to read /dev/urandom.

Linux getrandom() is also more secure than /dev/urandom because it
blocks until /dev/urandom is feeded with enough entropy.

getentropy() and getrandom() are now used in Python 2.7.10, Python 3.4
and newer.

Today, an issue was reported on Solaris because os.urandom() is much
slower with Python 2.7.10:
https://bugs.python.org/issue25003

It looks like Solaris has getrandom() and getentropy(), and
getentropy() is slow.

Now I'm not sure that I understood the purpose of getentropy() even on
OpenBSD. Should it be used to feed a PRNG in user-space, or can it be
used as a PRNG?

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2?query=getentropy&sec=2

If getentropy() must only be used to feed a PRNG (which only use a few
bytes), we should remove the code using getentropy() (but getrandom()
should be kept).

Note: I didn't know that other operating systems supported getrandom()
and getentropy()! The feature looks recent in Solaris:
" Solaris 11.3 adds two new system calls, getrandom(2) and
getentropy(2), for getting random bit streams or raw entropy."
https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy
(article published at July, 2015)

Note2: There is an open discussion proposing to "Use arc4random under
OpenBSD for os.urandom() if /dev/urandom is not present"
https://bugs.python.org/issue22542

getentropy() issue in Python (closed):
https://bugs.python.org/issue22585

getrandom() issue in Python (closed):
https://bugs.python.org/issue22181

Victor

From guido at python.org  Sat Sep  5 01:05:28 2015
From: guido at python.org (Guido van Rossum)
Date: Fri, 4 Sep 2015 16:05:28 -0700
Subject: [Python-Dev] Should we use getentropy() for os.urandom()?
In-Reply-To: <CAMpsgwb2j-dHX4BQ76Xgg8uHxB0XY6b2mt6s+7gNhQmYHmfcwA@mail.gmail.com>
References: <CAMpsgwb2j-dHX4BQ76Xgg8uHxB0XY6b2mt6s+7gNhQmYHmfcwA@mail.gmail.com>
Message-ID: <CAP7+vJJbPmG3w0fR21nOkmRiLYuc8gDUKjMufZpvJYwGbO+Cpg@mail.gmail.com>

I'm no expert, but from the bug report and the man page you quoted it does
sound like getentropy() should only be used to seed a PRNG. It also sounds
like reading /dev/[u]random should be considered a PRNG. For evidence, the
man page on OS X says: "The random device produces uniformly distributed
random byte values of potentially high quality." It goes on to describe the
difference between the two on Linux (where urandom produces lower quality
when it runs out of entropy while random apparently blocks). It does sound
like we should not call getentropy() except to get a good seed for our own
PRNG.

On Fri, Sep 4, 2015 at 3:45 PM, haypo s <victor.stinner at gmail.com> wrote:

> Hi,
>
> I followed discussions on the new systems getrandom() on Linux and
> getentropy() on OpenBSD. I wanted to use them in Python to avoid the
> need of a file descriptor to read /dev/urandom.
>
> Linux getrandom() is also more secure than /dev/urandom because it
> blocks until /dev/urandom is feeded with enough entropy.
>
> getentropy() and getrandom() are now used in Python 2.7.10, Python 3.4
> and newer.
>
> Today, an issue was reported on Solaris because os.urandom() is much
> slower with Python 2.7.10:
> https://bugs.python.org/issue25003
>
> It looks like Solaris has getrandom() and getentropy(), and
> getentropy() is slow.
>
> Now I'm not sure that I understood the purpose of getentropy() even on
> OpenBSD. Should it be used to feed a PRNG in user-space, or can it be
> used as a PRNG?
>
>
> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2?query=getentropy&sec=2
>
> If getentropy() must only be used to feed a PRNG (which only use a few
> bytes), we should remove the code using getentropy() (but getrandom()
> should be kept).
>
> Note: I didn't know that other operating systems supported getrandom()
> and getentropy()! The feature looks recent in Solaris:
> " Solaris 11.3 adds two new system calls, getrandom(2) and
> getentropy(2), for getting random bit streams or raw entropy."
> https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy
> (article published at July, 2015)
>
> Note2: There is an open discussion proposing to "Use arc4random under
> OpenBSD for os.urandom() if /dev/urandom is not present"
> https://bugs.python.org/issue22542
>
> getentropy() issue in Python (closed):
> https://bugs.python.org/issue22585
>
> getrandom() issue in Python (closed):
> https://bugs.python.org/issue22181
>
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150904/0f118703/attachment.html>

From donald at stufft.io  Sat Sep  5 01:29:47 2015
From: donald at stufft.io (Donald Stufft)
Date: Fri, 4 Sep 2015 19:29:47 -0400
Subject: [Python-Dev] Should we use getentropy() for os.urandom()?
In-Reply-To: <CAP7+vJJbPmG3w0fR21nOkmRiLYuc8gDUKjMufZpvJYwGbO+Cpg@mail.gmail.com>
References: <CAMpsgwb2j-dHX4BQ76Xgg8uHxB0XY6b2mt6s+7gNhQmYHmfcwA@mail.gmail.com>
 <CAP7+vJJbPmG3w0fR21nOkmRiLYuc8gDUKjMufZpvJYwGbO+Cpg@mail.gmail.com>
Message-ID: <etPan.55ea296b.35ee18eb.fd6b@Draupnir.home>

On September 4, 2015 at 7:08:36 PM, Guido van Rossum (guido at python.org) wrote:
> I'm no expert, but from the bug report and the man page you quoted it does
> sound like getentropy() should only be used to seed a PRNG. It also sounds
> like reading /dev/[u]random should be considered a PRNG. For evidence, the
> man page on OS X says: "The random device produces uniformly distributed
> random byte values of potentially high quality." It goes on to describe the
> difference between the two on Linux (where urandom produces lower quality
> when it runs out of entropy while random apparently blocks). It does sound
> like we should not call getentropy() except to get a good seed for our own
> PRNG.


I don't recall the difference between getentropy and getrandom but
/dev/(u)random are basically the exact same except /dev/random tries to gues
how "random" it?s numbers are. The manpage for /dev/(u)random is basically
wrong. (See http://www.2uo.de/myths-about-urandom/ and
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/).

Someone who remembers what getentropy implements would have to chime in on
whether we should use it or not, but getrandom is basically a better form of
/dev/urandom.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



From eric at trueblade.com  Sat Sep  5 03:45:49 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Fri, 4 Sep 2015 21:45:49 -0400
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
Message-ID: <55EA494D.7090206@trueblade.com>

I've made a number of small changes to PEP 498. I don't think any of the
changes I've made in the last week are substantive. Mostly I've
clarified how it works and removing some limitations. The only
meaningful change is that expressions are now surrounded by parens
before they're evaluated. This allows for newlines inside of the
expressions to be ignored.

I think it's now ready for Guido to pronounce on it.

The code in issue 24965 is slightly out of date, in that it has some
limitations that are no longer mentioned in the PEP and doesn't enclose
the expression in parens before evaluation. If the PEP is accepted, I'll
fix that and update the issue.

-- 
Eric.

From Nikolaus at rath.org  Sat Sep  5 04:21:50 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Fri, 04 Sep 2015 19:21:50 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <55EA494D.7090206@trueblade.com> (Eric V. Smith's message of
 "Fri, 4 Sep 2015 21:45:49 -0400")
References: <55EA494D.7090206@trueblade.com>
Message-ID: <878u8ly5a9.fsf@vostro.rath.org>

On Sep 04 2015, "Eric V. Smith" <eric at trueblade.com> wrote:
> I've made a number of small changes to PEP 498. I don't think any of the
> changes I've made in the last week are substantive. Mostly I've
> clarified how it works and removing some limitations. The only
> meaningful change is that expressions are now surrounded by parens
> before they're evaluated. This allows for newlines inside of the
> expressions to be ignored.
>
> I think it's now ready for Guido to pronounce on it.

I just wanted to say that I think this is fantastic work. If the PEP
gets accepted, I expect that in my code f-strings will replace the other
interpolation mechanism in almost all cases.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From Nikolaus at rath.org  Sat Sep  5 04:36:55 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Fri, 04 Sep 2015 19:36:55 -0700
Subject: [Python-Dev] PEP 501 Shell Command Examples
Message-ID: <87613py4l4.fsf@vostro.rath.org>

Hi Nick,

You are giving

  runcommand(sh(i"cat {filename}"))

as an example that avoids injection attacks. While this is true, I think
this is still a terrible anti-pattern[1] that should not be entombed in
a PEP as a positive example.

Could you consider removing it?

(It doubly wastes resources by pointlessly calling a shell, and then by
parsing & quoting the argument only for the shell to do the same in
reverse).

Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From guido at python.org  Sat Sep  5 05:01:04 2015
From: guido at python.org (Guido van Rossum)
Date: Fri, 4 Sep 2015 20:01:04 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <55EA494D.7090206@trueblade.com>
References: <55EA494D.7090206@trueblade.com>
Message-ID: <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>

On Fri, Sep 4, 2015 at 6:45 PM, Eric V. Smith <eric at trueblade.com> wrote:

> I've made a number of small changes to PEP 498. I don't think any of the
> changes I've made in the last week are substantive. Mostly I've
> clarified how it works and removing some limitations. The only
> meaningful change is that expressions are now surrounded by parens
> before they're evaluated. This allows for newlines inside of the
> expressions to be ignored.
>
> I think it's now ready for Guido to pronounce on it.
>

And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
holiday in the US) in case anything unforeseen comes up, but this is really
the Last Call for this PEP.


> The code in issue 24965 is slightly out of date, in that it has some
> limitations that are no longer mentioned in the PEP and doesn't enclose
> the expression in parens before evaluation. If the PEP is accepted, I'll
> fix that and update the issue.


No worries. (The parens thing was something I suggested to Eric this
afternoon. :-)

I'll say a few words about PEPs 501 and 502, but I'll start separate
threads.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150904/26193fd6/attachment-0001.html>

From guido at python.org  Sat Sep  5 05:04:28 2015
From: guido at python.org (Guido van Rossum)
Date: Fri, 4 Sep 2015 20:04:28 -0700
Subject: [Python-Dev] Critique of PEP 501 (General purpose string
	interpolation)
Message-ID: <CAP7+vJKOaQn2iTvkghu5WHCw65BjwcOc7mOdUw9UNHnrgo72zw@mail.gmail.com>

I think it's too much effort for too little gain.

The motivation feels very weak; surely writing

  os.system("echo " + message_from_user)

is just as easy (as is the %s spelling), so the security issue can hardly
be blamed on PEP 498.

I also don't think that the current way to address such security issues is
a big deal:

- The subprocess module is complex for other reasons, and a simpler wrapper
could easily be made;

- Database wrappers have forever included their own solution for safely
quoting query parameters, and people who still don't use that are not
likely to care about i-strings either.

- Logging: again, it's hard to beat the existing solution, which mostly
comes down to using %r instead of %s for any user-supplied or otherwise
unverified data.

- HTML quoting is an art and I'm skeptical that the proposal will even work
for that use case.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150904/63dc2948/attachment.html>

From guido at python.org  Sat Sep  5 05:15:48 2015
From: guido at python.org (Guido van Rossum)
Date: Fri, 4 Sep 2015 20:15:48 -0700
Subject: [Python-Dev] Critique of PEP 502 (String Interpolation Redux)
Message-ID: <CAP7+vJLhrWYMs__jmoa1Vfwtw-2qd1_p4N1Vf8zvCzChEtdKfA@mail.gmail.com>

The text of the PEP has too much on motivation and rationale: maybe that
would be suitable for an informative PEP.

The proposal itself is under-specified.

But the real weakness cannot be fixed by improving the text: it is in the
key characteristic of the proposal, which wants to have its cake and eat
it, too.

This is initially likable: to recipients who don't know about e-strings
they behave just like regular strings; but recipients who *do* know about
them can extract the template and the values to be interpolated and use
these to build an alternative string, e.g. to be used as a translation.

However, in order to fulfill the former requirement, the type must inherit
from str (it's one of those built-in types for which duck typing doesn't
always work). And at the same time this is a real problem, because it's too
easy to lose the e-string. For example, any function that operates on
strings will operate on e-strings, but the result will in general be a
plain str instead of an e-string, which can be confusing for functions that
want the e-string. But *not* inheriting from str causes the reverse problem.

IOW, e-strings don't make a good alternative for f-strings -- they would
have to be added as a second string type. And the proliferation of similar
but different template string types cannot make anyone happy.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150904/e529a59c/attachment.html>

From victor.stinner at gmail.com  Sat Sep  5 10:47:31 2015
From: victor.stinner at gmail.com (haypo s)
Date: Sat, 5 Sep 2015 10:47:31 +0200
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAMpsgwa4zSX1MKdD4EpjmfpnHBf-H4K3BzMUtgnYjUucNHb1jg@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwa4zSX1MKdD4EpjmfpnHBf-H4K3BzMUtgnYjUucNHb1jg@mail.gmail.com>
Message-ID: <CAMpsgwYMVykBTaBswtTuO4oEqVr6DGwh6c82ayezaWT03SYjxg@mail.gmail.com>

2015-09-05 10:44 GMT+02:00 haypo s <victor.stinner at gmail.com>:
> PEP 498 allows to write >'abc' f'string'< which is replaced with
>>'abc' 'string'.__format__()< whereas str+str is a bad practice.

Oops, you should read which is replaced with >'abc' +
'string'.__format__()< with a '+' between the two strings.

Victor

From victor.stinner at gmail.com  Sat Sep  5 10:44:42 2015
From: victor.stinner at gmail.com (haypo s)
Date: Sat, 5 Sep 2015 10:44:42 +0200
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
Message-ID: <CAMpsgwa4zSX1MKdD4EpjmfpnHBf-H4K3BzMUtgnYjUucNHb1jg@mail.gmail.com>

2015-09-05 5:01 GMT+02:00 Guido van Rossum <guido at python.org>:
> And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> holiday in the US) in case anything unforeseen comes up, but this is really
> the Last Call for this PEP.

String concatenation is inefficient in Python because strings are
immutable. There is a micro-optimization which tried to reduce the bad
performances of a+b, but it's better to avoid it.

Python replaces >'abc' 'def'< with a single string >'abcdef'<. It's
done by the parser, there is no overhead at runtime.

PEP 498 allows to write >'abc' f'string'< which is replaced with
>'abc' 'string'.__format__()< whereas str+str is a bad practice.

I would prefer to force users to write an explicit '+' to remind them
that there are more efficient ways to concatenate strings like
''.join((str1, str2)) or putting the first string in the f-string:
>f'abcstring'<.

Section in the PEP:
https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings

Victor

From gjcarneiro at gmail.com  Sat Sep  5 11:12:03 2015
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Sat, 5 Sep 2015 10:12:03 +0100
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAMpsgwa4zSX1MKdD4EpjmfpnHBf-H4K3BzMUtgnYjUucNHb1jg@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwa4zSX1MKdD4EpjmfpnHBf-H4K3BzMUtgnYjUucNHb1jg@mail.gmail.com>
Message-ID: <CAO-CpEKArUBLxu4HJhvm7j1x_beNzd7tj_4QHEFTvh4FWGAyGg@mail.gmail.com>

On 5 September 2015 at 09:44, haypo s <victor.stinner at gmail.com> wrote:

> 2015-09-05 5:01 GMT+02:00 Guido van Rossum <guido at python.org>:
> > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> > holiday in the US) in case anything unforeseen comes up, but this is
> really
> > the Last Call for this PEP.
>
> String concatenation is inefficient in Python because strings are
> immutable. There is a micro-optimization which tried to reduce the bad
> performances of a+b, but it's better to avoid it.
>
> Python replaces >'abc' 'def'< with a single string >'abcdef'<. It's
> done by the parser, there is no overhead at runtime.
>
> PEP 498 allows to write >'abc' f'string'< which is replaced with
> >'abc' 'string'.__format__()< whereas str+str is a bad practice.
>
> I would prefer to force users to write an explicit '+' to remind them
> that there are more efficient ways to concatenate strings like
> ''.join((str1, str2)) or putting the first string in the f-string:
> >f'abcstring'<.
>
> Section in the PEP:
> https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings
>
>
That's a very good point!


> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com
>



-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/4f894365/attachment.html>

From victor.stinner at gmail.com  Sat Sep  5 11:10:12 2015
From: victor.stinner at gmail.com (haypo s)
Date: Sat, 5 Sep 2015 11:10:12 +0200
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
Message-ID: <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>

2015-09-05 5:01 GMT+02:00 Guido van Rossum <guido at python.org>:
> And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> holiday in the US) in case anything unforeseen comes up, but this is really
> the Last Call for this PEP.

Would it be possible to specify a subset of the Python language
allowed in f-string? For example, __import__ or lambda should not be
used in a f-string. I'm not convinced that a loop or
list/dict/set-comprehension is a good idea neither.

I would prefer to keep as much code as possible *outside* f-string because:
- text editor knows well how to color it
- static analyzers know how to analyze it
- it encourage developers to indent and comment their code correctly,
whereas f-string has more restrictons on indentation (is it possible
to indent and comment code inside a f-string?)

For example, for me it's a common practice to write a complex
list-comprehension on two lines for readability:

newlist = [very_complex_expression(item)
            for item in oldlist]
# sorry, it's hard to indent correctly in a mail client, especially Gmail

Well, I'm not convinced that we need a larger subset than what is
allowed currently in str.format(), simple expressions like: obj.attr,
obj[index], etc.

I recall horrible examples in the previous mail threads showing how
much complex code you can put inside f-string.

Even the following example from the PEP seems too complex to me:
print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in
valid_opts)}]", file=sys.stderr)

Oh, first I read [...] as a list-comprehension :-p But it's part of
the output string, not of the Python code...

I prefer to build the second parameter outside the f-string:
opts = '|'.join('--'+opt for opt in valid_opts)
print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)

f-string with complex code remembers me PHP where it was possible to
mix PHP and HTML. I have bad memories such... code? template? (I don't
know how to cal them). Text editors and me were unable to identify
quickly the beginning and end of the code. We have a similar issue
with Python unit test embedding Python code to run subprocesses. My
text editor vim is unable to identify if the current code is the
outter code or the code embedded in a long triple-quoted string
(especially when you open the file at the embedded code).

Maybe we should start with a simple f-string, play with it during one
cycle (Python 3.6), and then discuss again if it's necessary to extend
the allowed Python expresions inside f-string?

If you really want to allow *any* Python inside a f-string, can you
please at least explain in th PEP why you consider that it's a good
thing?

IMHO the main advantage of allowing expressions inside f-string is
that it adds something really new compared to the current str.format()
method. Without it, f-string are less interesting.

Victor

From rosuav at gmail.com  Sat Sep  5 12:57:25 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 5 Sep 2015 20:57:25 +1000
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
Message-ID: <CAPTjJmq9VRLfE0W3Ygk4tuF=QXoX6WP7DFZZfo4A1DNqcNx=xA@mail.gmail.com>

On Sat, Sep 5, 2015 at 7:10 PM, haypo s <victor.stinner at gmail.com> wrote:
> 2015-09-05 5:01 GMT+02:00 Guido van Rossum <guido at python.org>:
>> And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
>> holiday in the US) in case anything unforeseen comes up, but this is really
>> the Last Call for this PEP.
>
> Would it be possible to specify a subset of the Python language
> allowed in f-string? For example, __import__ or lambda should not be
> used in a f-string. I'm not convinced that a loop or
> list/dict/set-comprehension is a good idea neither.

PEP 8 and other style guides will quite possibly pick up some sort of
guidelines on the subject. The way I see it, though, it's like the
difference between lambda and def - there's a technical difference
(lambda and f-strings are restricted to expressions, so if you need
statements, pull it out of line), but for the rest, it's a judgement
call  as to how big your expression should be. The interpreter doesn't
need to be involved in that decision.

> I would prefer to keep as much code as possible *outside* f-string because:
> - text editor knows well how to color it
> - static analyzers know how to analyze it
> - it encourage developers to indent and comment their code correctly,
> whereas f-string has more restrictons on indentation (is it possible
> to indent and comment code inside a f-string?)

If it can be done inside parentheses, it can be done inside an
f-string. Though I suspect multi-line expressions will generally be a
bad idea - it'll be harder to see how much text is literal and how
much is the expression. But again, question for the style guides not
the interpreter.

Text editors and static analyzers will simply need to be taught that
f-strings are special forms of expression.

> Well, I'm not convinced that we need a larger subset than what is
> allowed currently in str.format(), simple expressions like: obj.attr,
> obj[index], etc.
> ...
> IMHO the main advantage of allowing expressions inside f-string is
> that it adds something really new compared to the current str.format()
> method. Without it, f-string are less interesting.

Putting these two paragraphs together: you're not convinced we need
f-strings, is that correct? I agree with your conclusion paragraph,
and feel that they *are* interesting and useful in their
currently-described state. Having full expression syntax available is
definitely worth while; it's exactly the same benefit as being able to
use lambda inside a function call, or anything else that we can do
inline.

ChrisA

From rosuav at gmail.com  Sat Sep  5 12:58:52 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 5 Sep 2015 20:58:52 +1000
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAPTjJmq9VRLfE0W3Ygk4tuF=QXoX6WP7DFZZfo4A1DNqcNx=xA@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAPTjJmq9VRLfE0W3Ygk4tuF=QXoX6WP7DFZZfo4A1DNqcNx=xA@mail.gmail.com>
Message-ID: <CAPTjJmqo=+CnLTweZvnq4bm=Cym9o9CzyKNm-kjo3W=wcSu==w@mail.gmail.com>

On Sat, Sep 5, 2015 at 8:57 PM, Chris Angelico <rosuav at gmail.com> wrote:
>> IMHO the main advantage of allowing expressions inside f-string is
>> that it adds something really new compared to the current str.format()
>> method. Without it, f-string are less interesting.
>
> I agree with your conclusion paragraph,
> and feel that they *are* interesting and useful in their
> currently-described state.

By the way, I've been using this PEP to drum up some excitement about
Python 3. Still trying to get some people to make the jump from 2.7,
but if this lands, it'll be cool and interesting and fun, and maybe
some more weight on the Py3 side of the scale :)

ChrisA

From ncoghlan at gmail.com  Sat Sep  5 13:59:48 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Sep 2015 21:59:48 +1000
Subject: [Python-Dev] PEP 501 Shell Command Examples
In-Reply-To: <87613py4l4.fsf@vostro.rath.org>
References: <87613py4l4.fsf@vostro.rath.org>
Message-ID: <CADiSq7esTLW51BY5if9OdgyQ3zp-kLpx-4uZAdpRUUV=9-GzoA@mail.gmail.com>

On 5 September 2015 at 12:36, Nikolaus Rath <Nikolaus at rath.org> wrote:
> Hi Nick,
>
> You are giving
>
>   runcommand(sh(i"cat {filename}"))
>
> as an example that avoids injection attacks. While this is true, I think
> this is still a terrible anti-pattern[1] that should not be entombed in
> a PEP as a positive example.
>
> Could you consider removing it?
>
> (It doubly wastes resources by pointlessly calling a shell, and then by
> parsing & quoting the argument only for the shell to do the same in
> reverse).

Any reasonable implementation of that pattern wouldn't actually call a
system shell, it would invoke something like Julia's command system.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Sat Sep  5 14:11:22 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Sep 2015 22:11:22 +1000
Subject: [Python-Dev] Critique of PEP 501 (General purpose string
	interpolation)
In-Reply-To: <CAP7+vJKOaQn2iTvkghu5WHCw65BjwcOc7mOdUw9UNHnrgo72zw@mail.gmail.com>
References: <CAP7+vJKOaQn2iTvkghu5WHCw65BjwcOc7mOdUw9UNHnrgo72zw@mail.gmail.com>
Message-ID: <CADiSq7dN3WgR1qNxJ9iYvqzWsZ+eyXhRCgwtAsY3GsC_1wqvJw@mail.gmail.com>

On 5 September 2015 at 13:04, Guido van Rossum <guido at python.org> wrote:
> I think it's too much effort for too little gain.
>
> The motivation feels very weak; surely writing
>
>   os.system("echo " + message_from_user)
>
> is just as easy (as is the %s spelling), so the security issue can hardly be
> blamed on PEP 498.

That's fair - writing PEP 501 actually made *me* a lot more
comfortable with PEP 498.

Rather than asking for a pronouncement, I've marked 501 as Deferred -
I still think it's potentially interesting, but I also think it's
worth taking our time and seeing how far we can get with just eager
rendering. If cases emerge where the lack of delayed rendering support
is keenly felt, then it isn't hard to resurrect a deferred PEP.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From guido at python.org  Sat Sep  5 17:48:05 2015
From: guido at python.org (Guido van Rossum)
Date: Sat, 5 Sep 2015 08:48:05 -0700
Subject: [Python-Dev] Critique of PEP 501 (General purpose string
	interpolation)
In-Reply-To: <CADiSq7dN3WgR1qNxJ9iYvqzWsZ+eyXhRCgwtAsY3GsC_1wqvJw@mail.gmail.com>
References: <CAP7+vJKOaQn2iTvkghu5WHCw65BjwcOc7mOdUw9UNHnrgo72zw@mail.gmail.com>
 <CADiSq7dN3WgR1qNxJ9iYvqzWsZ+eyXhRCgwtAsY3GsC_1wqvJw@mail.gmail.com>
Message-ID: <CAP7+vJLW008hME-szt__rkaOZfDkZLZvExG9zV+0h0qWp1CFdA@mail.gmail.com>

On Sat, Sep 5, 2015 at 5:11 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 5 September 2015 at 13:04, Guido van Rossum <guido at python.org> wrote:
> > I think it's too much effort for too little gain.
> >
> > The motivation feels very weak; surely writing
> >
> >   os.system("echo " + message_from_user)
> >
> > is just as easy (as is the %s spelling), so the security issue can
> hardly be
> > blamed on PEP 498.
>
> That's fair - writing PEP 501 actually made *me* a lot more
> comfortable with PEP 498.
>
> Rather than asking for a pronouncement, I've marked 501 as Deferred -
> I still think it's potentially interesting, but I also think it's
> worth taking our time and seeing how far we can get with just eager
> rendering. If cases emerge where the lack of delayed rendering support
> is keenly felt, then it isn't hard to resurrect a deferred PEP.
>

Thank you. I agree with that assessment.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/d7ac94af/attachment.html>

From guido at python.org  Sat Sep  5 17:55:42 2015
From: guido at python.org (Guido van Rossum)
Date: Sat, 5 Sep 2015 08:55:42 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAMpsgwa4zSX1MKdD4EpjmfpnHBf-H4K3BzMUtgnYjUucNHb1jg@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwa4zSX1MKdD4EpjmfpnHBf-H4K3BzMUtgnYjUucNHb1jg@mail.gmail.com>
Message-ID: <CAP7+vJ+mZ4txoi4f1v5gReJzzf2P512B=HGxo02Z8yDXwpXueQ@mail.gmail.com>

On Sat, Sep 5, 2015 at 1:44 AM, haypo s <victor.stinner at gmail.com> wrote:

> 2015-09-05 5:01 GMT+02:00 Guido van Rossum <guido at python.org>:
> > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> > holiday in the US) in case anything unforeseen comes up, but this is
> really
> > the Last Call for this PEP.
>
> String concatenation is inefficient in Python because strings are
> immutable. There is a micro-optimization which tried to reduce the bad
> performances of a+b, but it's better to avoid it.
>
> Python replaces >'abc' 'def'< with a single string >'abcdef'<. It's
> done by the parser, there is no overhead at runtime.
>
> PEP 498 allows to write >'abc' f'string'< which is replaced with
> >'abc' 'string'.__format__()< whereas str+str is a bad practice.
>
> I would prefer to force users to write an explicit '+' to remind them
> that there are more efficient ways to concatenate strings like
> ''.join((str1, str2)) or putting the first string in the f-string:
> >f'abcstring'<.
>
> Section in the PEP:
> https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings
>
> Victor
>

What does the extra + buy users? It's just more punctuation noise. The
implementation is intentionally left unspecified by the PEP; it should be
possible to design an implementation that combines all the parts together
more efficiently than the use of + (e.g. using a "string builder" object
internally).

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/ecb16a78/attachment.html>

From guido at python.org  Sat Sep  5 18:18:45 2015
From: guido at python.org (Guido van Rossum)
Date: Sat, 5 Sep 2015 09:18:45 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
Message-ID: <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>

On Sat, Sep 5, 2015 at 2:10 AM, haypo s <victor.stinner at gmail.com> wrote:

> 2015-09-05 5:01 GMT+02:00 Guido van Rossum <guido at python.org>:
> > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> > holiday in the US) in case anything unforeseen comes up, but this is
> really
> > the Last Call for this PEP.
>
> Would it be possible to specify a subset of the Python language
> allowed in f-string? For example, __import__ or lambda should not be
> used in a f-string. I'm not convinced that a loop or
> list/dict/set-comprehension is a good idea neither.
>

We already went over this. You might as well argue that __import__ or
lambda should not be used as arguments to print(). It's an expression, and
it must allow exactly everything that is allowed in other places where
expressions are allowed.

Of course you don't *have* to write those things in f-string
interpolations. But that's just a style guide; the language should not try
to second-guess the user.


> I would prefer to keep as much code as possible *outside* f-string because:
> - text editor knows well how to color it
> - static analyzers know how to analyze it
> - it encourage developers to indent and comment their code correctly,
> whereas f-string has more restrictons on indentation


Really, we already went over most of this. You can put whitespace (even
newlines) exactly where they are allowed in other expressions, as long as
they don't terminate the string. You probably shouldn't do any of those
things regularly, but there are lots of other things you that you can do in
Python that you shouldn't.

>
> (is it possible to indent and comment code inside a f-string?)
>

Now that's an interesting question. I think the answer must be No, because
we don't want to deal with ambiguities like whether a closing curly bracket
or string quote should be ignored inside such comments. The processing of
f-strings described by the PEP uses several phases:

- find the end of the string (the final quote[s]) using the same algorithm
used for all string literals
- expand \ escapes (e.g. \uXXXX)
- look for single {, then scan ahead to a matching } -- this skips matching
() [] {}
- look for optional !a,!r,!s and !<spec> inside each {...} pair
- take what's left, enclose it in (), parse as expression

The presence of comments would impede several of these stages.


> For example, for me it's a common practice to write a complex
> list-comprehension on two lines for readability:
>
> newlist = [very_complex_expression(item)
>             for item in oldlist]
> # sorry, it's hard to indent correctly in a mail client, especially Gmail
>

The list comprehension across two lines without the comment would be fine
in a triple-quoted f-string (or perhaps even in a single-quoted f-string if
you put a \ before the line break).


> Well, I'm not convinced that we need a larger subset than what is
> allowed currently in str.format(), simple expressions like: obj.attr,
> obj[index], etc.
>

The PEP explains why actually.


> I recall horrible examples in the previous mail threads showing how
> much complex code you can put inside f-string.
>

Yes, that was a very poorly thought out argument. All of Python should be
condemned if you took it seriously.


> Even the following example from the PEP seems too complex to me:
> print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in
> valid_opts)}]", file=sys.stderr)
>
> Oh, first I read [...] as a list-comprehension :-p But it's part of
> the output string, not of the Python code...
>
> I prefer to build the second parameter outside the f-string:
> opts = '|'.join('--'+opt for opt in valid_opts)
> print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)
>

The same criticism can be made for the original version (using .format()),
which was lifted from real code.


> f-string with complex code remembers me PHP where it was possible to
> mix PHP and HTML. I have bad memories such... code? template? (I don't
> know how to cal them). Text editors and me were unable to identify
> quickly the beginning and end of the code. We have a similar issue
> with Python unit test embedding Python code to run subprocesses. My
> text editor vim is unable to identify if the current code is the
> outter code or the code embedded in a long triple-quoted string
> (especially when you open the file at the embedded code).
>

Yeah, tools will need to be updated. There are several other languages
(e.g. Ruby) that allow arbitrary expressions in strings and at least some
editors have no problem with them, even vim.


> Maybe we should start with a simple f-string, play with it during one
> cycle (Python 3.6), and then discuss again if it's necessary to extend
> the allowed Python expresions inside f-string?
>
> If you really want to allow *any* Python inside a f-string, can you
> please at least explain in the PEP why you consider that it's a good
> thing?
>

Sigh. We've gone over this on python-ideas. Your objection is not new.


> IMHO the main advantage of allowing expressions inside f-string is
> that it adds something really new compared to the current str.format()
> method. Without it, f-string are less interesting.
>

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/1727619e/attachment.html>

From brett at python.org  Sat Sep  5 18:44:08 2015
From: brett at python.org (Brett Cannon)
Date: Sat, 05 Sep 2015 16:44:08 +0000
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
Message-ID: <CAP1=2W5iYX3kNDD9i53JsHTkhu-EmFKZftcXA9__v7SRBQx=VA@mail.gmail.com>

On Sat, 5 Sep 2015 at 09:19 Guido van Rossum <guido at python.org> wrote:

> On Sat, Sep 5, 2015 at 2:10 AM, haypo s <victor.stinner at gmail.com> wrote:
>
>> 2015-09-05 5:01 GMT+02:00 Guido van Rossum <guido at python.org>:
>> > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
>> > holiday in the US) in case anything unforeseen comes up, but this is
>> really
>> > the Last Call for this PEP.
>>
>> Would it be possible to specify a subset of the Python language
>> allowed in f-string? For example, __import__ or lambda should not be
>> used in a f-string. I'm not convinced that a loop or
>> list/dict/set-comprehension is a good idea neither.
>>
>
> We already went over this. You might as well argue that __import__ or
> lambda should not be used as arguments to print(). It's an expression, and
> it must allow exactly everything that is allowed in other places where
> expressions are allowed.
>
> Of course you don't *have* to write those things in f-string
> interpolations. But that's just a style guide; the language should not try
> to second-guess the user.
>

Right, it's the whole "consenting adults" bit along with trying to minimize
surprise by placing restrictions that are hard to remember. Having the
restriction of "it must be an expression" is pretty minor thing to remember
vs. "it must a specific f-string subset of Python as defined in section
N.N.N of the language spec". One of those fits in my brain and one of them
does not. ;)


>
>
>> I would prefer to keep as much code as possible *outside* f-string
>> because:
>> - text editor knows well how to color it
>> - static analyzers know how to analyze it
>> - it encourage developers to indent and comment their code correctly,
>> whereas f-string has more restrictons on indentation
>
>
> Really, we already went over most of this. You can put whitespace (even
> newlines) exactly where they are allowed in other expressions, as long as
> they don't terminate the string. You probably shouldn't do any of those
> things regularly, but there are lots of other things you that you can do in
> Python that you shouldn't.
>

As Guido said, we're consenting adults and if it makes the code unreadable
then don't do it. Just like we promote refactoring code to have more
functions to be more readable even though it adds overhead, I suspect we
will end up updating PEP 8 to say that f-strings should tend towards simple
expressions and should never compromise the readability of the code, in
which case the expressions should be hoisted out of the f-string and into
the surrounding code.

I also don't think that we should tie our hands in the design of the
language because it makes some work on behalf of the tool providers. If it
made it impossible then I think we should discuss it, but simply requiring
some more work from tools isn't a sufficient condition to restrict what we
do. That's like saying Guido shouldn't have gone with whitespace-delimited
formatting because most editors didn't support it back in the day and it
took some effort to support it since it wasn't such a simple "find the
matching curly brace" algorithm that applied to most languages.

I appreciate wanting to *promote* making code be readable, I don't think it
should come at the *cost* of the simplicity of the solution when coding
practices can easily make up for any ugliness that is possible.

-Brett


>
>>
>> (is it possible to indent and comment code inside a f-string?)
>>
>
> Now that's an interesting question. I think the answer must be No, because
> we don't want to deal with ambiguities like whether a closing curly bracket
> or string quote should be ignored inside such comments. The processing of
> f-strings described by the PEP uses several phases:
>
> - find the end of the string (the final quote[s]) using the same algorithm
> used for all string literals
> - expand \ escapes (e.g. \uXXXX)
> - look for single {, then scan ahead to a matching } -- this skips
> matching () [] {}
> - look for optional !a,!r,!s and !<spec> inside each {...} pair
> - take what's left, enclose it in (), parse as expression
>
> The presence of comments would impede several of these stages.
>
>
>> For example, for me it's a common practice to write a complex
>> list-comprehension on two lines for readability:
>>
>> newlist = [very_complex_expression(item)
>>             for item in oldlist]
>> # sorry, it's hard to indent correctly in a mail client, especially Gmail
>>
>
> The list comprehension across two lines without the comment would be fine
> in a triple-quoted f-string (or perhaps even in a single-quoted f-string if
> you put a \ before the line break).
>
>
>> Well, I'm not convinced that we need a larger subset than what is
>> allowed currently in str.format(), simple expressions like: obj.attr,
>> obj[index], etc.
>>
>
> The PEP explains why actually.
>
>
>> I recall horrible examples in the previous mail threads showing how
>> much complex code you can put inside f-string.
>>
>
> Yes, that was a very poorly thought out argument. All of Python should be
> condemned if you took it seriously.
>
>
>> Even the following example from the PEP seems too complex to me:
>> print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in
>> valid_opts)}]", file=sys.stderr)
>>
>> Oh, first I read [...] as a list-comprehension :-p But it's part of
>> the output string, not of the Python code...
>>
>> I prefer to build the second parameter outside the f-string:
>> opts = '|'.join('--'+opt for opt in valid_opts)
>> print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)
>>
>
> The same criticism can be made for the original version (using .format()),
> which was lifted from real code.
>
>
>> f-string with complex code remembers me PHP where it was possible to
>> mix PHP and HTML. I have bad memories such... code? template? (I don't
>> know how to cal them). Text editors and me were unable to identify
>> quickly the beginning and end of the code. We have a similar issue
>> with Python unit test embedding Python code to run subprocesses. My
>> text editor vim is unable to identify if the current code is the
>> outter code or the code embedded in a long triple-quoted string
>> (especially when you open the file at the embedded code).
>>
>
> Yeah, tools will need to be updated. There are several other languages
> (e.g. Ruby) that allow arbitrary expressions in strings and at least some
> editors have no problem with them, even vim.
>
>
>> Maybe we should start with a simple f-string, play with it during one
>> cycle (Python 3.6), and then discuss again if it's necessary to extend
>> the allowed Python expresions inside f-string?
>>
>> If you really want to allow *any* Python inside a f-string, can you
>>
> please at least explain in the PEP why you consider that it's a good
>> thing?
>>
>
> Sigh. We've gone over this on python-ideas. Your objection is not new.
>
>
>> IMHO the main advantage of allowing expressions inside f-string is
>> that it adds something really new compared to the current str.format()
>> method. Without it, f-string are less interesting.
>>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/4ae8c2f4/attachment-0001.html>

From gjcarneiro at gmail.com  Sat Sep  5 19:14:53 2015
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Sat, 05 Sep 2015 17:14:53 +0000
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAP7+vJ+mZ4txoi4f1v5gReJzzf2P512B=HGxo02Z8yDXwpXueQ@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwa4zSX1MKdD4EpjmfpnHBf-H4K3BzMUtgnYjUucNHb1jg@mail.gmail.com>
 <CAP7+vJ+mZ4txoi4f1v5gReJzzf2P512B=HGxo02Z8yDXwpXueQ@mail.gmail.com>
Message-ID: <CAO-CpELpC79b+iC8psyrNt2jGC0dZwvxMWFFvaCD=HhfZQri3g@mail.gmail.com>

Why not allow string concatenation without plus sign only if/when the
implementation becomes optimised to allow compile time concatenation?  This
makes it crystal clear whether the concatenation is compile time or
runtime. If we allow it now, it's hard to tell without looking at the
CPython source code...

On Sat, 5 Sep 2015 16:57 Guido van Rossum <guido at python.org> wrote:

On Sat, Sep 5, 2015 at 1:44 AM, haypo s <victor.stinner at gmail.com> wrote:

2015-09-05 5:01 GMT+02:00 Guido van Rossum <guido at python.org>:
> And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> holiday in the US) in case anything unforeseen comes up, but this is
really
> the Last Call for this PEP.

String concatenation is inefficient in Python because strings are
immutable. There is a micro-optimization which tried to reduce the bad
performances of a+b, but it's better to avoid it.

Python replaces >'abc' 'def'< with a single string >'abcdef'<. It's
done by the parser, there is no overhead at runtime.

PEP 498 allows to write >'abc' f'string'< which is replaced with
>'abc' 'string'.__format__()< whereas str+str is a bad practice.

I would prefer to force users to write an explicit '+' to remind them
that there are more efficient ways to concatenate strings like
''.join((str1, str2)) or putting the first string in the f-string:
>f'abcstring'<.

Section in the PEP:
https
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>://
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>
www.python.org
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>/dev/
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>
pepsstring
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>
/pep-0498/#concatenating-strings
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>

Victor

What does the extra + buy users? It's just more punctuation noise. The
implementation is intentionally left unspecified by the PEP; it should be
possible to design an implementation that combines all the parts together
more efficiently than the use of + (e.g. using a "string builder" object
internally).


-- 

--Guido van Rossum (python.org <http://python.org/~guido>/~
<http://python.org/~guido>guido <http://python.org/~guido>)

_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https <https://mail.python.org/mailman/listinfo/python-dev>://
<https://mail.python.org/mailman/listinfo/python-dev>mail.python.org
<https://mail.python.org/mailman/listinfo/python-dev>/mailman/
<https://mail.python.org/mailman/listinfo/python-dev>listinfo
<https://mail.python.org/mailman/listinfo/python-dev>/
<https://mail.python.org/mailman/listinfo/python-dev>python-dev
<https://mail.python.org/mailman/listinfo/python-dev>
Unsubscribe: https
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
://
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
mail.python.org
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
/mailman/options/
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
python-dev
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>/
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
gjcarneiro%40gmail.com
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/ee82b665/attachment.html>

From python-ideas at mgmiller.net  Sat Sep  5 19:18:20 2015
From: python-ideas at mgmiller.net (Mike Miller)
Date: Sat, 5 Sep 2015 10:18:20 -0700
Subject: [Python-Dev] Critique of PEP 502 (String Interpolation Redux)
In-Reply-To: <CAP7+vJLhrWYMs__jmoa1Vfwtw-2qd1_p4N1Vf8zvCzChEtdKfA@mail.gmail.com>
References: <CAP7+vJLhrWYMs__jmoa1Vfwtw-2qd1_p4N1Vf8zvCzChEtdKfA@mail.gmail.com>
Message-ID: <55EB23DC.2020805@mgmiller.net>


On 09/04/2015 08:15 PM, Guido van Rossum wrote:
> The text of the PEP has too much on motivation and rationale: maybe that would
> be suitable for an informative PEP.  The proposal itself is under-specified.
> But the real weakness cannot be fixed by improving the text: it is in the key?

I'm planning on writing an improved version, but haven't the time to get to it 
this past week; huge project at work.  (Though it may not matter at this point 
as the last sentence indicates.)

Since another thread on the list just started about whether to allow arbitrary 
expressions, I think it is important to have a good explanation of that for 
those that might disagree at first, a place to send them.  That was easier for 
me to write than making interpreter improvements, which explains the current 
state of PEP 502 well... fair enough.

> This is initially likable: to recipients who don't know about e-strings they
> behave just like regular strings; but recipients who *do* know about them can
> extract the template and the values to be interpolated and use these to build an
> alternative string, e.g. to be used as a translation.
>
> However, in order to fulfill the former requirement, the type must inherit from
> str (it's one of those built-in types for which duck typing doesn't always
> work). And at the same time this is a real problem, because it's too easy to..

Yes, was aiming to "split the difference" and produce a helpful object that 
could alleviate various concerns.  The design is somewhat successful at that. 
However, while we could mitigate "losing the object" with docs and 
magic-methods, the end-result is still less compelling than I had hoped.  The 
exercise was helpful in that regard.

There is something quite nice about the simplicity of PEP 498 for the developer. 
  It can also be explained to critics as just "syntactic sugar over existing 
str.format," which is compelling.  Though, can we do any cherry picking from 
these PEPs?

While the 498 implementation is great, I'd argue that the 502 expression-string 
nomenclature is a bit better.  The terminology is not heavily used for strings 
in the stdlib (as format and template are), the e/expression name highlights the 
difference in capability, and in conversations doesn't remind one of the f-word, 
haha.

-Mike

From mertz at gnosis.cx  Sat Sep  5 19:27:26 2015
From: mertz at gnosis.cx (David Mertz)
Date: Sat, 5 Sep 2015 10:27:26 -0700
Subject: [Python-Dev] What's New editing
In-Reply-To: <55E7AA86.7020504@gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
 <55E7AA86.7020504@gmail.com>
Message-ID: <CAEbHw4Y42n5ugU-aO9jcdvRje6DA6SeK-LSOWoFQGCSOKefnBA@mail.gmail.com>

I have to apologize profusely here.  Just after I offered to do this (and
work even said it was OK in principle to do it on work time), my work load
went through the roof.  And now it's really already later than most of it
should have been done.  I'd still very much like to work on this, but I
wonder if maybe someone else would like to be co-author since the increased
workload doesn't actually seem likely to diminish soon.

On Wed, Sep 2, 2015 at 7:03 PM, Yury Selivanov <yselivanov.ml at gmail.com>
wrote:

>
>
> On 2015-07-06 11:38 AM, David Mertz wrote:
>
>> Hi Folks,
>>
>> I hereby volunteer to write "What's New for Python 3.5?" if folks on
>> python-dev are fine with me taking the job (i.e. I ran it by Travis, my
>> boss at Continuum, and he's happy to allow me to do that work within my
>> salaried hours... so having time isn't a problem).
>>
>> If this is OK with the powers-that-be, I'll coordinate with David Murray
>> on how best to take over this task from him.
>>
>
> Hi David,
>
> Are you still going to work on what's new for 3.5?
>
> Yury
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/ec767be6/attachment.html>

From njs at pobox.com  Sat Sep  5 19:28:27 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Sat, 5 Sep 2015 10:28:27 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
Message-ID: <CAPJVwB=6qiirhM1-dC9oO9yKERXWfLeEO=yjd1xExxtFtd4KBA@mail.gmail.com>

On Sep 5, 2015 9:20 AM, "Guido van Rossum" <guido at python.org> wrote:
>
> The processing of f-strings described by the PEP uses several phases:
>
> - find the end of the string (the final quote[s]) using the same
algorithm used for all string literals
> - expand \ escapes (e.g. \uXXXX)

It might be worth calling out explicitly in the text how this works for
what I suspect will be the most common case: embedded quoting embedded
quotes, like

    f"{ table[\"foo\"] }"

> - look for single {, then scan ahead to a matching } -- this skips
matching () [] {}

I assume this part of the algorithm uses the lexer and scans for matching
tokens rather than just scanning for characters? I tried looking at the PEP
to double check but couldn't find the relevant part. It's important for
things like

     f"{ '}' }"

> - look for optional !a,!r,!s and !<spec> inside each {...} pair
> - take what's left, enclose it in (), parse as expression

In fact maybe this whole list that Guido wrote should be copied into the
PEP; it's a good summary :-).

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/48c608ab/attachment.html>

From rymg19 at gmail.com  Sat Sep  5 19:36:56 2015
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Sat, 05 Sep 2015 12:36:56 -0500
Subject: [Python-Dev] What's New editing
In-Reply-To: <CAEbHw4Y42n5ugU-aO9jcdvRje6DA6SeK-LSOWoFQGCSOKefnBA@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
 <55E7AA86.7020504@gmail.com>
 <CAEbHw4Y42n5ugU-aO9jcdvRje6DA6SeK-LSOWoFQGCSOKefnBA@mail.gmail.com>
Message-ID: <6EA0672C-34EE-4983-A8B0-30B2818DEF54@gmail.com>



On September 5, 2015 12:27:26 PM CDT, David Mertz <mertz at gnosis.cx> wrote:
>I have to apologize profusely here.  Just after I offered to do this
>(and
>work even said it was OK in principle to do it on work time), my work
>load
>went through the roof.  And now it's really already later than most of
>it
>should have been done.  I'd still very much like to work on this, but I
>wonder if maybe someone else would like to be co-author since the
>increased
>workload doesn't actually seem likely to diminish soon.

So...

I also have a lot of stuff right now, but it's not that bad...could I help out here?


>
>On Wed, Sep 2, 2015 at 7:03 PM, Yury Selivanov
><yselivanov.ml at gmail.com>
>wrote:
>
>>
>>
>> On 2015-07-06 11:38 AM, David Mertz wrote:
>>
>>> Hi Folks,
>>>
>>> I hereby volunteer to write "What's New for Python 3.5?" if folks on
>>> python-dev are fine with me taking the job (i.e. I ran it by Travis,
>my
>>> boss at Continuum, and he's happy to allow me to do that work within
>my
>>> salaried hours... so having time isn't a problem).
>>>
>>> If this is OK with the powers-that-be, I'll coordinate with David
>Murray
>>> on how best to take over this task from him.
>>>
>>
>> Hi David,
>>
>> Are you still going to work on what's new for 3.5?
>>
>> Yury
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>>

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

From eric at trueblade.com  Sat Sep  5 19:39:23 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Sat, 5 Sep 2015 13:39:23 -0400
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <CAPJVwB=6qiirhM1-dC9oO9yKERXWfLeEO=yjd1xExxtFtd4KBA@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
 <CAPJVwB=6qiirhM1-dC9oO9yKERXWfLeEO=yjd1xExxtFtd4KBA@mail.gmail.com>
Message-ID: <55EB28CB.1020209@trueblade.com>

On 9/5/2015 1:28 PM, Nathaniel Smith wrote:
> On Sep 5, 2015 9:20 AM, "Guido van Rossum" <guido at python.org
> <mailto:guido at python.org>> wrote:
>>
>> The processing of f-strings described by the PEP uses several phases:
>>
>> - find the end of the string (the final quote[s]) using the same
> algorithm used for all string literals
>> - expand \ escapes (e.g. \uXXXX)
> 
> It might be worth calling out explicitly in the text how this works for
> what I suspect will be the most common case: embedded quoting embedded
> quotes, like
> 
>     f"{ table[\"foo\"] }"
> 
>> - look for single {, then scan ahead to a matching } -- this skips
> matching () [] {}
> 
> I assume this part of the algorithm uses the lexer and scans for
> matching tokens rather than just scanning for characters? I tried
> looking at the PEP to double check but couldn't find the relevant part.
> It's important for things like
> 
>      f"{ '}' }"

Actually, my current implementation doesn't use the lexer, although I
suppose it could. I'm currently manually scanning the string, keeping
track of strings and parens. To find the end of an expression, it looks
for a '!', ':', or non-doubled '}', not inside of a string or (), [], or
{}. There's a special case for '!=' so the bang isn't seen as ending the
expression.

So it does work on this f-string:

>>> f"{ '}' }"
'}'

Although by using the lexer, I'd be worried about multiple levels of
escaping. I'd have to give it some thought.


>> - look for optional !a,!r,!s and !<spec> inside each {...} pair
>> - take what's left, enclose it in (), parse as expression
> 
> In fact maybe this whole list that Guido wrote should be copied into the
> PEP; it's a good summary :-).

I think the PEP does say these things, but maybe it could be tightened up.

Eric.


From tjreedy at udel.edu  Sat Sep  5 19:52:37 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 5 Sep 2015 13:52:37 -0400
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
Message-ID: <msfa5n$p65$1@ger.gmane.org>

On 9/5/2015 12:18 PM, Guido van Rossum wrote:
> On Sat, Sep 5, 2015 at 2:10 AM, haypo s <victor.stinner at gmail.com
> <mailto:victor.stinner at gmail.com>> wrote:

> We already went over this. You might as well argue that __import__ or
> lambda should not be used as arguments to print(). It's an expression,
> and it must allow exactly everything that is allowed in other places
> where expressions are allowed.

>     (is it possible to indent and comment code inside a f-string?)

I cannot think of any expression where indents on continuation lines 
have any significance other than being extra whitespace.  Comments are 
allowed, but cannot cause line continuation by ending with \.

>>> (1 + #\
... 2)
3
>>> 1 + #\
   File "<stdin>", line 1
     1 + #\
          ^
SyntaxError: invalid syntax

> Now that's an interesting question. I think the answer must be No,

This is a restriction on 'exactly everything'.  The doc should then say 
'any expression without embedded comments' (plus the usual restriction 
on not having embedded strings using the same quotes as the string itself).

> because we don't want to deal with ambiguities like whether a closing
> curly bracket or string quote should be ignored inside such comments.
> The processing of f-strings described by the PEP uses several phases:
>
> - find the end of the string (the final quote[s]) using the same
> algorithm used for all string literals
> - expand \ escapes (e.g. \uXXXX)
> - look for single {, then scan ahead to a matching } -- this skips
> matching () [] {}
> - look for optional !a,!r,!s and !<spec> inside each {...} pair
> - take what's left, enclose it in (), parse as expression
>
> The presence of comments would impede several of these stages.

-- 
Terry Jan Reedy


From Nikolaus at rath.org  Sat Sep  5 19:54:20 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Sat, 05 Sep 2015 10:54:20 -0700
Subject: [Python-Dev] PEP 501 Shell Command Examples
In-Reply-To: <CADiSq7esTLW51BY5if9OdgyQ3zp-kLpx-4uZAdpRUUV=9-GzoA@mail.gmail.com>
 (Nick Coghlan's message of "Sat, 5 Sep 2015 21:59:48 +1000")
References: <87613py4l4.fsf@vostro.rath.org>
 <CADiSq7esTLW51BY5if9OdgyQ3zp-kLpx-4uZAdpRUUV=9-GzoA@mail.gmail.com>
Message-ID: <87vbbosqer.fsf@vostro.rath.org>

On Sep 05 2015, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 5 September 2015 at 12:36, Nikolaus Rath <Nikolaus at rath.org> wrote:
>> Hi Nick,
>>
>> You are giving
>>
>>   runcommand(sh(i"cat {filename}"))
>>
>> as an example that avoids injection attacks. While this is true, I think
>> this is still a terrible anti-pattern[1] that should not be entombed in
>> a PEP as a positive example.
>>
>> Could you consider removing it?
>>
>> (It doubly wastes resources by pointlessly calling a shell, and then by
>> parsing & quoting the argument only for the shell to do the same in
>> reverse).
>
> Any reasonable implementation of that pattern wouldn't actually call a
> system shell, it would invoke something like Julia's command system.

That's obvious to someone like you who thinks about this in terms of the
best implementation.

To someone less experienced, or just coming at from a different angle,
this example just says "writing a shell command is a good way to start
an external program, as long as I take care of quoting".


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From yselivanov.ml at gmail.com  Sat Sep  5 20:05:52 2015
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Sat, 5 Sep 2015 14:05:52 -0400
Subject: [Python-Dev] What's New editing
In-Reply-To: <CAEbHw4Y42n5ugU-aO9jcdvRje6DA6SeK-LSOWoFQGCSOKefnBA@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
 <55E7AA86.7020504@gmail.com>
 <CAEbHw4Y42n5ugU-aO9jcdvRje6DA6SeK-LSOWoFQGCSOKefnBA@mail.gmail.com>
Message-ID: <55EB2F00.4080703@gmail.com>

On 2015-09-05 1:27 PM, David Mertz wrote:
> I have to apologize profusely here.  Just after I offered to do this 
> (and work even said it was OK in principle to do it on work time), my 
> work load went through the roof.  And now it's really already later 
> than most of it should have been done.  I'd still very much like to 
> work on this, but I wonder if maybe someone else would like to be 
> co-author since the increased workload doesn't actually seem likely to 
> diminish soon.

I can recommend someone -- my colleague Elvis Pranskevichus.

Elvis is a highly experienced Python developer with deep experience in 
networks programming, databases, compilers etc.  He also has very good 
editing skills, and helped me to better shape PEP 492 (Rationale and 
Abstract sections were written by him).

He isn't a core developer but I can review and commit his patches, as 
well as assist him with other matters, like checking the NEWS file and 
ensuring proper versionadded/changed tags in out documentation.  We can 
spend 60-70 hours on this task.

Yury


From eric at trueblade.com  Sat Sep  5 20:16:29 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Sat, 5 Sep 2015 14:16:29 -0400
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <CAO-CpELpC79b+iC8psyrNt2jGC0dZwvxMWFFvaCD=HhfZQri3g@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwa4zSX1MKdD4EpjmfpnHBf-H4K3BzMUtgnYjUucNHb1jg@mail.gmail.com>
 <CAP7+vJ+mZ4txoi4f1v5gReJzzf2P512B=HGxo02Z8yDXwpXueQ@mail.gmail.com>
 <CAO-CpELpC79b+iC8psyrNt2jGC0dZwvxMWFFvaCD=HhfZQri3g@mail.gmail.com>
Message-ID: <55EB317D.8010609@trueblade.com>

On 9/5/2015 1:14 PM, Gustavo Carneiro wrote:
> Why not allow string concatenation without plus sign only if/when the
> implementation becomes optimised to allow compile time concatenation? 
> This makes it crystal clear whether the concatenation is compile time or
> runtime. If we allow it now, it's hard to tell without looking at the
> CPython source code...

Although you can make it faster than '+', it's not possible for it to be
a compile-time concatenation. The PEP calls out that it's an expression
that's evaluated at runtime.

I think having strings concatenated with adjacent f-strings follows the
principle of least surprise. I also think it won't get used all that
often, just as compile-time string concatenation isn't seen with great
frequency.

Eric.

From gvanrossum at gmail.com  Sat Sep  5 20:23:15 2015
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Sat, 5 Sep 2015 11:23:15 -0700
Subject: [Python-Dev] What's New editing
In-Reply-To: <55EB2F00.4080703@gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
 <55E7AA86.7020504@gmail.com>
 <CAEbHw4Y42n5ugU-aO9jcdvRje6DA6SeK-LSOWoFQGCSOKefnBA@mail.gmail.com>
 <55EB2F00.4080703@gmail.com>
Message-ID: <CAP7+vJJuQvcU1jhpOWk39gkWD=6NperXedN-ebNT8pX566z5YQ@mail.gmail.com>

Awesome! We need more people with those skills!

--Guido (on mobile)
On Sep 5, 2015 11:07 AM, "Yury Selivanov" <yselivanov.ml at gmail.com> wrote:

> On 2015-09-05 1:27 PM, David Mertz wrote:
>
>> I have to apologize profusely here.  Just after I offered to do this (and
>> work even said it was OK in principle to do it on work time), my work load
>> went through the roof.  And now it's really already later than most of it
>> should have been done.  I'd still very much like to work on this, but I
>> wonder if maybe someone else would like to be co-author since the increased
>> workload doesn't actually seem likely to diminish soon.
>>
>
> I can recommend someone -- my colleague Elvis Pranskevichus.
>
> Elvis is a highly experienced Python developer with deep experience in
> networks programming, databases, compilers etc.  He also has very good
> editing skills, and helped me to better shape PEP 492 (Rationale and
> Abstract sections were written by him).
>
> He isn't a core developer but I can review and commit his patches, as well
> as assist him with other matters, like checking the NEWS file and ensuring
> proper versionadded/changed tags in out documentation.  We can spend 60-70
> hours on this task.
>
> Yury
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/f9dc9587/attachment.html>

From eric at trueblade.com  Sat Sep  5 20:31:21 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Sat, 5 Sep 2015 14:31:21 -0400
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <55EB28CB.1020209@trueblade.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
 <CAPJVwB=6qiirhM1-dC9oO9yKERXWfLeEO=yjd1xExxtFtd4KBA@mail.gmail.com>
 <55EB28CB.1020209@trueblade.com>
Message-ID: <55EB34F9.9000702@trueblade.com>

> Actually, my current implementation doesn't use the lexer, although I
> suppose it could. I'm currently manually scanning the string, keeping
> track of strings and parens. To find the end of an expression, it looks
> for a '!', ':', or non-doubled '}', not inside of a string or (), [], or
> {}. There's a special case for '!=' so the bang isn't seen as ending the
> expression.

Ignore the part about non-doubled '}'. The actual description is:

To find the end of an expression, it looks for a '!', ':', or '}', not
inside of a string or (), [], or {}. There's a special case for '!=' so
the bang isn't seen as ending the expression.

Eric.


From njs at pobox.com  Sat Sep  5 21:23:49 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Sat, 5 Sep 2015 12:23:49 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <55EB34F9.9000702@trueblade.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
 <CAPJVwB=6qiirhM1-dC9oO9yKERXWfLeEO=yjd1xExxtFtd4KBA@mail.gmail.com>
 <55EB28CB.1020209@trueblade.com> <55EB34F9.9000702@trueblade.com>
Message-ID: <CAPJVwBkWrDDfZ_-di_xxNCZLDDH4LF0-QR7nA5K6yk9KC-wKPQ@mail.gmail.com>

On Sep 5, 2015 11:32 AM, "Eric V. Smith" <eric at trueblade.com> wrote:
>
> > Actually, my current implementation doesn't use the lexer, although I
> > suppose it could. I'm currently manually scanning the string, keeping
> > track of strings and parens. To find the end of an expression, it looks
> > for a '!', ':', or non-doubled '}', not inside of a string or (), [], or
> > {}. There's a special case for '!=' so the bang isn't seen as ending the
> > expression.
>
> Ignore the part about non-doubled '}'. The actual description is:
>
> To find the end of an expression, it looks for a '!', ':', or '}', not
> inside of a string or (), [], or {}. There's a special case for '!=' so
> the bang isn't seen as ending the expression.

Sounds like you're reimplementing a lot of the lexer... I guess that's
doable, but how confident are you that your definition of "inside a string"
matches the original in all corner cases?

In any case the abstract language definition part should be phrased in
terms of the python lexer -- the expression ends when you encounter the
first } *token* that is not nested inside () [] {} *tokens*, and then you
can implement it however makes sense...

(This is then the same rule that patsy uses to find the end of python
expressions embedded inside patsy formula strings: patsy.readthedocs.org)

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/be8a70a1/attachment.html>

From jimjjewett at gmail.com  Sat Sep  5 21:57:20 2015
From: jimjjewett at gmail.com (Jim J. Jewett)
Date: Sat, 5 Sep 2015 15:57:20 -0400
Subject: [Python-Dev] PEPs and PEP 8 changes
Message-ID: <CA+OGgf4XKww+b-z5ZwuoGe3EZkEtJe7PVVw18Q3haZPVRyJ_3Q@mail.gmail.com>

PEP 498 is only the latest PEP where part of the concern is fear that
it may encourage certain types of bad code.

Would it be reasonable to ask PEPs to start including a section on any
recommended changes to PEP8?  (e.g., "If an embedded expression
doesn't fit on a single line, factor it out to a named variable.")

I realize that there will be times when best practices (or common
mistakes) aren't obvious in advance, but I'm a bit uncomfortable with
"PEP 8 will probably grow advice"... if we expect to need such advice,
then we should probably include it from the start.  (PEP 8 is, after
all, only advice.)

-jJ

From eric at trueblade.com  Sat Sep  5 22:00:06 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Sat, 5 Sep 2015 16:00:06 -0400
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <CAPJVwBkWrDDfZ_-di_xxNCZLDDH4LF0-QR7nA5K6yk9KC-wKPQ@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
 <CAPJVwB=6qiirhM1-dC9oO9yKERXWfLeEO=yjd1xExxtFtd4KBA@mail.gmail.com>
 <55EB28CB.1020209@trueblade.com> <55EB34F9.9000702@trueblade.com>
 <CAPJVwBkWrDDfZ_-di_xxNCZLDDH4LF0-QR7nA5K6yk9KC-wKPQ@mail.gmail.com>
Message-ID: <55EB49C6.6010206@trueblade.com>

On 9/5/2015 3:23 PM, Nathaniel Smith wrote:
> On Sep 5, 2015 11:32 AM, "Eric V. Smith" <eric at trueblade.com
> <mailto:eric at trueblade.com>> wrote:
>> Ignore the part about non-doubled '}'. The actual description is:
>>
>> To find the end of an expression, it looks for a '!', ':', or '}', not
>> inside of a string or (), [], or {}. There's a special case for '!=' so
>> the bang isn't seen as ending the expression.
> 
> Sounds like you're reimplementing a lot of the lexer... I guess that's
> doable, but how confident are you that your definition of "inside a
> string" matches the original in all corner cases?

Well, this is 35 lines of code (including comments), and it's much
simpler than a lexer (in the sense of "something that generates
tokens"). So I don't think I'm reimplementing a lot of the lexer.

However, your point is valid: if I don't do the same thing the lexer
would do, I could either prematurely find the end of an expression, or
look too far. In either case, when I call ast.parse() I'll get a syntax
error, and/or I'll get an error when parsing/lexing the remainder of the
string.

But it's not like I have to agree with the lexer: no larger error will
occur if I get it wrong. Everything is confined to a single f-string,
since I've already used the lexer to find the f-string in its entirety.
I only need to make sure the users understand how expressions are
extracted from f-strings.

I did look at using the actual lexer (Parser/tokenizer.c) to do this,
but it would require a large amount of surgery. I think it's overkill
for this task.

So far, I've tested it enough to have reasonable confidence that it's
correct. But the implementation could always be swapped out for an
improved version. I'm certainly open to that, if we find cases that the
simple scanner can't deal with.

> In any case the abstract language definition part should be phrased in
> terms of the python lexer -- the expression ends when you encounter the
> first } *token* that is not nested inside () [] {} *tokens*, and then
> you can implement it however makes sense...

I'm not sure that's an improvement on Guido's description when you're
trying to explain it to a user. But when time comes to write the
documentation, we can discuss it then.

> (This is then the same rule that patsy uses to find the end of python
> expressions embedded inside patsy formula strings: patsy.readthedocs.org
> <http://patsy.readthedocs.org>)

I don't see where patsy looks for expressions in parts of strings. Let
me know if I'm missing it.

Eric.

From eric at trueblade.com  Sat Sep  5 22:43:52 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Sat, 5 Sep 2015 16:43:52 -0400
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
Message-ID: <55EB5408.2050703@trueblade.com>

On 9/5/2015 12:18 PM, Guido van Rossum wrote:
> On Sat, Sep 5, 2015 at 2:10 AM, haypo s <victor.stinner at gmail.com
> <mailto:victor.stinner at gmail.com>> wrote:
>
>     (is it possible to indent and comment code inside a f-string?)
> 
> 
> Now that's an interesting question. I think the answer must be No,
> because we don't want to deal with ambiguities like whether a closing
> curly bracket or string quote should be ignored inside such comments.
> The processing of f-strings described by the PEP uses several phases:

I'll update the PEP to say comments aren't allowed. It gets especially
wacky when adding () around the expression: f'{2#}' would become the
expression "(2#)", which is a syntax error.

Eric.

From yselivanov.ml at gmail.com  Sat Sep  5 23:22:03 2015
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Sat, 5 Sep 2015 17:22:03 -0400
Subject: [Python-Dev] What's New editing
In-Reply-To: <CAP7+vJJuQvcU1jhpOWk39gkWD=6NperXedN-ebNT8pX566z5YQ@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
 <55E7AA86.7020504@gmail.com>
 <CAEbHw4Y42n5ugU-aO9jcdvRje6DA6SeK-LSOWoFQGCSOKefnBA@mail.gmail.com>
 <55EB2F00.4080703@gmail.com>
 <CAP7+vJJuQvcU1jhpOWk39gkWD=6NperXedN-ebNT8pX566z5YQ@mail.gmail.com>
Message-ID: <55EB5CFB.1030300@gmail.com>


On 2015-09-05 2:23 PM, Guido van Rossum wrote:
>
> Awesome! We need more people with those skills!
>
> --Guido (on mobile)
>

Great, we'll start today!

Thanks,
Yury


From victor.stinner at gmail.com  Sat Sep  5 23:22:38 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sat, 5 Sep 2015 23:22:38 +0200
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
Message-ID: <CAMpsgwaa=_rY=sjn0ChZt=DE9mNymjVQnSnr=+KFD+XATWK7sw@mail.gmail.com>

> If you really want to allow *any* Python inside a f-string, can you
>> please at least explain in the PEP why you consider that it's a good
>> thing?
>>
>
> Sigh. We've gone over this on python-ideas. Your objection is not new.
>

I'm sure that later others will have exactly the same question than me.
Is''t the purpose of the PEP to summarize a discussion to not have to
repeat it again and again?

Please, can anyone summerize the discussion (on allowing or not complex
expressions in f-string) into a short paragraph in the PEP?

I don't follow python-ideas and I don't want to subscribe.

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/2d4b2816/attachment.html>

From guido at python.org  Sun Sep  6 00:10:34 2015
From: guido at python.org (Guido van Rossum)
Date: Sat, 5 Sep 2015 15:10:34 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAMpsgwaa=_rY=sjn0ChZt=DE9mNymjVQnSnr=+KFD+XATWK7sw@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
 <CAMpsgwaa=_rY=sjn0ChZt=DE9mNymjVQnSnr=+KFD+XATWK7sw@mail.gmail.com>
Message-ID: <CAP7+vJJ__9b6AFxvg8DWWJVdneVVFgL-WmsDpean8A20JKEpQQ@mail.gmail.com>

On Sat, Sep 5, 2015 at 2:22 PM, Victor Stinner <victor.stinner at gmail.com>
wrote:

>
> If you really want to allow *any* Python inside a f-string, can you
>>> please at least explain in the PEP why you consider that it's a good
>>> thing?
>>>
>>
>> Sigh. We've gone over this on python-ideas. Your objection is not new.
>>
>
> I'm sure that later others will have exactly the same question than me.
> Is''t the purpose of the PEP to summarize a discussion to not have to
> repeat it again and again?
>
> Please, can anyone summerize the discussion (on allowing or not complex
> expressions in f-string) into a short paragraph in the PEP?
>
> I don't follow python-ideas and I don't want to subscribe.
>

But you can at least read the PEP. There is a whole section "Supporting
full Python expressions" which explains this.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/823e3876/attachment-0001.html>

From njs at pobox.com  Sun Sep  6 01:12:02 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Sat, 5 Sep 2015 16:12:02 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <55EB49C6.6010206@trueblade.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
 <CAPJVwB=6qiirhM1-dC9oO9yKERXWfLeEO=yjd1xExxtFtd4KBA@mail.gmail.com>
 <55EB28CB.1020209@trueblade.com> <55EB34F9.9000702@trueblade.com>
 <CAPJVwBkWrDDfZ_-di_xxNCZLDDH4LF0-QR7nA5K6yk9KC-wKPQ@mail.gmail.com>
 <55EB49C6.6010206@trueblade.com>
Message-ID: <CAPJVwBnm91sQArebT5kqrt5_yCM-b-pqCg0SEDaaB_KHrNHFbQ@mail.gmail.com>

On Sat, Sep 5, 2015 at 1:00 PM, Eric V. Smith <eric at trueblade.com> wrote:
> On 9/5/2015 3:23 PM, Nathaniel Smith wrote:
>> On Sep 5, 2015 11:32 AM, "Eric V. Smith" <eric at trueblade.com
>> <mailto:eric at trueblade.com>> wrote:
>>> Ignore the part about non-doubled '}'. The actual description is:
>>>
>>> To find the end of an expression, it looks for a '!', ':', or '}', not
>>> inside of a string or (), [], or {}. There's a special case for '!=' so
>>> the bang isn't seen as ending the expression.
>>
>> Sounds like you're reimplementing a lot of the lexer... I guess that's
>> doable, but how confident are you that your definition of "inside a
>> string" matches the original in all corner cases?
>
> Well, this is 35 lines of code (including comments), and it's much
> simpler than a lexer (in the sense of "something that generates
> tokens"). So I don't think I'm reimplementing a lot of the lexer.
>
> However, your point is valid: if I don't do the same thing the lexer
> would do, I could either prematurely find the end of an expression, or
> look too far. In either case, when I call ast.parse() I'll get a syntax
> error, and/or I'll get an error when parsing/lexing the remainder of the
> string.
>
> But it's not like I have to agree with the lexer: no larger error will
> occur if I get it wrong. Everything is confined to a single f-string,
> since I've already used the lexer to find the f-string in its entirety.
> I only need to make sure the users understand how expressions are
> extracted from f-strings.
>
> I did look at using the actual lexer (Parser/tokenizer.c) to do this,
> but it would require a large amount of surgery. I think it's overkill
> for this task.
>
> So far, I've tested it enough to have reasonable confidence that it's
> correct. But the implementation could always be swapped out for an
> improved version. I'm certainly open to that, if we find cases that the
> simple scanner can't deal with.
>
>> In any case the abstract language definition part should be phrased in
>> terms of the python lexer -- the expression ends when you encounter the
>> first } *token* that is not nested inside () [] {} *tokens*, and then
>> you can implement it however makes sense...
>
> I'm not sure that's an improvement on Guido's description when you're
> trying to explain it to a user. But when time comes to write the
> documentation, we can discuss it then.

I'm not talking about end-user documentation, I'm talking about the
formal specification, like in the Python Language Reference.

I'm pretty sure that just calling the tokenizer will be easier for
Cython or PyPy than implementing a special purpose scanner :-)

>> (This is then the same rule that patsy uses to find the end of python
>> expressions embedded inside patsy formula strings: patsy.readthedocs.org
>> <http://patsy.readthedocs.org>)
>
> I don't see where patsy looks for expressions in parts of strings. Let
> me know if I'm missing it.

Patsy parses strings like

   "np.sin(a + b) + c"

using a grammar that supports some basic arithmetic-like infix
operations (+, *, parentheses, etc.), and in which the atoms are
arbitrary Python expressions. So the above string is parsed into a
patsy-AST that looks something like:

  Add(PyExpr("np.sin(a + b)"), PyExpr("c"))

The rule it uses to do this is that it uses the Python tokenizer,
counts nesting of () [] {}, and when it sees a valid unnested patsy
operator, then that's the end of the embedded expression:

  https://github.com/pydata/patsy/blob/master/patsy/parse_formula.py#L37

Not tremendously relevant, but that's why I've thought this through before :-)

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

From brett at python.org  Sun Sep  6 02:42:19 2015
From: brett at python.org (Brett Cannon)
Date: Sun, 06 Sep 2015 00:42:19 +0000
Subject: [Python-Dev] PEPs and PEP 8 changes
In-Reply-To: <CA+OGgf4XKww+b-z5ZwuoGe3EZkEtJe7PVVw18Q3haZPVRyJ_3Q@mail.gmail.com>
References: <CA+OGgf4XKww+b-z5ZwuoGe3EZkEtJe7PVVw18Q3haZPVRyJ_3Q@mail.gmail.com>
Message-ID: <CAP1=2W5ApdmVojfVXW1RiD8qyethkMcAT_VQrFAvs7chETVX8g@mail.gmail.com>

On Sat, 5 Sep 2015 at 12:58 Jim J. Jewett <jimjjewett at gmail.com> wrote:

> PEP 498 is only the latest PEP where part of the concern is fear that
> it may encourage certain types of bad code.
>
> Would it be reasonable to ask PEPs to start including a section on any
> recommended changes to PEP8?  (e.g., "If an embedded expression
> doesn't fit on a single line, factor it out to a named variable.")
>
> I realize that there will be times when best practices (or common
> mistakes) aren't obvious in advance, but I'm a bit uncomfortable with
> "PEP 8 will probably grow advice"... if we expect to need such advice,
> then we should probably include it from the start.  (PEP 8 is, after
> all, only advice.)
>

I have no issue suggesting it, but I don't think it needs to be a rule
either.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150906/ba637978/attachment.html>

From eric at trueblade.com  Sun Sep  6 02:45:07 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Sat, 5 Sep 2015 20:45:07 -0400
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <CAPJVwBnm91sQArebT5kqrt5_yCM-b-pqCg0SEDaaB_KHrNHFbQ@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAP7+vJJGN1K1B2dpkZn6PbbsY7sf9P6kzuEtHnXoanUK8r-_UA@mail.gmail.com>
 <CAPJVwB=6qiirhM1-dC9oO9yKERXWfLeEO=yjd1xExxtFtd4KBA@mail.gmail.com>
 <55EB28CB.1020209@trueblade.com> <55EB34F9.9000702@trueblade.com>
 <CAPJVwBkWrDDfZ_-di_xxNCZLDDH4LF0-QR7nA5K6yk9KC-wKPQ@mail.gmail.com>
 <55EB49C6.6010206@trueblade.com>
 <CAPJVwBnm91sQArebT5kqrt5_yCM-b-pqCg0SEDaaB_KHrNHFbQ@mail.gmail.com>
Message-ID: <55EB8C93.8080305@trueblade.com>

On 9/5/2015 7:12 PM, Nathaniel Smith wrote:
> On Sat, Sep 5, 2015 at 1:00 PM, Eric V. Smith <eric at trueblade.com> wrote:
>> On 9/5/2015 3:23 PM, Nathaniel Smith wrote:
>>> On Sep 5, 2015 11:32 AM, "Eric V. Smith" <eric at trueblade.com
>>> <mailto:eric at trueblade.com>> wrote:
>>>> Ignore the part about non-doubled '}'. The actual description is:
>>>>
>>>> To find the end of an expression, it looks for a '!', ':', or '}', not
>>>> inside of a string or (), [], or {}. There's a special case for '!=' so
>>>> the bang isn't seen as ending the expression.
>>>
>>> Sounds like you're reimplementing a lot of the lexer... I guess that's
>>> doable, but how confident are you that your definition of "inside a
>>> string" matches the original in all corner cases?
>>
>> Well, this is 35 lines of code (including comments), and it's much
>> simpler than a lexer (in the sense of "something that generates
>> tokens"). So I don't think I'm reimplementing a lot of the lexer.
>>
>> However, your point is valid: if I don't do the same thing the lexer
>> would do, I could either prematurely find the end of an expression, or
>> look too far. In either case, when I call ast.parse() I'll get a syntax
>> error, and/or I'll get an error when parsing/lexing the remainder of the
>> string.
>>
>> But it's not like I have to agree with the lexer: no larger error will
>> occur if I get it wrong. Everything is confined to a single f-string,
>> since I've already used the lexer to find the f-string in its entirety.
>> I only need to make sure the users understand how expressions are
>> extracted from f-strings.
>>
>> I did look at using the actual lexer (Parser/tokenizer.c) to do this,
>> but it would require a large amount of surgery. I think it's overkill
>> for this task.
>>
>> So far, I've tested it enough to have reasonable confidence that it's
>> correct. But the implementation could always be swapped out for an
>> improved version. I'm certainly open to that, if we find cases that the
>> simple scanner can't deal with.
>>
>>> In any case the abstract language definition part should be phrased in
>>> terms of the python lexer -- the expression ends when you encounter the
>>> first } *token* that is not nested inside () [] {} *tokens*, and then
>>> you can implement it however makes sense...
>>
>> I'm not sure that's an improvement on Guido's description when you're
>> trying to explain it to a user. But when time comes to write the
>> documentation, we can discuss it then.
> 
> I'm not talking about end-user documentation, I'm talking about the
> formal specification, like in the Python Language Reference.

I think the formal specification can talk about scanning a string
looking for the end of an expression without discussing tokens. Just as
https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals
uses an EBNF sort of language.

The implementation is not tokenizing anything: it's just trying to find
the end of the string in order to pass it to ast.parse(). That task is
significantly easier than tokenizing.

> I'm pretty sure that just calling the tokenizer will be easier for
> Cython or PyPy than implementing a special purpose scanner :-)

I sincerely doubt that, but I'd be curious how they implemented
_string.formatter_parser(), which is extremely close in functionality.
Sadly, just not close enough to be reusable for this.

But I'm not going to argue about implementation when the PEP hasn't been
accepted yet. Especially for code I'm not going to write in Cython and PyPy!

>>> (This is then the same rule that patsy uses to find the end of python
>>> expressions embedded inside patsy formula strings: patsy.readthedocs.org
>>> <http://patsy.readthedocs.org>)
>>
>> I don't see where patsy looks for expressions in parts of strings. Let
>> me know if I'm missing it.
> 
> Patsy parses strings like
> 
>    "np.sin(a + b) + c"
> 
> using a grammar that supports some basic arithmetic-like infix
> operations (+, *, parentheses, etc.), and in which the atoms are
> arbitrary Python expressions. So the above string is parsed into a
> patsy-AST that looks something like:
> 
>   Add(PyExpr("np.sin(a + b)"), PyExpr("c"))
> 
> The rule it uses to do this is that it uses the Python tokenizer,
> counts nesting of () [] {}, and when it sees a valid unnested patsy
> operator, then that's the end of the embedded expression:
> 
>   https://github.com/pydata/patsy/blob/master/patsy/parse_formula.py#L37
> 
> Not tremendously relevant, but that's why I've thought this through before :-)

For the actual parsing of the expressions, I use the equivalent of
ast.parse(). So that phase of the processing I'm not worried about.

Eric.


From barry at python.org  Sun Sep  6 04:58:55 2015
From: barry at python.org (Barry Warsaw)
Date: Sat, 5 Sep 2015 22:58:55 -0400
Subject: [Python-Dev] PEPs and PEP 8 changes
In-Reply-To: <CA+OGgf4XKww+b-z5ZwuoGe3EZkEtJe7PVVw18Q3haZPVRyJ_3Q@mail.gmail.com>
References: <CA+OGgf4XKww+b-z5ZwuoGe3EZkEtJe7PVVw18Q3haZPVRyJ_3Q@mail.gmail.com>
Message-ID: <20150905225855.4d63447a@anarchist.wooz.org>

On Sep 05, 2015, at 03:57 PM, Jim J. Jewett wrote:

>Would it be reasonable to ask PEPs to start including a section on any
>recommended changes to PEP8?  (e.g., "If an embedded expression
>doesn't fit on a single line, factor it out to a named variable.")

Yes, I think it's reasonable to encourage a "best practices" section in
relevant PEPs.  Those best practices can include recommendations for updates
to PEP 8.

>I realize that there will be times when best practices (or common mistakes)
>aren't obvious in advance, but I'm a bit uncomfortable with "PEP 8 will
>probably grow advice"... if we expect to need such advice, then we should
>probably include it from the start.  (PEP 8 is, after all, only advice.)

Except of course that for some projects, it's more than that.  The pep8 (and
related) tools are often used in test suites to force style compliance within
a project.  That's fine except that, to paraphrase Dr. Strangelove, the whole
point of such tests is lost if you don't run those tests!  I've actually had
to fix several packages recently whose pep8 tests fail.

I'm often reluctant to lock PEP 8 down too much because it can sometimes be a
straight jacket.

Cheers,
-Barry

From barry at python.org  Sun Sep  6 05:11:00 2015
From: barry at python.org (Barry Warsaw)
Date: Sat, 5 Sep 2015 23:11:00 -0400
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
Message-ID: <20150905231100.1f664d6f@anarchist.wooz.org>

On Sep 04, 2015, at 08:01 PM, Guido van Rossum wrote:

>And I'm ready to accept it.

As I've mentioned to Eric, I think it's a great PEP, so congratulations on
getting one through The Gauntlet.  I know that in my own code, I'm looking
forward to using it in however many years it takes for 3.6 to be the base
compatible version of course. :)

I'm okay with it not being appropriate for i18n (IMHO) but no worries,
string.Template and libraries like mine built on top of it all do the trick
nicely and are quite stable.  No reason for them to go away, and PEP 498 is
orthogonal to that.

Still, I read *a lot* of Python code written by other people.  Most of it is
really good (it's nice that there are so many excellent Python developers out
there :).  I also know that the syntax is going to be abused and I rather
dread having to read, comprehend, and debug it.  But oh well.

In another thread it was suggested that a PEP 8 -type of best practices be
included in new PEPs.  I definitely think that any documentation written for
f-strings should include such best practices.  Maybe PEP 8 should also include
some style suggestions or admonitions for f-strings, but I'll let others
propose language for that.

Cheers,
-Barry

From srkunze at mail.de  Sun Sep  6 11:44:45 2015
From: srkunze at mail.de (Sven R. Kunze)
Date: Sun, 6 Sep 2015 11:44:45 +0200
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <CAPTjJmqo=+CnLTweZvnq4bm=Cym9o9CzyKNm-kjo3W=wcSu==w@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <CAMpsgwYfEZ2U34-mA4WacBsj+wXVTNQRg+dBJnLi0KW9rM-K2Q@mail.gmail.com>
 <CAPTjJmq9VRLfE0W3Ygk4tuF=QXoX6WP7DFZZfo4A1DNqcNx=xA@mail.gmail.com>
 <CAPTjJmqo=+CnLTweZvnq4bm=Cym9o9CzyKNm-kjo3W=wcSu==w@mail.gmail.com>
Message-ID: <55EC0B0D.8050500@mail.de>

On 05.09.2015 12:58, Chris Angelico wrote:
> On Sat, Sep 5, 2015 at 8:57 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>> IMHO the main advantage of allowing expressions inside f-string is
>>> that it adds something really new compared to the current str.format()
>>> method. Without it, f-string are less interesting.
>> I agree with your conclusion paragraph,
>> and feel that they *are* interesting and useful in their
>> currently-described state.
> By the way, I've been using this PEP to drum up some excitement about
> Python 3. Still trying to get some people to make the jump from 2.7,
> but if this lands, it'll be cool and interesting and fun, and maybe
> some more weight on the Py3 side of the scale :)

Do you really think that matters?

From trent at snakebite.org  Sun Sep  6 17:19:54 2015
From: trent at snakebite.org (Trent Nelson)
Date: Sun, 6 Sep 2015 11:19:54 -0400
Subject: [Python-Dev] PyParallel update
Message-ID: <20150906151954.GB1069@trent.me>

[CC'ing python-dev@ for those that are curious; please drop and keep
follow-up discussion to python-ideas@]

Hi folks,

I've made a lot of progress on PyParallel since the PyCon dev summit
(https://speakerdeck.com/trent/pyparallel-pycon-2015-language-summit); I
fixed the outstanding breakage with generators, exceptions and whatnot.
I got the "instantaneous Wiki search server" working[1] and implemented
the entire TechEmpower Frameworks Benchmark Suite[2], including a
PyParallel-friendly pyodbc module, allowing database connections and
querying in parallel.

[1]:
https://github.com/pyparallel/pyparallel/blob/branches/3.3-px/examples/wiki/wiki.py
[2]:
https://github.com/pyparallel/pyparallel/blob/branches/3.3-px/examples/tefb/tefb.py

I set up a landing page for the project:

    http://pyparallel.org

And there was some good discussion on reddit earlier this week:

    https://www.reddit.com/r/programming/comments/3jhv80/pyparallel_an_experimental_proofofconcept_fork_of/

I've put together some documentation on the project, its aims, and
the key parts of the solution regarding the parallelism through
simple client/server paradigms.  This documentation is available
directly on the github landing page for the project:

    https://github.com/pyparallel/pyparallel

Writing that documentation forced me to formalize (or at least commit)
to the restrictions/trade-offs that PyParallel would introduce, and I'm
pretty happy I was basically able to boil it down into a single rule:

    Don't persist parallel objects.

That keeps the mental model very simple.  You don't need to worry about
locking or ownership or races or anything like that.  Just don't persist
parallel objects, that's the only thing you have to remember.

It's actually really easy to convert existing C code or Python code into
something that is suitable for calling from within a parallel callback by
just ensuring that rule isn't violated.  It took about four hours to figure
out how NumPy allocated stuff and add in the necessary PyParallel-aware
tweaks, and not that much longer for pyodbc.  (Most stuff "just works",
though.)  (The ABI changes would mean this is a Python 4.x type of
thing; there are fancy ways we could avoid ABI changes and get this
working on Python 3.x, but, eh, I like the 4.x target.  It's realistic.)

The other thing that clicked is that asyncio and PyParallel would
actually work really well together for exploiting client-driven
parallelism (PyParallel really is only suited to server-oriented
parallelism at the moment, i.e. serving HTTP requests in parallel).

With asyncio, though, you could keep the main-thread/single-thread
client-drives-computation paradigm, but have it actually dispatch work
to parallel.server() objects behind the scenes.  For example, in order
to process all files in a directory in parallel, asyncio would request a
directory listing (i.e. issue a GET /) which the PyParallel HTTP server
would return, it would then create non-blocking client connections to
the same server and invoke whatever HTTP method is desired to do the
file processing.  You can either choose to write the new results from
within the parallel context (which could then be accessed as normal
files via HTTP), or you could have PyParallel return json/bytes, which
could then be aggregated by asyncio.

Everything is within the same process, so you get all the benefits that
provides (free access to anything within scope, like large data
structures, from within parallel contexts).  You can synchronously call
back into the main thread from a parallel thread, too, if you wanted to
update a complex data structure directly.

The other interesting thing that documentation highlights is the
advantage of the split brain "main thread vs parallel thread" GC and
non-GC allocators.  I'm not sure if I've ever extolled the virtue of
such an approach on paper or in e-mail.  It's pretty neat though and
allows us to avoid a whole raft of problems that need to be solved when
you have a single GC/memory model.

Next steps: once 3.5 is tagged, I'm going to bite the bullet and rebase.
That'll require a bit of churn, so if there's enough interest from
others, I figured we'd use the opportunity to at least get it building
again on POSIX (Linux/OSX/FreeBSD).  From there people can start
implementing the missing bits for implementing the parallel machinery
behind the scenes.

The parallel interpreter thread changes I made are platform agnostic,
the implementation just happens to be on Windows at the moment; don't
let the Windows-only thing detract from what's actually being pitched: a
(working, demonstrably-performant) solution to "Python's GIL problem".

Regards,

    Trent.


From python-ideas at mgmiller.net  Mon Sep  7 21:40:56 2015
From: python-ideas at mgmiller.net (Mike Miller)
Date: Mon, 7 Sep 2015 12:40:56 -0700
Subject: [Python-Dev] Critique of PEP 502 (String Interpolation Redux)
In-Reply-To: <CAP7+vJLhrWYMs__jmoa1Vfwtw-2qd1_p4N1Vf8zvCzChEtdKfA@mail.gmail.com>
References: <CAP7+vJLhrWYMs__jmoa1Vfwtw-2qd1_p4N1Vf8zvCzChEtdKfA@mail.gmail.com>
Message-ID: <55EDE848.7020200@mgmiller.net>

That could be helpful and done without too much work, adding in the best 
practices and PEP8 guidelines that have been asked for in other threads.

Are people interested in a "rationale and best practices" for string 
interpolation pep?

-Mike


On 09/04/2015 08:15 PM, Guido van Rossum wrote:
> The text of the PEP has too much on motivation and rationale: maybe that would
> be suitable for an informative PEP.

From guido at python.org  Mon Sep  7 23:05:48 2015
From: guido at python.org (Guido van Rossum)
Date: Mon, 7 Sep 2015 14:05:48 -0700
Subject: [Python-Dev] Critique of PEP 502 (String Interpolation Redux)
In-Reply-To: <55EDE848.7020200@mgmiller.net>
References: <CAP7+vJLhrWYMs__jmoa1Vfwtw-2qd1_p4N1Vf8zvCzChEtdKfA@mail.gmail.com>
 <55EDE848.7020200@mgmiller.net>
Message-ID: <CAP7+vJ+5rQMQybx63RLEMOqkFtpLnqfYCk1bMwjgBNPcn_dzyA@mail.gmail.com>

I think that would be a better use of your time than continuing to refine
the spec of your competing proposal.

On Mon, Sep 7, 2015 at 12:40 PM, Mike Miller <python-ideas at mgmiller.net>
wrote:

> That could be helpful and done without too much work, adding in the best
> practices and PEP8 guidelines that have been asked for in other threads.
>
> Are people interested in a "rationale and best practices" for string
> interpolation pep?
>
> -Mike
>
>
> On 09/04/2015 08:15 PM, Guido van Rossum wrote:
>
>> The text of the PEP has too much on motivation and rationale: maybe that
>> would
>> be suitable for an informative PEP.
>>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150907/7558cc17/attachment.html>

From larry at hastings.org  Tue Sep  8 03:35:03 2015
From: larry at hastings.org (Larry Hastings)
Date: Mon, 7 Sep 2015 18:35:03 -0700
Subject: [Python-Dev] [RELEASED] Python 3.5.0rc3 is now available
Message-ID: <55EE3B47.7030305@hastings.org>



On behalf of the Python development community and the Python 3.5 release 
team, I'm relieved to announce the availability of Python 3.5.0rc3, also 
known as Python 3.5.0 Release Candidate 3.

The next release of Python 3.5 will be Python 3.5.0 final.  There should 
be few (or no) changes to Python 3.5 between rc3 and final.

This is a preview release, and its use is not recommended for production 
settings.


You can find Python 3.5.0rc3 here:

     https://www.python.org/downloads/release/python-350rc3/

Windows and Mac users: please read the important platform-specific 
"Notes on this release" section near the end of that page.


Happy hacking,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150907/f01910b6/attachment.html>

From alexander.belopolsky at gmail.com  Tue Sep  8 03:57:12 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 7 Sep 2015 21:57:12 -0400
Subject: [Python-Dev] PEP 495: What's left to resolve
Message-ID: <CAP7h-xZcGFmkaY6o1xB60dizC-T63iBOPK89jL1EVoxw-8P5+g@mail.gmail.com>

The good news that other than a few editorial changes there is only one
issue which keeps me from declaring PEP 495 complete.  The bad news is that
the remaining issue is subtle and while several solutions have been
proposed, neither stands out as an obviously right.

The Problem
-----------

PEP 495 requires that the value of the fold attribute is ignored when two
aware datetime objects that share tzinfo are compared.  This is motivated
by the reasons of backward compatibility: we want the value of fold to only
matter in conversions from one zone to another and not in arithmetic within
a single timezone.

As Tim pointed out, this rule is in conflict with the only requirement that
a hash function must satisfy: if two objects compare as equal, their hashes
should be equal as well.

Let t0 and t1 be two times in the fold that differ only by the value of
their fold attribute: t0.fold == 0, t1.fold == 1.  Let u0 =
t0.astimezone(utc) and u1 = t1.astimezone(t1).  PEP 495 requires that u0 <
u1.  (In fact, this is the main purpose of the PEP to disambiguate between
t0 and t1 so that conversion to UTC is well defined.)  However, by the
current PEP 495 rules, t0 == t1 is True, by the pre-PEP rule (and the PEP
rule that fold is ignored in comparisons) we also have t0 == u0 and t1 ==
u1.  So, we have (a) a violation of the transitivity of ==: u0 == t0 == t1
== u1 does not imply u0 == u1 which is bad enough by itself, and (b) since
hash(u0) can be equal to hash(u1) only by a lucky coincidence, the rule
"equality of objects implies equality of hashes" leads to contradiction
because applying it to the chain u0 == t0 == t1 == u1, we get hash(u0) ==
hash(t0) == hash(t1) == hash(u1) which is now a chain of equalities of
integers and on integers == is transitive, so we have hash(u0) == hash(u1)
which as we said can only happen by a lucky coincidence.


The Root of the Problem
-----------------------

The rules of arithmetic on aware datetime objects already cause some basic
mathematical identities to break.  The problem described above is avoided
by not having a way to represent u1 in the timezone where u0 and u1 map to
the same local time.  We still have a surprising u0 < u1, but
u0.astimezone(local) == u1.astimezone(local), but it does not rise to the
level of a hash invariant violation because u0.astimezone(local) and
u1.astimezone(local) are not only equal: they are identical in all other
ways and if we convert them back to UTC - they both convert to u0.

The root of the hash problem is not in the t0 == t1 is True rule.  It is in
u0 == t0.  The later equality is just too fragile: if you add
timedelta(hour=1) to both sides to this equation, then (assuming an
ordinary 1 hour fall-back fold), you will get two datetime objects that are
no longer equal. (Indeed, local to utc equality t == u is defined as t -
t.utcoffset() == u.replace(tzinfo=t.tzinfo), but when you add 1 hour to t0,
utcoffset() changes so the equality that held for t0 and u0 will no longer
hold for t0 + timedelta(hour=1) and u0 + timedelta(hour=1).)

PEP 495 gives us a way to break the u0 == t0 equality by replacing t0 with
an "equal" object t1 and simultaneously have u0 == t0, t0 == t1 and t1 !=
u0.


The Solutions
-------------

Tim suggested several solutions to this problem, but by his own admission
neither is more than "grudgingly acceptable."  For completeness, I will
also present my "non-solution."

Solution 0: Ignore the problem.  Since PEP 495 does not by itself introduce
any tzinfo implementations with variable utcoffset(), it does not create a
hash invariant violation.  I call this a non-solution because it would once
again punt an unsolvable problem to tzinfo implementors.  It is unsolvable
for *them* because without some variant of the rejected PEP 500, they will
have no control over datetime comparisons or hashing.

Solution 1: Make t1 > t0.

Solution 2: Leave t1 == t0, but make t1 != u1.


Request for Comments
--------------------

I will not discuss pros and cons on the two solutions because my goal here
was only to state the problem, identify the root case and indicate the
possible solutions.  Those interested in details can read Tim's excellent
explanations in the "Another round on error-checking" [1] and "Another
approach to 495's glitches" [2] threads.

I "bcc" python-dev in a hope that someone in the expanded forum will either
say "of course solution N is the right one and here is why" or "here is an
obviously right solution - how could  you guys miss it."


[1]:
https://mail.python.org/pipermail/datetime-sig/2015-September/000622.html
[2]:
https://mail.python.org/pipermail/datetime-sig/2015-September/000716.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150907/39e4c5ed/attachment.html>

From kerrick at kerrickstaley.com  Tue Sep  8 04:06:17 2015
From: kerrick at kerrickstaley.com (Kerrick Staley)
Date: Mon, 7 Sep 2015 19:06:17 -0700
Subject: [Python-Dev] Comparison operators (> < >= <=) for
	collections.Counter
Message-ID: <CANaWP3xuf=Gq_9WhWp4=K_SEx-0VDSeUZLAknTVcjCqgyJeLNg@mail.gmail.com>

I noticed that collections.Counter, unlike set, doesn't support the ordered
comparison operators (> < >= <=). I'd like to propose implementing these
operators in an analogous fashion to set: counter1 >= counter2 if counter1
contains at least as many of every key as counter2 does. Cases where
counter1 doesn't have a key and counter2 has a negative amount of that key
would still count as >=. counter1 > counter2 when counter1 >= counter2 and
counter1 != counter2.

Does this sound reasonable? If so I'll write up and submit a patch.

- Kerrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150907/ea2214a8/attachment.html>

From storchaka at gmail.com  Tue Sep  8 04:58:55 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 8 Sep 2015 05:58:55 +0300
Subject: [Python-Dev] Comparison operators (> < >= <=) for
	collections.Counter
In-Reply-To: <CANaWP3xuf=Gq_9WhWp4=K_SEx-0VDSeUZLAknTVcjCqgyJeLNg@mail.gmail.com>
References: <CANaWP3xuf=Gq_9WhWp4=K_SEx-0VDSeUZLAknTVcjCqgyJeLNg@mail.gmail.com>
Message-ID: <mslitf$vj4$1@ger.gmane.org>

On 08.09.15 05:06, Kerrick Staley wrote:
> I noticed that collections.Counter, unlike set, doesn't support the
> ordered comparison operators (> < >= <=). I'd like to propose
> implementing these operators in an analogous fashion to set: counter1 >=
> counter2 if counter1 contains at least as many of every key as counter2
> does. Cases where counter1 doesn't have a key and counter2 has a
> negative amount of that key would still count as >=. counter1 > counter2
> when counter1 >= counter2 and counter1 != counter2.
>
> Does this sound reasonable? If so I'll write up and submit a patch.

This idea already was rejected. http://bugs.python.org/issue22515



From python at mrabarnett.plus.com  Tue Sep  8 05:40:26 2015
From: python at mrabarnett.plus.com (MRAB)
Date: Tue, 8 Sep 2015 04:40:26 +0100
Subject: [Python-Dev] Can't install Python 3.5rc3
Message-ID: <55EE58AA.40108@mrabarnett.plus.com>

I've been unable to install Python 3.5rc3.

It progresses to installing Tcl/tk, then reports that a newer version
of 3.5 is already installed, then it rolls back (slowly).

I don't know where it's finding this "newer version"; I've uninstalled
the previous releases of Python 3.5.

I'm on Windows 10.


Here's the contents of the log file:

[0A40:1CC8][2015-09-08T04:29:45]i001: Burn v3.10.0.1823, Windows v10.0 
(Build 10240: Service Pack 0), path: 
C:\Users\MRAB\Downloads\Python\python-3.5.0rc3.exe
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'ActionLikeInstalling' to value 'Installing'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'ActionLikeInstallation' to value 'Setup'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'ShortVersion' to value '3.5'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'ShortVersionNoDot' to value '35'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'InstallAllUsers' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'InstallLauncherAllUsers' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetDir' to value ''
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'DefaultAllUsersTargetDir' to value '[ProgramFilesFolder]Python 
[ShortVersion]'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetPlatform' to value 'x86'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'DefaultJustForMeTargetDir' to value 
'[LocalAppDataFolder]Programs\Python\Python[ShortVersionNoDot]-32'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'OptionalFeaturesRegistryKey' to value 
'Software\Python\PythonCore\[ShortVersion]-32\InstalledFeatures'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetDirRegistryKey' to value 
'Software\Python\PythonCore\[ShortVersion]-32\InstallPath'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'DefaultCustomTargetDir' to value ''
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'InstallAllUsersState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'InstallLauncherAllUsersState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'CustomInstallLauncherAllUsersState' to value 
'[InstallLauncherAllUsersState]'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetDirState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'CustomBrowseButtonState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_core' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_exe' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_dev' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_lib' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_test' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_doc' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_tools' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_tcltk' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_pip' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_launcher' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_symbols' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_debug' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'LauncherOnly' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'AssociateFiles' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Shortcuts' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'PrependPath' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'CompileAll' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'SimpleInstall' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'SimpleInstallDescription' to value ''
[0A40:1CC8][2015-09-08T04:29:45]i009: Command Line: ''
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'WixBundleLog' to value 'C:\Users\MRAB\AppData\Local\Temp\Python 
3.5.0rc3 (32-bit)_20150908042945.log'
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'WixBundleOriginalSource' to value 
'C:\Users\MRAB\Downloads\Python\python-3.5.0rc3.exe'
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'WixBundleOriginalSourceFolder' to value 'C:\Users\MRAB\Downloads\Python\'
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'WixBundleName' to value 'Python 3.5.0rc3 (32-bit)'
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'WixBundleManufacturer' to value 'Python Software Foundation'
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'CRTInstalled' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_debug' to value 0
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_symbols' to value 0
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_dev' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_doc' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_exe' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_lib' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'PrependPath' to value 0
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_pip' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_tcltk' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_test' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_tools' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Shortcuts' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'InstallAllUsersState' to value 'disable'
[0A40:1508][2015-09-08T04:29:45]i000: Did not find 
C:\Users\MRAB\Downloads\Python\unattend.xml
[0A40:1508][2015-09-08T04:29:46]i000: Setting string variable 
'ActionLikeInstalling' to value 'Installing'
[0A40:1508][2015-09-08T04:29:46]i000: Setting string variable 
'ActionLikeInstallation' to value 'Setup'
[0A40:1508][2015-09-08T04:29:46]i000: Setting version variable 
'WixBundleFileVersion' to value '3.5.123.0'
[0A40:1CC8][2015-09-08T04:29:46]i100: Detect begin, 54 packages
[0A40:1CC8][2015-09-08T04:29:46]i103: Detected related package: 
{CF3F6C9B-5897-40E0-9650-8B2700475A41}, scope: PerMachine, version: 
3.5.5339.0, language: 0 operation: Downgrade
[0A40:1CC8][2015-09-08T04:29:46]i103: Detected related package: 
{CF3F6C9B-5897-40E0-9650-8B2700475A41}, scope: PerMachine, version: 
3.5.5339.0, language: 0 operation: Downgrade
[0A40:1CC8][2015-09-08T04:29:46]i103: Detected related package: 
{0D8550C8-AFBE-48C6-8C89-66B8FE2F2207}, scope: PerUser, version: 
3.5.121.0, language: 0 operation: MajorUpgrade
[0A40:1CC8][2015-09-08T04:29:46]i103: Detected related package: 
{0D8550C8-AFBE-48C6-8C89-66B8FE2F2207}, scope: PerUser, version: 
3.5.121.0, language: 0 operation: MajorUpgrade
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.0_x86, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.0_x64, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.1_x86, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.1_x64, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.2_x86, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.2_x64, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.3_x86, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.3_x64, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: core_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
core_AllUsers_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: core_AllUsers_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: core_JustForMe, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
core_JustForMe_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
core_JustForMe_d, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: dev_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: dev_AllUsers_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: dev_JustForMe, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: dev_JustForMe_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: exe_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: exe_AllUsers, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: exe_AllUsers, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
exe_AllUsers_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: exe_AllUsers_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: exe_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: exe_JustForMe, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: exe_JustForMe, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
exe_JustForMe_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: exe_JustForMe_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: lib_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
lib_AllUsers_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: lib_AllUsers_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: lib_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
lib_JustForMe_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: lib_JustForMe_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: test_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
test_AllUsers_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: test_AllUsers_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: test_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
test_JustForMe_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
test_JustForMe_d, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: doc_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: doc_AllUsers, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: doc_AllUsers, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: doc_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: doc_JustForMe, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: doc_JustForMe, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: tools_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: tools_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: tcltk_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_AllUsers, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_AllUsers, 
feature: AssociateFiles, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_AllUsers, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
tcltk_AllUsers_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
tcltk_AllUsers_pdb, feature: Symbols, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
tcltk_AllUsers_d, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
tcltk_AllUsers_d, feature: DebugBinaries, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: tcltk_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_JustForMe, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_JustForMe, 
feature: AssociateFiles, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_JustForMe, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
tcltk_JustForMe_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
tcltk_JustForMe_pdb, feature: Symbols, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
tcltk_JustForMe_d, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
tcltk_JustForMe_d, feature: DebugBinaries, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
launcher_AllUsers, state: Obsolete, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
launcher_AllUsers, feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
launcher_AllUsers, feature: AssociateFiles, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
launcher_JustForMe, state: Obsolete, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
launcher_JustForMe, feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
launcher_JustForMe, feature: AssociateFiles, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: pip_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: pip_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: path_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: path_JustForMe, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
compileall_AllUsers, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
compileall_JustForMe, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i199: Detect complete, result: 0x0
[0A40:1508][2015-09-08T04:29:46]i052: Condition 'not WixBundleElevated 
and (InstallAllUsers or (InstallLauncherAllUsers and Include_launcher))' 
evaluates to true.
[0A40:1508][2015-09-08T04:29:47]i000: Setting numeric variable 
'PrependPath' to value 0
[0A40:1508][2015-09-08T04:29:47]i000: Setting numeric variable 
'InstallLauncherAllUsers' to value 1
[0A40:1508][2015-09-08T04:29:47]i052: Condition 'not WixBundleElevated 
and (InstallAllUsers or (InstallLauncherAllUsers and Include_launcher))' 
evaluates to true.
[0A40:1508][2015-09-08T04:29:47]i000: Setting numeric variable 
'CompileAll' to value 0
[0A40:1508][2015-09-08T04:29:47]i000: Setting string variable 
'TargetDir' to value 
'C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32'
[0A40:1508][2015-09-08T04:29:47]i000: Setting string variable 
'ActionLikeInstalling' to value 'Installing'
[0A40:1508][2015-09-08T04:29:47]i000: Setting string variable 
'ActionLikeInstallation' to value 'Setup'
[0A40:1CC8][2015-09-08T04:29:47]i200: Plan begin, 54 packages, action: 
Install
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.0 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.0 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.0_x86
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.0 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.0 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.0_x64
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.1 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.1 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.1_x86
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.1 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.1 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.1_x64
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.2 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.2 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.2_x86
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.2 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.2 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.2_x64
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.3 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.3 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.3_x86
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.3 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.3 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.3_x64
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and not 
LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and not 
LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: core_AllUsers, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and 
Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and 
Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: core_AllUsers_pdb, bundle scope: PerUser, 
package scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and 
Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and 
Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: core_AllUsers_d, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and not 
LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and not 
LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleRollbackLog_core_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_000_core_JustForMe_rollback.log'
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleLog_core_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_000_core_JustForMe.log'
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and 
Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and 
Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and 
Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_core or Include_exe or Include_launcher or Include_pip) and 
Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_dev and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_dev and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: dev_AllUsers, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: dev_AllUsers_d, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_dev and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_dev and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleRollbackLog_dev_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_001_dev_JustForMe_rollback.log'
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleLog_dev_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_001_dev_JustForMe.log'
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and not LauncherOnly' 
evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and not LauncherOnly' 
evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i204: Plan 2 msi features for package: 
exe_AllUsers
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: DefaultFeature, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: Shortcuts, state: 
Absent, default requested: Unknown, ba requested: Local, execute action: 
AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: exe_AllUsers, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and Include_symbols and 
not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and Include_symbols and 
not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: exe_AllUsers_pdb, bundle scope: PerUser, 
package scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and Include_debug and 
not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and Include_debug and 
not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: exe_AllUsers_d, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and not LauncherOnly' 
evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and not LauncherOnly' 
evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i204: Plan 2 msi features for package: 
exe_JustForMe
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: DefaultFeature, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: Shortcuts, state: 
Absent, default requested: Unknown, ba requested: Local, execute action: 
AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleRollbackLog_exe_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_002_exe_JustForMe_rollback.log'
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleLog_exe_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_002_exe_JustForMe.log'
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and Include_symbols and 
not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and Include_symbols and 
not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and Include_debug and 
not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
(Include_exe or Include_launcher or Include_pip) and Include_debug and 
not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_lib and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_lib and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: lib_AllUsers, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: lib_AllUsers_pdb, bundle scope: PerUser, 
package scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: lib_AllUsers_d, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_lib and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_lib and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleRollbackLog_lib_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_003_lib_JustForMe_rollback.log'
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleLog_lib_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_003_lib_JustForMe.log'
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_test and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_test and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: test_AllUsers, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: test_AllUsers_pdb, bundle scope: PerUser, 
package scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_test and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_test and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: test_AllUsers_d, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_test and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_test and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleRollbackLog_test_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_004_test_JustForMe_rollback.log'
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleLog_test_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_004_test_JustForMe.log'
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_test and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_test and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_doc and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_doc and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i204: Plan 2 msi features for package: 
doc_AllUsers
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: DefaultFeature, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: Shortcuts, state: 
Absent, default requested: Unknown, ba requested: Local, execute action: 
AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: doc_AllUsers, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_doc and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_doc and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i204: Plan 2 msi features for package: 
doc_JustForMe
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: DefaultFeature, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: Shortcuts, state: 
Absent, default requested: Unknown, ba requested: Local, execute action: 
AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleRollbackLog_doc_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_005_doc_JustForMe_rollback.log'
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleLog_doc_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_005_doc_JustForMe.log'
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_tools and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_tools and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: tools_AllUsers, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_tools and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_tools and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleRollbackLog_tools_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_006_tools_JustForMe_rollback.log'
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleLog_tools_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_006_tools_JustForMe.log'
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_tcltk and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_tcltk and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i204: Plan 3 msi features for package: 
tcltk_AllUsers
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: DefaultFeature, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: AssociateFiles, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: Shortcuts, state: 
Absent, default requested: Unknown, ba requested: Local, execute action: 
AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: tcltk_AllUsers, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i204: Plan 1 msi features for package: 
tcltk_AllUsers_pdb
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: Symbols, state: 
Absent, default requested: Unknown, ba requested: Local, execute action: 
AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: tcltk_AllUsers_pdb, bundle scope: PerUser, 
package scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i204: Plan 1 msi features for package: 
tcltk_AllUsers_d
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: DebugBinaries, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: tcltk_AllUsers_d, bundle scope: PerUser, 
package scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_tcltk and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_tcltk and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i204: Plan 3 msi features for package: 
tcltk_JustForMe
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: DefaultFeature, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: AssociateFiles, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: Shortcuts, state: 
Absent, default requested: Unknown, ba requested: Local, execute action: 
AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleRollbackLog_tcltk_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_007_tcltk_JustForMe_rollback.log'
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleLog_tcltk_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_007_tcltk_JustForMe.log'
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i204: Plan 1 msi features for package: 
tcltk_JustForMe_pdb
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: Symbols, state: 
Absent, default requested: Unknown, ba requested: Local, execute action: 
AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i204: Plan 1 msi features for package: 
tcltk_JustForMe_d
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: DebugBinaries, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition '(InstallAllUsers or 
InstallLauncherAllUsers) and Include_launcher' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i204: Plan 2 msi features for package: 
launcher_AllUsers
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: DefaultFeature, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]i203: Planned feature: AssociateFiles, 
state: Absent, default requested: Unknown, ba requested: Local, execute 
action: AddLocal, rollback action: Remove
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: launcher_AllUsers, bundle scope: PerUser, 
package scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleRollbackLog_launcher_AllUsers' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_008_launcher_AllUsers_rollback.log'
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleLog_launcher_AllUsers' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_008_launcher_AllUsers.log'
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not (InstallAllUsers or 
InstallLauncherAllUsers) and Include_launcher' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_pip and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
Include_pip and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: pip_AllUsers, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_pip and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
Include_pip and not LauncherOnly' evaluates to true.
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleRollbackLog_pip_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_009_pip_JustForMe_rollback.log'
[0A40:1CC8][2015-09-08T04:29:47]i000: Setting string variable 
'WixBundleLog_pip_JustForMe' to value 
'C:\Users\MRAB\AppData\Local\Temp\Python 3.5.0rc3 
(32-bit)_20150908042945_009_pip_JustForMe.log'
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
PrependPath and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
PrependPath and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w322: Skipping cross-scope dependency 
registration on package: path_AllUsers, bundle scope: PerUser, package 
scope: PerMachine
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
PrependPath and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
PrependPath and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
CompileAll and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'InstallAllUsers and 
CompileAll and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: compileall_AllUsers
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
CompileAll and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not InstallAllUsers and 
CompileAll and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: compileall_JustForMe
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
crt_14.0_v6.0_x86, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
crt_14.0_v6.0_x64, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
crt_14.0_v6.1_x86, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
crt_14.0_v6.1_x64, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
crt_14.0_v6.2_x86, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
crt_14.0_v6.2_x64, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
crt_14.0_v6.3_x86, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
crt_14.0_v6.3_x64, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: core_AllUsers, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
core_AllUsers_pdb, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: core_AllUsers_d, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: core_JustForMe, 
state: Absent, default requested: Present, ba requested: Present, 
execute: Install, rollback: Uninstall, cache: Yes, uncache: No, 
dependency: Register
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
core_JustForMe_pdb, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: core_JustForMe_d, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: dev_AllUsers, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: dev_AllUsers_d, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: dev_JustForMe, 
state: Absent, default requested: Present, ba requested: Present, 
execute: Install, rollback: Uninstall, cache: Yes, uncache: No, 
dependency: Register
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: dev_JustForMe_d, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: exe_AllUsers, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: exe_AllUsers_pdb, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: exe_AllUsers_d, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: exe_JustForMe, 
state: Absent, default requested: Present, ba requested: Present, 
execute: Install, rollback: Uninstall, cache: No, uncache: No, 
dependency: Register
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
exe_JustForMe_pdb, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: exe_JustForMe_d, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: lib_AllUsers, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: lib_AllUsers_pdb, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: lib_AllUsers_d, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: lib_JustForMe, 
state: Absent, default requested: Present, ba requested: Present, 
execute: Install, rollback: Uninstall, cache: No, uncache: No, 
dependency: Register
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
lib_JustForMe_pdb, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: lib_JustForMe_d, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: test_AllUsers, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
test_AllUsers_pdb, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: test_AllUsers_d, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: test_JustForMe, 
state: Absent, default requested: Present, ba requested: Present, 
execute: Install, rollback: Uninstall, cache: No, uncache: No, 
dependency: Register
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
test_JustForMe_pdb, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: test_JustForMe_d, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: doc_AllUsers, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: doc_JustForMe, 
state: Absent, default requested: Present, ba requested: Present, 
execute: Install, rollback: Uninstall, cache: No, uncache: No, 
dependency: Register
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: tools_AllUsers, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: tools_JustForMe, 
state: Absent, default requested: Present, ba requested: Present, 
execute: Install, rollback: Uninstall, cache: No, uncache: No, 
dependency: Register
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: tcltk_AllUsers, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
tcltk_AllUsers_pdb, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: tcltk_AllUsers_d, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: tcltk_JustForMe, 
state: Absent, default requested: Present, ba requested: Present, 
execute: Install, rollback: Uninstall, cache: No, uncache: No, 
dependency: Register
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
tcltk_JustForMe_pdb, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
tcltk_JustForMe_d, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
launcher_AllUsers, state: Obsolete, default requested: None, ba 
requested: Present, execute: Install, rollback: Uninstall, cache: No, 
uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
launcher_JustForMe, state: Obsolete, default requested: None, ba 
requested: None, execute: None, rollback: None, cache: No, uncache: No, 
dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: pip_AllUsers, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: pip_JustForMe, 
state: Absent, default requested: Present, ba requested: Present, 
execute: Install, rollback: Uninstall, cache: No, uncache: No, 
dependency: Register
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: path_AllUsers, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: path_JustForMe, 
state: Absent, default requested: Absent, ba requested: Absent, execute: 
None, rollback: None, cache: No, uncache: No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
compileall_AllUsers, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i201: Planned package: 
compileall_JustForMe, state: Absent, default requested: Absent, ba 
requested: Absent, execute: None, rollback: None, cache: No, uncache: 
No, dependency: None
[0A40:1CC8][2015-09-08T04:29:47]i299: Plan complete, result: 0x0
[0A40:1CC8][2015-09-08T04:29:47]i300: Apply begin
[0A40:1CC8][2015-09-08T04:29:47]i010: Launching elevated engine process.
[0A40:1CC8][2015-09-08T04:29:49]i011: Launched elevated engine process.
[0A40:1CC8][2015-09-08T04:29:49]i012: Connected to elevated engine.
[1FCC:1C70][2015-09-08T04:29:49]i358: Pausing automatic updates.
[1FCC:1C70][2015-09-08T04:29:49]w308: Automatic updates could not be 
paused due to error: 0x80040154. Continuing...
[1FCC:1C70][2015-09-08T04:29:49]i360: Creating a system restore point.
[1FCC:1C70][2015-09-08T04:29:49]i361: Created a system restore point.
[0A40:1CC8][2015-09-08T04:29:49]i370: Session begin, registration key: 
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{939c965b-21aa-4e7f-9b88-bf9f41fe47d8}, 
options: 0x7, disable resume: No
[0A40:1CC8][2015-09-08T04:29:49]i000: Caching bundle from: 
'C:\Users\MRAB\AppData\Local\Temp\{939c965b-21aa-4e7f-9b88-bf9f41fe47d8}\.be\python-3.5.0rc3.exe' 
to: 'C:\Users\MRAB\AppData\Local\Package 
Cache\{939c965b-21aa-4e7f-9b88-bf9f41fe47d8}\python-3.5.0rc3.exe'
[0A40:1CC8][2015-09-08T04:29:50]i320: Registering bundle dependency 
provider: {939c965b-21aa-4e7f-9b88-bf9f41fe47d8}, version: 3.5.123.0
[0A40:1CC8][2015-09-08T04:29:50]i371: Updating session, registration 
key: 
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{939c965b-21aa-4e7f-9b88-bf9f41fe47d8}, 
resume: Active, restart initiated: No, disable resume: No
[0A40:1CC0][2015-09-08T04:29:50]i305: Verified acquired payload: 
core_JustForMe at path: C:\Users\MRAB\AppData\Local\Package 
Cache\.unverified\core_JustForMe, moving to: 
C:\Users\MRAB\AppData\Local\Package 
Cache\{96875502-851C-4716-AF31-D2308A293849}v3.5.123.0\core.msi.
[0A40:1CC8][2015-09-08T04:29:50]i323: Registering package dependency 
provider: {96875502-851C-4716-AF31-D2308A293849}, version: 3.5.123.0, 
package: core_JustForMe
[0A40:1CC8][2015-09-08T04:29:50]i301: Applying execute package: 
core_JustForMe, action: Install, path: 
C:\Users\MRAB\AppData\Local\Package 
Cache\{96875502-851C-4716-AF31-D2308A293849}v3.5.123.0\core.msi, 
arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"'
[0A40:1CC0][2015-09-08T04:29:50]i305: Verified acquired payload: 
dev_JustForMe at path: C:\Users\MRAB\AppData\Local\Package 
Cache\.unverified\dev_JustForMe, moving to: 
C:\Users\MRAB\AppData\Local\Package 
Cache\{1F48D630-274F-47B1-8425-E6E147A7312B}v3.5.123.0\dev.msi.
[0A40:1CC0][2015-09-08T04:29:50]i304: Verified existing payload: 
exe_JustForMe at path: C:\Users\MRAB\AppData\Local\Package 
Cache\{D924F350-F479-4B43-941C-DE9BDD40BE79}v3.5.123.0\exe.msi.
[0A40:1CC0][2015-09-08T04:29:50]i304: Verified existing payload: 
lib_JustForMe at path: C:\Users\MRAB\AppData\Local\Package 
Cache\{629CBAA8-3EDF-43A8-9A2B-92E1BBA86955}v3.5.123.0\lib.msi.
[0A40:1CC0][2015-09-08T04:29:50]i304: Verified existing payload: 
test_JustForMe at path: C:\Users\MRAB\AppData\Local\Package 
Cache\{A293DE1B-6CBD-4474-9695-6DD093A9175A}v3.5.123.0\test.msi.
[0A40:1CC0][2015-09-08T04:29:50]i304: Verified existing payload: 
doc_JustForMe at path: C:\Users\MRAB\AppData\Local\Package 
Cache\{7A78FBDB-2802-4440-A71C-5C4302DD6A15}v3.5.123.0\doc.msi.
[0A40:1CC0][2015-09-08T04:29:50]i304: Verified existing payload: 
tools_JustForMe at path: C:\Users\MRAB\AppData\Local\Package 
Cache\{EAF34C48-097F-46C7-8040-113B4831261A}v3.5.123.0\tools.msi.
[0A40:1CC0][2015-09-08T04:29:50]i304: Verified existing payload: 
tcltk_JustForMe at path: C:\Users\MRAB\AppData\Local\Package 
Cache\{137010C2-D3AC-44DA-AE5B-C38D7CB3B2D1}v3.5.123.0\tcltk.msi.
[1FCC:1E50][2015-09-08T04:29:50]i304: Verified existing payload: 
launcher_AllUsers at path: C:\ProgramData\Package 
Cache\{288248CB-0C6D-45F8-B52A-629B4C5EF1FD}v3.5.122.0\launcher.msi.
[0A40:1CC0][2015-09-08T04:29:50]i304: Verified existing payload: 
pip_JustForMe at path: C:\Users\MRAB\AppData\Local\Package 
Cache\{465634FD-E060-45CF-B5A9-E9DA55FC815C}v3.5.123.0\pip.msi.
[0A40:1CC8][2015-09-08T04:29:50]i319: Applied execute package: 
core_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:29:50]i325: Registering dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{96875502-851C-4716-AF31-D2308A293849}, package: core_JustForMe
[0A40:1CC8][2015-09-08T04:29:50]i323: Registering package dependency 
provider: {1F48D630-274F-47B1-8425-E6E147A7312B}, version: 3.5.123.0, 
package: dev_JustForMe
[0A40:1CC8][2015-09-08T04:29:50]i301: Applying execute package: 
dev_JustForMe, action: Install, path: 
C:\Users\MRAB\AppData\Local\Package 
Cache\{1F48D630-274F-47B1-8425-E6E147A7312B}v3.5.123.0\dev.msi, 
arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"'
[0A40:1CC8][2015-09-08T04:29:53]i319: Applied execute package: 
dev_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:29:53]i325: Registering dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{1F48D630-274F-47B1-8425-E6E147A7312B}, package: dev_JustForMe
[0A40:1CC8][2015-09-08T04:29:53]i323: Registering package dependency 
provider: {D924F350-F479-4B43-941C-DE9BDD40BE79}, version: 3.5.123.0, 
package: exe_JustForMe
[0A40:1CC8][2015-09-08T04:29:53]i301: Applying execute package: 
exe_JustForMe, action: Install, path: 
C:\Users\MRAB\AppData\Local\Package 
Cache\{D924F350-F479-4B43-941C-DE9BDD40BE79}v3.5.123.0\exe.msi, 
arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures" 
ADDLOCAL="DefaultFeature,Shortcuts"'
[0A40:1CC8][2015-09-08T04:29:54]i319: Applied execute package: 
exe_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:29:54]i325: Registering dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{D924F350-F479-4B43-941C-DE9BDD40BE79}, package: exe_JustForMe
[0A40:1CC8][2015-09-08T04:29:54]i323: Registering package dependency 
provider: {629CBAA8-3EDF-43A8-9A2B-92E1BBA86955}, version: 3.5.123.0, 
package: lib_JustForMe
[0A40:1CC8][2015-09-08T04:29:54]i301: Applying execute package: 
lib_JustForMe, action: Install, path: 
C:\Users\MRAB\AppData\Local\Package 
Cache\{629CBAA8-3EDF-43A8-9A2B-92E1BBA86955}v3.5.123.0\lib.msi, 
arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"'
[0A40:1CC8][2015-09-08T04:30:06]i319: Applied execute package: 
lib_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:30:06]i325: Registering dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{629CBAA8-3EDF-43A8-9A2B-92E1BBA86955}, package: lib_JustForMe
[0A40:1CC8][2015-09-08T04:30:06]i323: Registering package dependency 
provider: {A293DE1B-6CBD-4474-9695-6DD093A9175A}, version: 3.5.123.0, 
package: test_JustForMe
[0A40:1CC8][2015-09-08T04:30:06]i301: Applying execute package: 
test_JustForMe, action: Install, path: 
C:\Users\MRAB\AppData\Local\Package 
Cache\{A293DE1B-6CBD-4474-9695-6DD093A9175A}v3.5.123.0\test.msi, 
arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"'
[0A40:1CC8][2015-09-08T04:30:19]i319: Applied execute package: 
test_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:30:19]i325: Registering dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{A293DE1B-6CBD-4474-9695-6DD093A9175A}, package: test_JustForMe
[0A40:1CC8][2015-09-08T04:30:19]i323: Registering package dependency 
provider: {7A78FBDB-2802-4440-A71C-5C4302DD6A15}, version: 3.5.123.0, 
package: doc_JustForMe
[0A40:1CC8][2015-09-08T04:30:19]i301: Applying execute package: 
doc_JustForMe, action: Install, path: 
C:\Users\MRAB\AppData\Local\Package 
Cache\{7A78FBDB-2802-4440-A71C-5C4302DD6A15}v3.5.123.0\doc.msi, 
arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures" 
ADDLOCAL="DefaultFeature,Shortcuts"'
[0A40:1CC8][2015-09-08T04:30:21]i319: Applied execute package: 
doc_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:30:21]i325: Registering dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{7A78FBDB-2802-4440-A71C-5C4302DD6A15}, package: doc_JustForMe
[0A40:1CC8][2015-09-08T04:30:21]i323: Registering package dependency 
provider: {EAF34C48-097F-46C7-8040-113B4831261A}, version: 3.5.123.0, 
package: tools_JustForMe
[0A40:1CC8][2015-09-08T04:30:21]i301: Applying execute package: 
tools_JustForMe, action: Install, path: 
C:\Users\MRAB\AppData\Local\Package 
Cache\{EAF34C48-097F-46C7-8040-113B4831261A}v3.5.123.0\tools.msi, 
arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"'
[0A40:1CC8][2015-09-08T04:30:23]i319: Applied execute package: 
tools_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:30:23]i325: Registering dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{EAF34C48-097F-46C7-8040-113B4831261A}, package: tools_JustForMe
[0A40:1CC8][2015-09-08T04:30:23]i323: Registering package dependency 
provider: {137010C2-D3AC-44DA-AE5B-C38D7CB3B2D1}, version: 3.5.123.0, 
package: tcltk_JustForMe
[0A40:1CC8][2015-09-08T04:30:23]i301: Applying execute package: 
tcltk_JustForMe, action: Install, path: 
C:\Users\MRAB\AppData\Local\Package 
Cache\{137010C2-D3AC-44DA-AE5B-C38D7CB3B2D1}v3.5.123.0\tcltk.msi, 
arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures" 
ADDLOCAL="DefaultFeature,AssociateFiles,Shortcuts"'
[0A40:1CC8][2015-09-08T04:30:41]i319: Applied execute package: 
tcltk_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:30:41]i325: Registering dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{137010C2-D3AC-44DA-AE5B-C38D7CB3B2D1}, package: tcltk_JustForMe
[1FCC:1C70][2015-09-08T04:30:41]i301: Applying execute package: 
launcher_AllUsers, action: Install, path: C:\ProgramData\Package 
Cache\{288248CB-0C6D-45F8-B52A-629B4C5EF1FD}v3.5.122.0\launcher.msi, 
arguments: ' ALLUSERS="1" ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
ADDLOCAL="DefaultFeature,AssociateFiles"'
[1FCC:1C70][2015-09-08T04:30:45]e000: Error 0x80070643: Failed to 
install MSI package.
[1FCC:1C70][2015-09-08T04:30:45]e000: Error 0x80070643: Failed to 
execute MSI package.
[0A40:1CC8][2015-09-08T04:30:45]e000: Error 0x80070643: Failed to 
configure per-machine MSI package.
[0A40:1CC8][2015-09-08T04:30:45]i319: Applied execute package: 
launcher_AllUsers, result: 0x80070643, restart: None
[0A40:1CC8][2015-09-08T04:30:45]e000: Error 0x80070643: Failed to 
execute MSI package.
[1FCC:1C70][2015-09-08T04:30:45]i318: Skipped rollback of package: 
launcher_AllUsers, action: Uninstall, already: Absent
[0A40:1CC8][2015-09-08T04:30:45]i319: Applied rollback package: 
launcher_AllUsers, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:30:45]i329: Removed package dependency 
provider: {5CA1D2B2-DE07-4B9F-ABF8-3D988418F8BB}, package: tcltk_JustForMe_d
[0A40:1CC8][2015-09-08T04:30:45]i329: Removed package dependency 
provider: {D1EF88EB-3931-45EC-B1D8-14A2838B9BF9}, package: 
tcltk_JustForMe_pdb
[0A40:1CC8][2015-09-08T04:30:45]i326: Removed dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{137010C2-D3AC-44DA-AE5B-C38D7CB3B2D1}, package tcltk_JustForMe
[0A40:1CC8][2015-09-08T04:30:45]i301: Applying rollback package: 
tcltk_JustForMe, action: Uninstall, path: (null), arguments: ' 
ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures" 
REMOVE="DefaultFeature,AssociateFiles,Shortcuts"'
[0A40:1CC8][2015-09-08T04:31:26]i319: Applied rollback package: 
tcltk_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:31:26]i329: Removed package dependency 
provider: {137010C2-D3AC-44DA-AE5B-C38D7CB3B2D1}, package: tcltk_JustForMe
[0A40:1CC8][2015-09-08T04:31:26]i326: Removed dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{EAF34C48-097F-46C7-8040-113B4831261A}, package tools_JustForMe
[0A40:1CC8][2015-09-08T04:31:26]i301: Applying rollback package: 
tools_JustForMe, action: Uninstall, path: (null), arguments: ' 
ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"'
[0A40:1CC8][2015-09-08T04:31:30]i319: Applied rollback package: 
tools_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:31:30]i329: Removed package dependency 
provider: {EAF34C48-097F-46C7-8040-113B4831261A}, package: tools_JustForMe
[0A40:1CC8][2015-09-08T04:31:30]i326: Removed dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{7A78FBDB-2802-4440-A71C-5C4302DD6A15}, package doc_JustForMe
[0A40:1CC8][2015-09-08T04:31:30]i301: Applying rollback package: 
doc_JustForMe, action: Uninstall, path: (null), arguments: ' 
ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures" 
REMOVE="DefaultFeature,Shortcuts"'
[0A40:1CC8][2015-09-08T04:31:30]i319: Applied rollback package: 
doc_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:31:30]i329: Removed package dependency 
provider: {7A78FBDB-2802-4440-A71C-5C4302DD6A15}, package: doc_JustForMe
[0A40:1CC8][2015-09-08T04:31:30]i329: Removed package dependency 
provider: {9FA35BEC-6982-4A96-A10A-3FF07B52886E}, package: test_JustForMe_d
[0A40:1CC8][2015-09-08T04:31:30]i329: Removed package dependency 
provider: {03DC3AE9-6287-4C3D-B662-0734A0E69C11}, package: 
test_JustForMe_pdb
[0A40:1CC8][2015-09-08T04:31:30]i326: Removed dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{A293DE1B-6CBD-4474-9695-6DD093A9175A}, package test_JustForMe
[0A40:1CC8][2015-09-08T04:31:30]i301: Applying rollback package: 
test_JustForMe, action: Uninstall, path: (null), arguments: ' 
ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"'
[0A40:1CC8][2015-09-08T04:31:57]i319: Applied rollback package: 
test_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:31:57]i329: Removed package dependency 
provider: {A293DE1B-6CBD-4474-9695-6DD093A9175A}, package: test_JustForMe
[0A40:1CC8][2015-09-08T04:31:57]i329: Removed package dependency 
provider: {6FDE12E4-1CBE-440A-975B-0A419CEA876A}, package: lib_JustForMe_d
[0A40:1CC8][2015-09-08T04:31:57]i329: Removed package dependency 
provider: {EC733C7D-9AE1-4016-81AF-87BA6F333ACE}, package: lib_JustForMe_pdb
[0A40:1CC8][2015-09-08T04:31:57]i326: Removed dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{629CBAA8-3EDF-43A8-9A2B-92E1BBA86955}, package lib_JustForMe
[0A40:1CC8][2015-09-08T04:31:57]i301: Applying rollback package: 
lib_JustForMe, action: Uninstall, path: (null), arguments: ' 
ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"'
[0A40:1CC8][2015-09-08T04:32:19]i319: Applied rollback package: 
lib_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:32:19]i329: Removed package dependency 
provider: {629CBAA8-3EDF-43A8-9A2B-92E1BBA86955}, package: lib_JustForMe
[0A40:1CC8][2015-09-08T04:32:19]i329: Removed package dependency 
provider: {5962E2A1-543B-4780-B71F-A78946B1EFB8}, package: exe_JustForMe_d
[0A40:1CC8][2015-09-08T04:32:19]i329: Removed package dependency 
provider: {A5B5C471-90EF-483C-9717-796FBBE05F13}, package: exe_JustForMe_pdb
[0A40:1CC8][2015-09-08T04:32:19]i326: Removed dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{D924F350-F479-4B43-941C-DE9BDD40BE79}, package exe_JustForMe
[0A40:1CC8][2015-09-08T04:32:19]i301: Applying rollback package: 
exe_JustForMe, action: Uninstall, path: (null), arguments: ' 
ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures" 
REMOVE="DefaultFeature,Shortcuts"'
[0A40:1CC8][2015-09-08T04:32:20]i319: Applied rollback package: 
exe_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:32:20]i329: Removed package dependency 
provider: {D924F350-F479-4B43-941C-DE9BDD40BE79}, package: exe_JustForMe
[0A40:1CC8][2015-09-08T04:32:20]i329: Removed package dependency 
provider: {C02C2FFA-D255-4486-9CFB-C8246421BAD4}, package: dev_JustForMe_d
[0A40:1CC8][2015-09-08T04:32:20]i326: Removed dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{1F48D630-274F-47B1-8425-E6E147A7312B}, package dev_JustForMe
[0A40:1CC8][2015-09-08T04:32:20]i301: Applying rollback package: 
dev_JustForMe, action: Uninstall, path: (null), arguments: ' 
ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"'
[0A40:1CC8][2015-09-08T04:32:24]i319: Applied rollback package: 
dev_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:32:24]i329: Removed package dependency 
provider: {1F48D630-274F-47B1-8425-E6E147A7312B}, package: dev_JustForMe
[0A40:1CC8][2015-09-08T04:32:24]i351: Removing cached package: 
dev_JustForMe, from path: C:\Users\MRAB\AppData\Local\Package 
Cache\{1F48D630-274F-47B1-8425-E6E147A7312B}v3.5.123.0\
[0A40:1CC8][2015-09-08T04:32:24]i329: Removed package dependency 
provider: {0E5EBB7D-F702-4211-8742-A42B35FA1205}, package: core_JustForMe_d
[0A40:1CC8][2015-09-08T04:32:24]i329: Removed package dependency 
provider: {8508B125-3D7C-44C2-B27E-18CC10B3A452}, package: 
core_JustForMe_pdb
[0A40:1CC8][2015-09-08T04:32:24]i326: Removed dependency: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8} on package provider: 
{96875502-851C-4716-AF31-D2308A293849}, package core_JustForMe
[0A40:1CC8][2015-09-08T04:32:24]i301: Applying rollback package: 
core_JustForMe, action: Uninstall, path: (null), arguments: ' 
ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" 
TARGETDIR="C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32" 
OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"'
[0A40:1CC8][2015-09-08T04:32:24]i319: Applied rollback package: 
core_JustForMe, result: 0x0, restart: None
[0A40:1CC8][2015-09-08T04:32:24]i329: Removed package dependency 
provider: {96875502-851C-4716-AF31-D2308A293849}, package: core_JustForMe
[0A40:1CC8][2015-09-08T04:32:24]i351: Removing cached package: 
core_JustForMe, from path: C:\Users\MRAB\AppData\Local\Package 
Cache\{96875502-851C-4716-AF31-D2308A293849}v3.5.123.0\
[0A40:1CC8][2015-09-08T04:32:24]i372: Session end, registration key: 
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{939c965b-21aa-4e7f-9b88-bf9f41fe47d8}, 
resume: None, restart: None, disable resume: No
[0A40:1CC8][2015-09-08T04:32:24]i330: Removed bundle dependency 
provider: {939c965b-21aa-4e7f-9b88-bf9f41fe47d8}
[0A40:1CC8][2015-09-08T04:32:24]i352: Removing cached bundle: 
{939c965b-21aa-4e7f-9b88-bf9f41fe47d8}, from path: 
C:\Users\MRAB\AppData\Local\Package 
Cache\{939c965b-21aa-4e7f-9b88-bf9f41fe47d8}\
[0A40:1CC8][2015-09-08T04:32:24]i371: Updating session, registration 
key: 
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{939c965b-21aa-4e7f-9b88-bf9f41fe47d8}, 
resume: None, restart initiated: No, disable resume: No
[0A40:1CC8][2015-09-08T04:32:25]i399: Apply complete, result: 
0x80070643, restart: None, ba requested restart:  No

From python-ideas at mgmiller.net  Tue Sep  8 08:37:33 2015
From: python-ideas at mgmiller.net (Mike Miller)
Date: Mon, 7 Sep 2015 23:37:33 -0700
Subject: [Python-Dev] PEP 498: Naming
In-Reply-To: <55EA494D.7090206@trueblade.com>
References: <55EA494D.7090206@trueblade.com>
Message-ID: <55EE822D.8010303@mgmiller.net>

Nice work!

So we're on the eve of pronouncement and though I've read several bring up the 
slightly-unfortunate naming of f-strings in the past, I've not seen recent 
discussion on the subject.  While the 498 implementation looks best, it still 
could be tweaked on the surface to use one of the other names or letters that 
had come up.  The original idea was to use f'' because it was thought that the 
feature would be locked to str.format, but that is no longer as true as it was 
originally.

To my knowledge there was i for interpolation, t for template, and e for 
expression suggested.  Any better ideas?

It's a good time to have this bikeshed discussion, because if the PEP is 
accepted news will get out and the name will be set in cement.  Previous drafts 
have made it out to hacker news and reddit, as the feature is exciting, so 
acceptance should as well.

-Mike


On 09/04/2015 06:45 PM, Eric V. Smith wrote:
>
> I think it's now ready for Guido to pronounce on it.

From steve.dower at python.org  Tue Sep  8 15:22:20 2015
From: steve.dower at python.org (Steve Dower)
Date: Tue, 8 Sep 2015 06:22:20 -0700
Subject: [Python-Dev] Can't install Python 3.5rc3
In-Reply-To: <55EE58AA.40108@mrabarnett.plus.com>
References: <55EE58AA.40108@mrabarnett.plus.com>
Message-ID: <E1ZZIrd-00019o-CE@se2-syd.hostedmail.net.au>

It thinks you have version 3.5.5339.0 installed, which IIRC was a test build I made for some tcl changes. It's probably listed under xPython - can you see it?

As I said at the time, they should be totally independent, but I guess not. Thanks for the heads up.

Top-posted from my Windows Phone

-----Original Message-----
From: "MRAB" <python at mrabarnett.plus.com>
Sent: ?9/?7/?2015 20:41
To: "Python-Dev" <python-dev at python.org>
Subject: [Python-Dev] Can't install Python 3.5rc3

I've been unable to install Python 3.5rc3.

It progresses to installing Tcl/tk, then reports that a newer version
of 3.5 is already installed, then it rolls back (slowly).

I don't know where it's finding this "newer version"; I've uninstalled
the previous releases of Python 3.5.

I'm on Windows 10.


Here's the contents of the log file:

[0A40:1CC8][2015-09-08T04:29:45]i001: Burn v3.10.0.1823, Windows v10.0 
(Build 10240: Service Pack 0), path: 
C:\Users\MRAB\Downloads\Python\python-3.5.0rc3.exe
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'ActionLikeInstalling' to value 'Installing'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'ActionLikeInstallation' to value 'Setup'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'ShortVersion' to value '3.5'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'ShortVersionNoDot' to value '35'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'InstallAllUsers' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'InstallLauncherAllUsers' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetDir' to value ''
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'DefaultAllUsersTargetDir' to value '[ProgramFilesFolder]Python 
[ShortVersion]'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetPlatform' to value 'x86'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'DefaultJustForMeTargetDir' to value 
'[LocalAppDataFolder]Programs\Python\Python[ShortVersionNoDot]-32'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'OptionalFeaturesRegistryKey' to value 
'Software\Python\PythonCore\[ShortVersion]-32\InstalledFeatures'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetDirRegistryKey' to value 
'Software\Python\PythonCore\[ShortVersion]-32\InstallPath'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'DefaultCustomTargetDir' to value ''
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'InstallAllUsersState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'InstallLauncherAllUsersState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'CustomInstallLauncherAllUsersState' to value 
'[InstallLauncherAllUsersState]'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetDirState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'CustomBrowseButtonState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_core' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_exe' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_dev' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_lib' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_test' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_doc' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_tools' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_tcltk' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_pip' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_launcher' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_symbols' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_debug' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'LauncherOnly' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'AssociateFiles' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Shortcuts' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'PrependPath' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'CompileAll' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'SimpleInstall' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'SimpleInstallDescription' to value ''
[0A40:1CC8][2015-09-08T04:29:45]i009: Command Line: ''
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'WixBundleLog' to value 'C:\Users\MRAB\AppData\Local\Temp\Python 
3.5.0rc3 (32-bit)_20150908042945.log'
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'WixBundleOriginalSource' to value 
'C:\Users\MRAB\Downloads\Python\python-3.5.0rc3.exe'
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'WixBundleOriginalSourceFolder' to value 'C:\Users\MRAB\Downloads\Python\'
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'WixBundleName' to value 'Python 3.5.0rc3 (32-bit)'
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'WixBundleManufacturer' to value 'Python Software Foundation'
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'CRTInstalled' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_debug' to value 0
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_symbols' to value 0
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_dev' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_doc' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_exe' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_lib' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'PrependPath' to value 0
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_pip' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_tcltk' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_test' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Include_tools' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting numeric variable 
'Shortcuts' to value 1
[0A40:1CC8][2015-09-08T04:29:45]i000: Setting string variable 
'InstallAllUsersState' to value 'disable'
[0A40:1508][2015-09-08T04:29:45]i000: Did not find 
C:\Users\MRAB\Downloads\Python\unattend.xml
[0A40:1508][2015-09-08T04:29:46]i000: Setting string variable 
'ActionLikeInstalling' to value 'Installing'
[0A40:1508][2015-09-08T04:29:46]i000: Setting string variable 
'ActionLikeInstallation' to value 'Setup'
[0A40:1508][2015-09-08T04:29:46]i000: Setting version variable 
'WixBundleFileVersion' to value '3.5.123.0'
[0A40:1CC8][2015-09-08T04:29:46]i100: Detect begin, 54 packages
[0A40:1CC8][2015-09-08T04:29:46]i103: Detected related package: 
{CF3F6C9B-5897-40E0-9650-8B2700475A41}, scope: PerMachine, version: 
3.5.5339.0, language: 0 operation: Downgrade
[0A40:1CC8][2015-09-08T04:29:46]i103: Detected related package: 
{CF3F6C9B-5897-40E0-9650-8B2700475A41}, scope: PerMachine, version: 
3.5.5339.0, language: 0 operation: Downgrade
[0A40:1CC8][2015-09-08T04:29:46]i103: Detected related package: 
{0D8550C8-AFBE-48C6-8C89-66B8FE2F2207}, scope: PerUser, version: 
3.5.121.0, language: 0 operation: MajorUpgrade
[0A40:1CC8][2015-09-08T04:29:46]i103: Detected related package: 
{0D8550C8-AFBE-48C6-8C89-66B8FE2F2207}, scope: PerUser, version: 
3.5.121.0, language: 0 operation: MajorUpgrade
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.0_x86, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.0_x64, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.1_x86, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.1_x64, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.2_x86, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.2_x64, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.3_x86, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
crt_14.0_v6.3_x64, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: core_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
core_AllUsers_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: core_AllUsers_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: core_JustForMe, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
core_JustForMe_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
core_JustForMe_d, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: dev_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: dev_AllUsers_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: dev_JustForMe, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: dev_JustForMe_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: exe_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: exe_AllUsers, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: exe_AllUsers, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
exe_AllUsers_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: exe_AllUsers_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: exe_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: exe_JustForMe, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: exe_JustForMe, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
exe_JustForMe_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: exe_JustForMe_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: lib_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
lib_AllUsers_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: lib_AllUsers_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: lib_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
lib_JustForMe_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: lib_JustForMe_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: test_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
test_AllUsers_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: test_AllUsers_d, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: test_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
test_JustForMe_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
test_JustForMe_d, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: doc_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: doc_AllUsers, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: doc_AllUsers, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: doc_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: doc_JustForMe, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: doc_JustForMe, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: tools_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: tools_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: tcltk_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_AllUsers, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_AllUsers, 
feature: AssociateFiles, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_AllUsers, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
tcltk_AllUsers_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
tcltk_AllUsers_pdb, feature: Symbols, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
tcltk_AllUsers_d, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
tcltk_AllUsers_d, feature: DebugBinaries, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: tcltk_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_JustForMe, 
feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_JustForMe, 
feature: AssociateFiles, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: tcltk_JustForMe, 
feature: Shortcuts, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
tcltk_JustForMe_pdb, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
tcltk_JustForMe_pdb, feature: Symbols, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
tcltk_JustForMe_d, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
tcltk_JustForMe_d, feature: DebugBinaries, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
launcher_AllUsers, state: Obsolete, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
launcher_AllUsers, feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
launcher_AllUsers, feature: AssociateFiles, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
launcher_JustForMe, state: Obsolete, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
launcher_JustForMe, feature: DefaultFeature, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i104: Detected package: 
launcher_JustForMe, feature: AssociateFiles, state: Absent
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: pip_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: pip_JustForMe, 
state: Absent, cached: Complete
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: path_AllUsers, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: path_JustForMe, 
state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
compileall_AllUsers, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i101: Detected package: 
compileall_JustForMe, state: Absent, cached: None
[0A40:1CC8][2015-09-08T04:29:46]i199: Detect complete, result: 0x0
[0A40:1508][2015-09-08T04:29:46]i052: Condition 'not WixBundleElevated 
and (InstallAllUsers or (InstallLauncherAllUsers and Include_launcher))' 
evaluates to true.
[0A40:1508][2015-09-08T04:29:47]i000: Setting numeric variable 
'PrependPath' to value 0
[0A40:1508][2015-09-08T04:29:47]i000: Setting numeric variable 
'InstallLauncherAllUsers' to value 1
[0A40:1508][2015-09-08T04:29:47]i052: Condition 'not WixBundleElevated 
and (InstallAllUsers or (InstallLauncherAllUsers and Include_launcher))' 
evaluates to true.
[0A40:1508][2015-09-08T04:29:47]i000: Setting numeric variable 
'CompileAll' to value 0
[0A40:1508][2015-09-08T04:29:47]i000: Setting string variable 
'TargetDir' to value 
'C:\Users\MRAB\AppData\Local\Programs\Python\Python35-32'
[0A40:1508][2015-09-08T04:29:47]i000: Setting string variable 
'ActionLikeInstalling' to value 'Installing'
[0A40:1508][2015-09-08T04:29:47]i000: Setting string variable 
'ActionLikeInstallation' to value 'Setup'
[0A40:1CC8][2015-09-08T04:29:47]i200: Plan begin, 54 packages, action: 
Install
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.0 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.0 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.0_x86
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.0 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.0 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.0_x64
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.1 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.1 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.1_x86
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.1 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.1 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.1_x64
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.2 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT = v6.2 and not VersionNT64 and (Include_core or Include_exe or 
Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping dependency registration 
on package with no dependency providers: crt_14.0_v6.2_x86
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.2 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]i052: Condition 'not CRTInstalled and 
VersionNT64 = v6.2 and (Include_core or Include_exe or Include_launcher 
or Include_pip) and not LauncherOnly' evaluates to false.
[0A40:1CC8][2015-09-08T04:29:47]w321: Skipping depen


[The entire original message is not included.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/3ebbfe89/attachment.html>

From alexander.belopolsky at gmail.com  Tue Sep  8 16:20:42 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 8 Sep 2015 10:20:42 -0400
Subject: [Python-Dev] PEP 498: Naming
In-Reply-To: <55EE822D.8010303@mgmiller.net>
References: <55EA494D.7090206@trueblade.com>
	<55EE822D.8010303@mgmiller.net>
Message-ID: <CAP7h-xaTQ6UecqUFpbv01yrKO8RK553pPkEvXnwTa8R4uYqZ8g@mail.gmail.com>

On Tue, Sep 8, 2015 at 2:37 AM, Mike Miller <python-ideas at mgmiller.net>
wrote:

> To my knowledge there was i for interpolation, t for template, and e for
> expression suggested.  Any better ideas?


I believe someone suggested !"..." as well.   I still think f"..." notation
is the best as long as these elements are called "format strings" in the
documentation.  After all, we don't call a unicode string "u-string" or
bytes a "b-string".  Given enough imagination someone may find
not-safe-for-work associations in those abbreviations as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/d55eb306/attachment.html>

From eric at trueblade.com  Tue Sep  8 16:42:24 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Tue, 08 Sep 2015 10:42:24 -0400
Subject: [Python-Dev] PEP 498: Naming
In-Reply-To: <CAP7h-xaTQ6UecqUFpbv01yrKO8RK553pPkEvXnwTa8R4uYqZ8g@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>	<55EE822D.8010303@mgmiller.net>
 <CAP7h-xaTQ6UecqUFpbv01yrKO8RK553pPkEvXnwTa8R4uYqZ8g@mail.gmail.com>
Message-ID: <55EEF3D0.4060809@trueblade.com>

On 09/08/2015 10:20 AM, Alexander Belopolsky wrote:
> 
> On Tue, Sep 8, 2015 at 2:37 AM, Mike Miller <python-ideas at mgmiller.net
> <mailto:python-ideas at mgmiller.net>> wrote:
> 
>     To my knowledge there was i for interpolation, t for template, and e
>     for expression suggested.  Any better ideas?
> 
> 
> I believe someone suggested !"..." as well.   I still think f"..."
> notation is the best as long as these elements are called "format
> strings" in the documentation.  After all, we don't call a unicode
> string "u-string" or bytes a "b-string".  Given enough imagination
> someone may find not-safe-for-work associations in those abbreviations
> as well.

Agreed. I discussed it with Guido offline, and we agreed on sticking
with f"" to tie in with str.format(), format(), __format__(), and format
strings.

Eric.


From garyrob at me.com  Tue Sep  8 16:12:37 2015
From: garyrob at me.com (Gary Robinson)
Date: Tue, 08 Sep 2015 10:12:37 -0400
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
	comment
Message-ID: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>

Folks,

If it?s out of line in some way for me to make this comment on this list, let me know and I?ll stop! But I do feel strongly about one issue and think it?s worth mentioning, so here goes.

I read the "A better story for multi-core Python? with great interest because the GIL has actually been a major hindrance to me. I know that for many uses, it?s a non-issue. But it was for me.

My situation was that I had a huge (technically mutable, but unchanging) data structure which needed a lot of analysis. CPU time was a major factor ? things took days to run. But even so, my time as a programmer was much more important than CPU time. I needed to prototype different algorithms very quickly. Even Cython would have slowed me down too much. Also, I had a lot of reason to want to make use of the many great statistical functions in SciPy, so Python was an excellent choice for me in that way. 

So, even though pure Python might not be the right choice for this program in a production environment, it was the right choice for me at the time. And, if I could have accessed as many cores as I wanted, it may have been good enough in production too. But my work was hampered by one thing:

There was a huge data structure that all the analysis needed to access. Using a database would have slowed things down too much. Ideally, I needed to access this same structure from many cores at once. On a Power8 system, for example, with its larger number of cores, performance may well have been good enough for production. In any case, my experimentation and prototyping would have gone more quickly with more cores.

But this data structure was simply too big. Replicating it in different processes used memory far too quickly and was the limiting factor on the number of cores I could use. (I could fork with the big data structure already in memory, but copy-on-write issues due to reference counting caused multiple copies to exist anyway.)

So, one thing I am hoping comes out of any effort in the ?A better story? direction would be a way to share large data structures between processes. Two possible solutions:

1) More the reference counts away from data structures, so copy-on-write isn?t an issue. That sounds like a lot of work ? I have no idea whether it?s practical. It has been mentioned in the ?A better story? discussion, but I wanted to bring it up again in the context of my specific use-case. Also, it seems worth reiterating that even though copy-on-write forking is a Unix thing, the midipix project appears to bring it to Windows as well. (http://midipix.org)

2) Have a mode where a particular data structure is not reference counted or garbage collected. The programmer would be entirely responsible for manually calling del on the structure if he wants to free that memory. I would imagine this would be controversial because Python is currently designed in a very different way. However, I see no actual risk if one were to use an @manual_memory_management decorator or some technique like that to make it very clear that the programmer is taking responsibility. I.e., in general, information sharing between subinterpreters would occur through message passing. But there would be the option of the programmer taking responsibility of memory management for a particular structure. In my case, the amount of work required for this would have been approximately zero ? once the structure was created, it was needed for the lifetime of the process. 

Under this second solution, there would be little need to actually remove the reference counts from the data structures ? they just wouldn?t be accessed. Maybe it?s not a practical solution, if only because of the overhead of Python needing to check whether a given structure is manually managed or not. In that case, the first solution makes more sense.

In any case I thought this was worth mentioning,  because it has been a real problem for me, and I assume it has been a real problem for other people as well. If a solution is both possible and practical, that would be great.

Thank you for listening,
Gary


-- 

Gary Robinson
garyrob at me.com
http://www.garyrobinson.net


From p.f.moore at gmail.com  Tue Sep  8 17:44:46 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 8 Sep 2015 16:44:46 +0100
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
	comment
In-Reply-To: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
Message-ID: <CACac1F8Rasijzyq-b5qtrwHKSviJJw96ryJWNwQCGMEefsZ-zA@mail.gmail.com>

On 8 September 2015 at 15:12, Gary Robinson <garyrob at me.com> wrote:
> So, one thing I am hoping comes out of any effort in the ?A better story? direction would be a way to share large data structures between processes. Two possible solutions:
>
> 1) More the reference counts away from data structures, so copy-on-write isn?t an issue. That sounds like a lot of work ? I have no idea whether it?s practical. It has been mentioned in the ?A better story? discussion, but I wanted to bring it up again in the context of my specific use-case. Also, it seems worth reiterating that even though copy-on-write forking is a Unix thing, the midipix project appears to bring it to Windows as well. (http://midipix.org)
>
> 2) Have a mode where a particular data structure is not reference counted or garbage collected. The programmer would be entirely responsible for manually calling del on the structure if he wants to free that memory. I would imagine this would be controversial because Python is currently designed in a very different way. However, I see no actual risk if one were to use an @manual_memory_management decorator or some technique like that to make it very clear that the programmer is taking responsibility. I.e., in general, information sharing between subinterpreters would occur through message passing. But there would be the option of the programmer taking responsibility of memory management for a particular structure. In my case, the amount of work required for this would have been approximately zero ? once the structure was created, it was needed for the lifetime of the process.

I guess a third possible solution, although it would probably have
meant developing something for yourself which would have hit the same
"programmer time is critical" issue that you noted originally, would
be to create a module that managed the data structure in shared
memory, and then use that to access the data from the multiple
processes. If your data structure is generic enough, you could make
such a module generally usable - or there may even be something
available already... I know you said that putting the data into a
database would be too slow, but how about an in-memory Sqlite database
(using shared memory so that there was only one copy for all
processes)?

Your suggestion (2), of having a non-refcounted data structure is
essentially this, doable as an extension module. The core data
structures all use refcounting, and that's unlikely to change, but
there's nothing to say that an extension module couldn't implement
fast data structures with objects allocated from a pool of
preallocated memory which is only freed as a complete block.

These suggestions are probably more suitable for python-list, though,
as (unlike your comment on non-refcounted core data structures) they
are things you can do in current versions of Python.

Paul

From bcannon at gmail.com  Tue Sep  8 18:59:30 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Tue, 08 Sep 2015 16:59:30 +0000
Subject: [Python-Dev] Choosing an official stance towards module deprecation
	in Python 3
Message-ID: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>

There are two discussions going on in the issue tracker about deprecating
some modules and it has led to the inevitable discussion of Python 2/3
compatibility (I'm not even going to bother mentioning the issue #s as this
thread is not about the modules specifically but module deprecation in
general). Because I'm tired of rehashing the same discussion every time a
module deprecation comes up I would like to make an official decision that
we can follow any time we decide to deprecate a module.

The approaches to module deprecation I have seen are:
1. Nothing changes to the deprecation process; you deprecate a module and
remove it in one to two releases
2. Deprecate the module but with no plans for removal until Python 2.7
reaches its EOL (I have been calling this Python 4)
3. Document the deprecation but no actual code deprecation

I'm personally in the #2 camp. I want users to be fully aware that the
module in question is not being updated and possibly not even getting
non-critical bugfixes, but it's still there in Python 3 in order to make
sure that you can have code which straddles Python 2 & 3 more easily.

I don't like #1 because when the module exists in python 2.7 as it makes
transitioning from Python 2 a bit harder. Leaving code in the stdlib as
deprecated isn't going to kill us, especially if we make it clear the code
only exists for transitioning purposes and you very well may have to work
around any bugs you come across (and yes, this means changing my stance for
the formatter module's deprecation).

I don't like #3 because if you have an API memorized or you copied some
code you found online you very well may not realize a module is deprecated.
It's not difficult to silence a deprecation warning and you can make it so
that even if you use -Werror your deprecated module imports continue to
work without throwing an exception while all other deprecations do throw an
exception.

Whatever decision we come to I will update PEP 4 and then personally go
through the various deprecated modules in Python 3.6 and tweak them as
necessary to follow whatever policy we come up with.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/bca71de7/attachment.html>

From guido at python.org  Tue Sep  8 19:02:55 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 8 Sep 2015 10:02:55 -0700
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
Message-ID: <CAP7+vJ+AA=_GM1cxNEjz=x5PFgybjwP4HsW_Vf2wwjGHOJtjnw@mail.gmail.com>

#2 sounds fine to me.

On Tue, Sep 8, 2015 at 9:59 AM, Brett Cannon <bcannon at gmail.com> wrote:

> There are two discussions going on in the issue tracker about deprecating
> some modules and it has led to the inevitable discussion of Python 2/3
> compatibility (I'm not even going to bother mentioning the issue #s as this
> thread is not about the modules specifically but module deprecation in
> general). Because I'm tired of rehashing the same discussion every time a
> module deprecation comes up I would like to make an official decision that
> we can follow any time we decide to deprecate a module.
>
> The approaches to module deprecation I have seen are:
> 1. Nothing changes to the deprecation process; you deprecate a module and
> remove it in one to two releases
> 2. Deprecate the module but with no plans for removal until Python 2.7
> reaches its EOL (I have been calling this Python 4)
> 3. Document the deprecation but no actual code deprecation
>
> I'm personally in the #2 camp. I want users to be fully aware that the
> module in question is not being updated and possibly not even getting
> non-critical bugfixes, but it's still there in Python 3 in order to make
> sure that you can have code which straddles Python 2 & 3 more easily.
>
> I don't like #1 because when the module exists in python 2.7 as it makes
> transitioning from Python 2 a bit harder. Leaving code in the stdlib as
> deprecated isn't going to kill us, especially if we make it clear the code
> only exists for transitioning purposes and you very well may have to work
> around any bugs you come across (and yes, this means changing my stance for
> the formatter module's deprecation).
>
> I don't like #3 because if you have an API memorized or you copied some
> code you found online you very well may not realize a module is deprecated.
> It's not difficult to silence a deprecation warning and you can make it so
> that even if you use -Werror your deprecated module imports continue to
> work without throwing an exception while all other deprecations do throw an
> exception.
>
> Whatever decision we come to I will update PEP 4 and then personally go
> through the various deprecated modules in Python 3.6 and tweak them as
> necessary to follow whatever policy we come up with.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/94a2d096/attachment.html>

From garyrob at me.com  Tue Sep  8 19:07:18 2015
From: garyrob at me.com (Gary Robinson)
Date: Tue, 08 Sep 2015 13:07:18 -0400
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
 comment
In-Reply-To: <CACac1F8Rasijzyq-b5qtrwHKSviJJw96ryJWNwQCGMEefsZ-zA@mail.gmail.com>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
 <CACac1F8Rasijzyq-b5qtrwHKSviJJw96ryJWNwQCGMEefsZ-zA@mail.gmail.com>
Message-ID: <D7302E7A-2907-426B-A39A-EC9DC96C106A@me.com>

> I guess a third possible solution, although it would probably have
> meant developing something for yourself which would have hit the same
> "programmer time is critical" issue that you noted originally, would
> be to create a module that managed the data structure in shared
> memory, and then use that to access the data from the multiple
> processes.

I think you mean, write a non-python data structure in shared memory, such as writing it in C? If so, you?re right, I want to avoid the time overhead for writing something like that. Although I have used C data in shared-memory in the past when the data structure was simple enough. It?s not a foreign concept to me ? it just would have been a real nuisance in this case.

An in-memory SQLLite database would have been too slow, at least if I used any kind of ORM. Without an ORM it still would have slowed things down while making for code that?s harder to read  and write. While I have used in-memory SQLite code at times, I?m not sure how much slowdown it would have engendered in this case. 

> Your suggestion (2), of having a non-refcounted data structure is
> essentially this, doable as an extension module. The core data
> structures all use refcounting, and that's unlikely to change, but
> there's nothing to say that an extension module couldn't implement
> fast data structures with objects allocated from a pool of
> preallocated memory which is only freed as a complete block.

Again, I think you?re talking about non-Python data structures, for instance C structures, which could be written to be ?fast?? Again, I want to avoid writing that kind of code. Sure, for a production project where I had more programmer time, that would be a solution, but that wasn?t my situation. And, ideally, even if I had more time, I would greatly prefer not to have to spend it on that kind of code. I like Python because it saves me time and eliminates potential bugs that are associated with language like C but not with Python (primarily memory management related). To the extent that I have to write and debug external modules in C or C++, it doesn?t.

But, my view is: I shouldn?t be forced to even think about that kind of thing. Python should simply provide a solution. The fact that the reference counters are mixed in with the data structure, so that copy-on-write causes copies to be made of the data structure shouldn?t be something I should have to discover by trial and error, or by having deep knowledge of language and OS internals before I start a project, and then have to try to find a way to work around.

Obviously, Python, like any language, will always have limitations, and therefore it?s arguable that no one should say that any language ?should? do anything it doesn?t do; if I don?t like it, I can use a more appropriate language. 

But these limitations aren?t obvious up-front. They make the language less predictable to people who don?t have a deep knowledge and just want to get something done and think Python (especially combined with things like SciPy) looks like a great choice to do them. And that confusion and uncertainty has to be bad for general language acceptance. I don?t see it as  ?PR issue? ? I see it as a practical issue having to do with the cost of knowledge acquisition. Indeed, I personally lost a lot of time because I didn?t understand them upfront!

Solving the problem I mention here would provide real benefits even with the current multiprocessing module. But it would also make the ?A better story? subinterpreter idea a better solution than it would be without it. The subinterpreter multi-core solution is a major project ? it seems like it would be a shame to create that solution and still have it not solve the problem discussed here.

Anyway, too much of this post is probably spent proseletyzing for my point of view. Members of python-dev can judge it as they think fit ? I don?t have much more to say unless anyone has questions.

But if I?m missing something about the solutions mentioned by Paul, and they can be implemented in pure Python, I would be much appreciative if that could be explained!

Thanks,
Gary




-- 

Gary Robinson
garyrob at me.com
http://www.garyrobinson.net

> On Sep 8, 2015, at 11:44 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
> On 8 September 2015 at 15:12, Gary Robinson <garyrob at me.com> wrote:
>> So, one thing I am hoping comes out of any effort in the ?A better story? direction would be a way to share large data structures between processes. Two possible solutions:
>> 
>> 1) More the reference counts away from data structures, so copy-on-write isn?t an issue. That sounds like a lot of work ? I have no idea whether it?s practical. It has been mentioned in the ?A better story? discussion, but I wanted to bring it up again in the context of my specific use-case. Also, it seems worth reiterating that even though copy-on-write forking is a Unix thing, the midipix project appears to bring it to Windows as well. (http://midipix.org)
>> 
>> 2) Have a mode where a particular data structure is not reference counted or garbage collected. The programmer would be entirely responsible for manually calling del on the structure if he wants to free that memory. I would imagine this would be controversial because Python is currently designed in a very different way. However, I see no actual risk if one were to use an @manual_memory_management decorator or some technique like that to make it very clear that the programmer is taking responsibility. I.e., in general, information sharing between subinterpreters would occur through message passing. But there would be the option of the programmer taking responsibility of memory management for a particular structure. In my case, the amount of work required for this would have been approximately zero ? once the structure was created, it was needed for the lifetime of the process.
> 
> I guess a third possible solution, although it would probably have
> meant developing something for yourself which would have hit the same
> "programmer time is critical" issue that you noted originally, would
> be to create a module that managed the data structure in shared
> memory, and then use that to access the data from the multiple
> processes. If your data structure is generic enough, you could make
> such a module generally usable - or there may even be something
> available already... I know you said that putting the data into a
> database would be too slow, but how about an in-memory Sqlite database
> (using shared memory so that there was only one copy for all
> processes)?
> 
> Your suggestion (2), of having a non-refcounted data structure is
> essentially this, doable as an extension module. The core data
> structures all use refcounting, and that's unlikely to change, but
> there's nothing to say that an extension module couldn't implement
> fast data structures with objects allocated from a pool of
> preallocated memory which is only freed as a complete block.
> 
> These suggestions are probably more suitable for python-list, though,
> as (unlike your comment on non-refcounted core data structures) they
> are things you can do in current versions of Python.
> 
> Paul


From donald at stufft.io  Tue Sep  8 19:08:06 2015
From: donald at stufft.io (Donald Stufft)
Date: Tue, 8 Sep 2015 13:08:06 -0400
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
Message-ID: <etPan.55ef15f7.4effcab5.31bc@Draupnir.home>

On September 8, 2015 at 1:01:14 PM, Brett Cannon (bcannon at gmail.com) wrote:
> 
> The approaches to module deprecation I have seen are:
> 1. Nothing changes to the deprecation process; you deprecate a module and
> remove it in one to two releases
> 2. Deprecate the module but with no plans for removal until Python 2.7
> reaches its EOL (I have been calling this Python 4)
> 3. Document the deprecation but no actual code deprecation
> 

A riff on #1, is that it gets packaged up separately and released on PyPI, this
is basically what Django did when it removed django.contrib.comments from
Django. This kind of walks a line between 1 and 2 where the module is no longer
in the standard library, but if people are actually using those things, then
they are a fairly easy ``pip install`` away. This obviously only works for
"leaf" modules that don't have other parts of the standard library depending on
them, but #1 wouldn't work fo those anyways.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



From laxmikant.general at gmail.com  Tue Sep  8 19:08:16 2015
From: laxmikant.general at gmail.com (Laxmikant Chitare)
Date: Tue, 8 Sep 2015 22:38:16 +0530
Subject: [Python-Dev] What's New editing
In-Reply-To: <55EB5CFB.1030300@gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
 <55E7AA86.7020504@gmail.com>
 <CAEbHw4Y42n5ugU-aO9jcdvRje6DA6SeK-LSOWoFQGCSOKefnBA@mail.gmail.com>
 <55EB2F00.4080703@gmail.com>
 <CAP7+vJJuQvcU1jhpOWk39gkWD=6NperXedN-ebNT8pX566z5YQ@mail.gmail.com>
 <55EB5CFB.1030300@gmail.com>
Message-ID: <CAFtnWG8pZc=1bzMpGSxNrFz7Txut4SOZe69QgSfPOM+DX5JjXA@mail.gmail.com>

Hi Team Python,

It is really nice, motivating and encouraging to see people contribute to
community in spite of the work load. "Thank you" is just not enough to
appreciate your efforts. I have been programming in Python for quite some
time and I am loving it more as days pass by. I have been thinking of
contributing to the community but not sure how and where to start. Of
course my employer will never allow me do this as paid time, but I can take
out about an hour a day on my own. Can someone guide me how can I utilize
this time for the community?

Best regards,
Laxmikant

On Sun, Sep 6, 2015 at 2:52 AM, Yury Selivanov <yselivanov.ml at gmail.com>
wrote:

>
> On 2015-09-05 2:23 PM, Guido van Rossum wrote:
>
>>
>> Awesome! We need more people with those skills!
>>
>> --Guido (on mobile)
>>
>>
> Great, we'll start today!
>
> Thanks,
> Yury
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/laxmikant.general%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/b343c674/attachment.html>

From rosuav at gmail.com  Tue Sep  8 19:15:39 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 9 Sep 2015 03:15:39 +1000
Subject: [Python-Dev] What's New editing
In-Reply-To: <CAFtnWG8pZc=1bzMpGSxNrFz7Txut4SOZe69QgSfPOM+DX5JjXA@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
 <55E7AA86.7020504@gmail.com>
 <CAEbHw4Y42n5ugU-aO9jcdvRje6DA6SeK-LSOWoFQGCSOKefnBA@mail.gmail.com>
 <55EB2F00.4080703@gmail.com>
 <CAP7+vJJuQvcU1jhpOWk39gkWD=6NperXedN-ebNT8pX566z5YQ@mail.gmail.com>
 <55EB5CFB.1030300@gmail.com>
 <CAFtnWG8pZc=1bzMpGSxNrFz7Txut4SOZe69QgSfPOM+DX5JjXA@mail.gmail.com>
Message-ID: <CAPTjJmq8N_aUmuevWDVzY61EdmT5K9TohMde9s_BpF0B5JMwSw@mail.gmail.com>

On Wed, Sep 9, 2015 at 3:08 AM, Laxmikant Chitare
<laxmikant.general at gmail.com> wrote:
>
> It is really nice, motivating and encouraging to see people contribute to
> community in spite of the work load. "Thank you" is just not enough to
> appreciate your efforts. I have been programming in Python for quite some
> time and I am loving it more as days pass by. I have been thinking of
> contributing to the community but not sure how and where to start. Of course
> my employer will never allow me do this as paid time, but I can take out
> about an hour a day on my own. Can someone guide me how can I utilize this
> time for the community?

Pick up something that I keep telling myself I'll do more of, and
never seem to do a significant amount of: read through
http://bugs.python.org/ and confirm the unconfirmed, or check that
patches are working correctly, or add patches to things that
definitely need them. Even if you don't know C, there are plenty of
places where you could do that; large slabs of the standard library
are written in Python, and the docs are in a straight-forward markup
language, so docs patches basically just require knowledge of English.

ChrisA

From brett at python.org  Tue Sep  8 19:15:57 2015
From: brett at python.org (Brett Cannon)
Date: Tue, 08 Sep 2015 17:15:57 +0000
Subject: [Python-Dev] What's New editing
In-Reply-To: <CAFtnWG8pZc=1bzMpGSxNrFz7Txut4SOZe69QgSfPOM+DX5JjXA@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
 <55E7AA86.7020504@gmail.com>
 <CAEbHw4Y42n5ugU-aO9jcdvRje6DA6SeK-LSOWoFQGCSOKefnBA@mail.gmail.com>
 <55EB2F00.4080703@gmail.com>
 <CAP7+vJJuQvcU1jhpOWk39gkWD=6NperXedN-ebNT8pX566z5YQ@mail.gmail.com>
 <55EB5CFB.1030300@gmail.com>
 <CAFtnWG8pZc=1bzMpGSxNrFz7Txut4SOZe69QgSfPOM+DX5JjXA@mail.gmail.com>
Message-ID: <CAP1=2W4NJwDBeNA3ognRvJQmsLw5PcJorGY7_-6f-HYJDJW3Lg@mail.gmail.com>

On Tue, 8 Sep 2015 at 10:11 Laxmikant Chitare <laxmikant.general at gmail.com>
wrote:

> Hi Team Python,
>
> It is really nice, motivating and encouraging to see people contribute to
> community in spite of the work load. "Thank you" is just not enough to
> appreciate your efforts. I have been programming in Python for quite some
> time and I am loving it more as days pass by. I have been thinking of
> contributing to the community but not sure how and where to start. Of
> course my employer will never allow me do this as paid time, but I can take
> out about an hour a day on my own. Can someone guide me how can I utilize
> this time for the community?
>

The easiest way is to read the devguide: https://docs.python.org/devguide/ .
It includes instructions on how you can help, instructions on how to join
the core-mentorship mailing list, etc.

-Brett


>
> Best regards,
> Laxmikant
>
> On Sun, Sep 6, 2015 at 2:52 AM, Yury Selivanov <yselivanov.ml at gmail.com>
> wrote:
>
>>
>> On 2015-09-05 2:23 PM, Guido van Rossum wrote:
>>
>>>
>>> Awesome! We need more people with those skills!
>>>
>>> --Guido (on mobile)
>>>
>>>
>> Great, we'll start today!
>>
>> Thanks,
>> Yury
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>>
> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/laxmikant.general%40gmail.com
>>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/cb7c64a8/attachment.html>

From rdmurray at bitdance.com  Tue Sep  8 19:17:30 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 08 Sep 2015 13:17:30 -0400
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
	comment
In-Reply-To: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
Message-ID: <20150908171730.E85FD1B10005@webabinitio.net>

On Tue, 08 Sep 2015 10:12:37 -0400, Gary Robinson <garyrob at me.com> wrote:
> 2) Have a mode where a particular data structure is not reference
> counted or garbage collected.

This sounds kind of like what Trent did in PyParallel (in a more generic
way).

--David

From python-dev at mgmiller.net  Tue Sep  8 09:17:38 2015
From: python-dev at mgmiller.net (Mike Miller)
Date: Tue, 8 Sep 2015 00:17:38 -0700
Subject: [Python-Dev] String Interpolation Best Practices
Message-ID: <55EE8B92.401@mgmiller.net>

Hi,

I'd like to collect thinking on best practices that we can use as a style guide 
for string interpolation.  Now that arbitrary expressions are very likely to be 
included, it is more important to set guidelines than it would otherwise be.

Below is a recent post with some good ideas (though it hopes to restrict 
expressions, which is not what we're discussing here, but rather creation of a 
style-guide for code-review a la PEP8).

Would anyone else like to contribute?

-Mike

Recent posts:

- On PEPs to augment PEP8:

     https://mail.python.org/pipermail/python-dev/2015-September/141473.html

- On things to avoid in f-strings:

     https://mail.python.org/pipermail/python-dev/2015-September/141451.html
     (part included below)


On 09/05/2015 02:10 AM, haypo s (Victor Stinner) wrote:
 > Would it be possible to specify a subset of the Python language
 > allowed in f-string? For example, __import__ or lambda should not be
 > used in a f-string. I'm not convinced that a loop or
 > list/dict/set-comprehension is a good idea neither.
 >
 > I would prefer to keep as much code as possible *outside* f-string because:
 > - text editor knows well how to color it
 > - static analyzers know how to analyze it
 > - it encourage developers to indent and comment their code correctly,
 > whereas f-string has more restrictons on indentation (is it possible
 > to indent and comment code inside a f-string?)
 >
 > For example, for me it's a common practice to write a complex
 > list-comprehension on two lines for readability:
 >
 > newlist = [very_complex_expression(item)
 >              for item in oldlist]
 > # sorry, it's hard to indent correctly in a mail client, especially Gmail
 >
 > Well, I'm not convinced that we need a larger subset than what is
 > allowed currently in str.format(), simple expressions like: obj.attr,
 > obj[index], etc.
 >
 > I recall horrible examples in the previous mail threads showing how
 > much complex code you can put inside f-string.
 >
 > Even the following example from the PEP seems too complex to me:
 > print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in
 > valid_opts)}]", file=sys.stderr)
 >
 > Oh, first I read [...] as a list-comprehension :-p But it's part of
 > the output string, not of the Python code...
 >
 > I prefer to build the second parameter outside the f-string:
 > opts = '|'.join('--'+opt for opt in valid_opts)
 > print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)
 >

From python at lucidity.plus.com  Tue Sep  8 12:30:55 2015
From: python at lucidity.plus.com (Erik)
Date: Tue, 8 Sep 2015 11:30:55 +0100
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
Message-ID: <55EEB8DF.3040002@lucidity.plus.com>

Hi.

I realise I'm coming late to the party on this, but I have a question 
about something I don't think the PEP makes clear.



When is the bytecode for the embedded expressions created?



Is it when the source code is parsed, or at runtime when the f-string is 
evaluated?

If the latter, then any process that works on bytecode (introspection 
tools, peep-hole optimisers etc) will need work.

I understand that colorising editors and analysis tools which operate at 
the source code level will need work, that's fair enough.


The PEP hints at things in this area in the "Specification", "Code 
equivalence" and "Expression evaluation" sections, and my guess is that 
it will (and should) happen during parsing, but I can't see where it 
comes right out and says it.

Thanks, E.

From bcannon at gmail.com  Tue Sep  8 19:29:47 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Tue, 08 Sep 2015 17:29:47 +0000
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <etPan.55ef15f7.4effcab5.31bc@Draupnir.home>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
 <etPan.55ef15f7.4effcab5.31bc@Draupnir.home>
Message-ID: <CAP1=2W6pXsChzxK8JEzXv2qrdCt7qLqQVnNxh-qhfT_xVCqa3w@mail.gmail.com>

On Tue, 8 Sep 2015 at 10:08 Donald Stufft <donald at stufft.io> wrote:

> On September 8, 2015 at 1:01:14 PM, Brett Cannon (bcannon at gmail.com)
> wrote:
> >
> > The approaches to module deprecation I have seen are:
> > 1. Nothing changes to the deprecation process; you deprecate a module and
> > remove it in one to two releases
> > 2. Deprecate the module but with no plans for removal until Python 2.7
> > reaches its EOL (I have been calling this Python 4)
> > 3. Document the deprecation but no actual code deprecation
> >
>
> A riff on #1, is that it gets packaged up separately and released on PyPI,
> this
> is basically what Django did when it removed django.contrib.comments from
> Django. This kind of walks a line between 1 and 2 where the module is no
> longer
> in the standard library, but if people are actually using those things,
> then
> they are a fairly easy ``pip install`` away. This obviously only works for
> "leaf" modules that don't have other parts of the standard library
> depending on
> them, but #1 wouldn't work fo those anyways.
>

That is one possibility, but I notice that django.contrib.comments is still
getting updated. For deprecated modules they probably won't even get
bugfixes anymore so I wouldn't want to give the wrong impression the
modules are still being maintained. Plus we would have to figure out who is
in charge of the actual project on PyPI since there isn't a concept of
group ownership.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/387006dd/attachment.html>

From guido at python.org  Tue Sep  8 19:30:28 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 8 Sep 2015 10:30:28 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <55EEB8DF.3040002@lucidity.plus.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <55EEB8DF.3040002@lucidity.plus.com>
Message-ID: <CAP7+vJLUG2TdhLQTq+6wnfZXFEFqyUhOkJCh7Kp5ME1mgbLdcg@mail.gmail.com>

The byte code for the embedded expressions is all produced during the
regular byte code generation phase.

On Tue, Sep 8, 2015 at 3:30 AM, Erik <python at lucidity.plus.com> wrote:

> Hi.
>
> I realise I'm coming late to the party on this, but I have a question
> about something I don't think the PEP makes clear.
>
>
>
> When is the bytecode for the embedded expressions created?
>
>
>
> Is it when the source code is parsed, or at runtime when the f-string is
> evaluated?
>
> If the latter, then any process that works on bytecode (introspection
> tools, peep-hole optimisers etc) will need work.
>
> I understand that colorising editors and analysis tools which operate at
> the source code level will need work, that's fair enough.
>
>
> The PEP hints at things in this area in the "Specification", "Code
> equivalence" and "Expression evaluation" sections, and my guess is that it
> will (and should) happen during parsing, but I can't see where it comes
> right out and says it.
>
> Thanks, E.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/fbc331be/attachment.html>

From guido at python.org  Tue Sep  8 19:32:02 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 8 Sep 2015 10:32:02 -0700
Subject: [Python-Dev] String Interpolation Best Practices
In-Reply-To: <55EE8B92.401@mgmiller.net>
References: <55EE8B92.401@mgmiller.net>
Message-ID: <CAP7+vJ+dG9D_QYvXQgu0xZW8z+YgeCQptPZrLH_Pmi17PFrj2g@mail.gmail.com>

Sounds awfully premature. Style guides are typically updated in response to
the occurrence of bad practice in the wild, not in anticipation of such bad
practice. I would give the users of Python 3.6 some more credit.

On Tue, Sep 8, 2015 at 12:17 AM, Mike Miller <python-dev at mgmiller.net>
wrote:

> Hi,
>
> I'd like to collect thinking on best practices that we can use as a style
> guide for string interpolation.  Now that arbitrary expressions are very
> likely to be included, it is more important to set guidelines than it would
> otherwise be.
>
> Below is a recent post with some good ideas (though it hopes to restrict
> expressions, which is not what we're discussing here, but rather creation
> of a style-guide for code-review a la PEP8).
>
> Would anyone else like to contribute?
>
> -Mike
>
> Recent posts:
>
> - On PEPs to augment PEP8:
>
>
> https://mail.python.org/pipermail/python-dev/2015-September/141473.html
>
> - On things to avoid in f-strings:
>
>
> https://mail.python.org/pipermail/python-dev/2015-September/141451.html
>     (part included below)
>
>
> On 09/05/2015 02:10 AM, haypo s (Victor Stinner) wrote:
> > Would it be possible to specify a subset of the Python language
> > allowed in f-string? For example, __import__ or lambda should not be
> > used in a f-string. I'm not convinced that a loop or
> > list/dict/set-comprehension is a good idea neither.
> >
> > I would prefer to keep as much code as possible *outside* f-string
> because:
> > - text editor knows well how to color it
> > - static analyzers know how to analyze it
> > - it encourage developers to indent and comment their code correctly,
> > whereas f-string has more restrictons on indentation (is it possible
> > to indent and comment code inside a f-string?)
> >
> > For example, for me it's a common practice to write a complex
> > list-comprehension on two lines for readability:
> >
> > newlist = [very_complex_expression(item)
> >              for item in oldlist]
> > # sorry, it's hard to indent correctly in a mail client, especially Gmail
> >
> > Well, I'm not convinced that we need a larger subset than what is
> > allowed currently in str.format(), simple expressions like: obj.attr,
> > obj[index], etc.
> >
> > I recall horrible examples in the previous mail threads showing how
> > much complex code you can put inside f-string.
> >
> > Even the following example from the PEP seems too complex to me:
> > print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in
> > valid_opts)}]", file=sys.stderr)
> >
> > Oh, first I read [...] as a list-comprehension :-p But it's part of
> > the output string, not of the Python code...
> >
> > I prefer to build the second parameter outside the f-string:
> > opts = '|'.join('--'+opt for opt in valid_opts)
> > print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)
> >
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/112ec767/attachment.html>

From brett at python.org  Tue Sep  8 19:32:20 2015
From: brett at python.org (Brett Cannon)
Date: Tue, 08 Sep 2015 17:32:20 +0000
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <55EEB8DF.3040002@lucidity.plus.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <55EEB8DF.3040002@lucidity.plus.com>
Message-ID: <CAP1=2W5S-NU030pWUBJXeaDjMSuXVuTWNjqcMafNK6=Nh4p-sg@mail.gmail.com>

On Tue, 8 Sep 2015 at 10:26 Erik <python at lucidity.plus.com> wrote:

> Hi.
>
> I realise I'm coming late to the party on this, but I have a question
> about something I don't think the PEP makes clear.
>
>
>
> When is the bytecode for the embedded expressions created?


>
>
> Is it when the source code is parsed, or at runtime when the f-string is
> evaluated?
>

It's at compile time.


>
> If the latter, then any process that works on bytecode (introspection
> tools, peep-hole optimisers etc) will need work.
>
> I understand that colorising editors and analysis tools which operate at
> the source code level will need work, that's fair enough.
>
>
> The PEP hints at things in this area in the "Specification", "Code
> equivalence" and "Expression evaluation" sections, and my guess is that
> it will (and should) happen during parsing, but I can't see where it
> comes right out and says it.
>

It doesn't explicitly state it because it's inherent in the fact that it is
implemented in bytecode which is created at compile time for Python source
(typically when a module is imported, but can be when you call compile()).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/ef796718/attachment-0001.html>

From donald at stufft.io  Tue Sep  8 19:35:44 2015
From: donald at stufft.io (Donald Stufft)
Date: Tue, 8 Sep 2015 13:35:44 -0400
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <CAP1=2W6pXsChzxK8JEzXv2qrdCt7qLqQVnNxh-qhfT_xVCqa3w@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
 <etPan.55ef15f7.4effcab5.31bc@Draupnir.home>
 <CAP1=2W6pXsChzxK8JEzXv2qrdCt7qLqQVnNxh-qhfT_xVCqa3w@mail.gmail.com>
Message-ID: <etPan.55ef1c70.69713ab5.31bc@Draupnir.home>

On September 8, 2015 at 1:29:58 PM, Brett Cannon (bcannon at gmail.com) wrote:
> 
> That is one possibility, but I notice that django.contrib.comments is still
> getting updated. For deprecated modules they probably won't even get
> bugfixes anymore so I wouldn't want to give the wrong impression the
> modules are still being maintained. Plus we would have to figure out who is
> in charge of the actual project on PyPI since there isn't a concept of
> group ownership.
> 

I don't really much care which way it is done, I was just throwing it out there
as a possibility. Though I think the first problem is solvable by clear
documentation. Actually in Django's case I think it was "Ok we've removed it,
if somebody wants to step up and maintain it they can, otherwise it's going to
wither and die on it's own", but my memory might be faulty. The second problem
is easier, you can add multiple people to a project, and "Organization/Group"
accounts will be something that gets implemented in Warehouse.


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



From srkunze at mail.de  Tue Sep  8 19:44:46 2015
From: srkunze at mail.de (Sven R. Kunze)
Date: Tue, 08 Sep 2015 19:44:46 +0200
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
 comment
In-Reply-To: <20150908171730.E85FD1B10005@webabinitio.net>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
 <20150908171730.E85FD1B10005@webabinitio.net>
Message-ID: <55EF1E8E.2000701@mail.de>

On 08.09.2015 19:17, R. David Murray wrote:
> On Tue, 08 Sep 2015 10:12:37 -0400, Gary Robinson <garyrob at me.com> wrote:
>> 2) Have a mode where a particular data structure is not reference
>> counted or garbage collected.
> This sounds kind of like what Trent did in PyParallel (in a more generic
> way).

Yes, I can recall that from his talk as well.

From stephen at xemacs.org  Tue Sep  8 20:08:23 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 09 Sep 2015 03:08:23 +0900
Subject: [Python-Dev] Yet another "A better story for multi-core
	Python"	comment
In-Reply-To: <20150908171730.E85FD1B10005@webabinitio.net>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
 <20150908171730.E85FD1B10005@webabinitio.net>
Message-ID: <87egi8238o.fsf@uwakimon.sk.tsukuba.ac.jp>

R. David Murray writes:
 > On Tue, 08 Sep 2015 10:12:37 -0400, Gary Robinson <garyrob at me.com> wrote:
 > > 2) Have a mode where a particular data structure is not reference
 > > counted or garbage collected.
 > 
 > This sounds kind of like what Trent did in PyParallel (in a more generic
 > way).

Except Gary has a large persistent data structure, and Trent's only
rule is "don't persist objects you want to operate on in parallel."
The similarity may be purely superficial, though.

@Gary: Justifying your request is unnecessary.  As far as I can see,
everybody acknowledges that "large shared data structure" + "multiple
cores" is something that Python doesn't do well enough in some sense.
It's just a hard problem, and the applications that really need it are
sufficiently specialized that we haven't been able to justify turning
the world upside down to serve them.

Trent seems to be on to something that requires only a bit of a tilt
;-), and despite the caveat above, I agree with David, check it out:

https://mail.python.org/pipermail/python-dev/2015-September/141485.html

From guido at python.org  Tue Sep  8 20:25:09 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 8 Sep 2015 11:25:09 -0700
Subject: [Python-Dev] String Interpolation Best Practices
In-Reply-To: <55EF2742.1090202@mgmiller.net>
References: <55EE8B92.401@mgmiller.net>
 <CAP7+vJ+dG9D_QYvXQgu0xZW8z+YgeCQptPZrLH_Pmi17PFrj2g@mail.gmail.com>
 <55EF2742.1090202@mgmiller.net>
Message-ID: <CAP7+vJKKBoYLkKXYoF9UXFv+0j1Cr+bnmcwTrOZZDQ-yYvi-HA@mail.gmail.com>

I was not asking for style rules. Maybe you're thinking of my encouraging
words regarding turning PEP 502 into an overview of the thinking that led
to PEP 498? Or maybe I wasn't clear enough that that's what I was
encouraging. :-)

On Tue, Sep 8, 2015 at 11:21 AM, Mike Miller <python-ideas at mgmiller.net>
wrote:

> Ok, I thought that's what you and others were asking for in previous
> threads.
>
> -Mike
>
>
>
> On 09/08/2015 10:32 AM, Guido van Rossum wrote:
>
>> Sounds awfully premature. Style guides are typically updated in response
>> to the
>>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/a9fbe9d8/attachment.html>

From python at mrabarnett.plus.com  Tue Sep  8 20:25:39 2015
From: python at mrabarnett.plus.com (MRAB)
Date: Tue, 8 Sep 2015 19:25:39 +0100
Subject: [Python-Dev] Can't install Python 3.5rc3
In-Reply-To: <E1ZZIrd-00019o-CE@se2-syd.hostedmail.net.au>
References: <55EE58AA.40108@mrabarnett.plus.com>
 <E1ZZIrd-00019o-CE@se2-syd.hostedmail.net.au>
Message-ID: <55EF2823.1010802@mrabarnett.plus.com>

On 2015-09-08 14:22, Steve Dower wrote:
 > It thinks you have version 3.5.5339.0 installed, which IIRC was a 
test build I made for some tcl changes. It's probably listed under 
xPython - can you see it?
 >
 > As I said at the time, they should be totally independent, but I 
guess not. Thanks for the heads up.
 >
I purged the xPython bits, but it still wouldn't install.

I then purged the Python3.5dev... bits.

Success!

Rather a messy fix though...

 >
 > From: MRAB
 > Sent: ?9/?7/?2015 20:41
 > To: Python-Dev
 > Subject: [Python-Dev] Can't install Python 3.5rc3
 >
 > I've been unable to install Python 3.5rc3.
 >
 > It progresses to installing Tcl/tk, then reports that a newer version
 > of 3.5 is already installed, then it rolls back (slowly).
 >
 > I don't know where it's finding this "newer version"; I've uninstalled
 > the previous releases of Python 3.5.
 >
 > I'm on Windows 10.
 >
 >
 > Here's the contents of the log file:

[snip]


From tjreedy at udel.edu  Tue Sep  8 20:35:01 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 8 Sep 2015 14:35:01 -0400
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
Message-ID: <msn9pb$kf5$1@ger.gmane.org>

On 9/8/2015 12:59 PM, Brett Cannon wrote:
> There are two discussions going on in the issue tracker about
> deprecating some modules and it has led to the inevitable discussion of
> Python 2/3 compatibility (I'm not even going to bother mentioning the
> issue #s as this thread is not about the modules specifically but module
> deprecation in general). Because I'm tired of rehashing the same
> discussion every time a module deprecation comes up I would like to make
> an official decision that we can follow any time we decide to deprecate
> a module.

Would you consider the 'official decision' as applying to idlelib 
modules?  The issue here is not especially related to 2.7. PEP 434 
formalized the idea that idlelib is mostly private, but acknowledged 
that there might be unauthorized module uses here and there. The first 
example is removing idlelib.idlever, now unused by Idle itself (#21499).

> The approaches to module deprecation I have seen are:
> 1. Nothing changes to the deprecation process; you deprecate a module
> and remove it in one to two releases
> 2. Deprecate the module but with no plans for removal until Python 2.7
> reaches its EOL (I have been calling this Python 4)

For either 1 or 2, the 2.7 code should get a py3 warning.

> 3. Document the deprecation but no actual code deprecation

Number 3 creates a discrepancy between code and doc.  This is normally 
considered a bug, and might be seen as such by someone reading both 
unless a comment were inserted into the code.

> I'm personally in the #2 camp. I want users to be fully aware that the
> module in question is not being updated and possibly not even getting
> non-critical bugfixes, but it's still there in Python 3 in order to make
> sure that you can have code which straddles Python 2 & 3 more easily.

There will be people who convert after 2020, but the final 3.x before 
removal will always be available.  I also see this as the best of 
imperfect choices.

> I don't like #1 because when the module exists in python 2.7 as it makes
> transitioning from Python 2 a bit harder. Leaving code in the stdlib as
> deprecated isn't going to kill us, especially if we make it clear the
> code only exists for transitioning purposes and you very well may have
> to work around any bugs you come across (and yes, this means changing my
> stance for the formatter module's deprecation).

Idlelib currently has about 6 module-naming conventions, and it was 
omitted from the 3.0 renaming. Even without an immediate mass PEP8 
rename (#24225), which would help Idle maintenance, new files from 
refactoring and ttk conversions will result in a large number of 
eventually unused old files. I would prefer to remove them before 2020.

> I don't like #3 because if you have an API memorized or you copied some
> code you found online you very well may not realize a module is
> deprecated. It's not difficult to silence a deprecation warning and you
> can make it so that even if you use -Werror your deprecated module
> imports continue to work without throwing an exception while all other
> deprecations do throw an exception.
>
> Whatever decision we come to I will update PEP 4 and then personally go
> through the various deprecated modules in Python 3.6 and tweak them as
> necessary to follow whatever policy we come up with.

-- 
Terry Jan Reedy


From brett at python.org  Tue Sep  8 20:56:44 2015
From: brett at python.org (Brett Cannon)
Date: Tue, 08 Sep 2015 18:56:44 +0000
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <msn9pb$kf5$1@ger.gmane.org>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
 <msn9pb$kf5$1@ger.gmane.org>
Message-ID: <CAP1=2W5+k6X6Jh1+-gjj5qXgV=5BZn9aPvdU+eDxaCSphvnnzw@mail.gmail.com>

On Tue, 8 Sep 2015 at 11:36 Terry Reedy <tjreedy at udel.edu> wrote:

> On 9/8/2015 12:59 PM, Brett Cannon wrote:
> > There are two discussions going on in the issue tracker about
> > deprecating some modules and it has led to the inevitable discussion of
> > Python 2/3 compatibility (I'm not even going to bother mentioning the
> > issue #s as this thread is not about the modules specifically but module
> > deprecation in general). Because I'm tired of rehashing the same
> > discussion every time a module deprecation comes up I would like to make
> > an official decision that we can follow any time we decide to deprecate
> > a module.
>
> Would you consider the 'official decision' as applying to idlelib
> modules?  The issue here is not especially related to 2.7. PEP 434
> formalized the idea that idlelib is mostly private, but acknowledged
> that there might be unauthorized module uses here and there. The first
> example is removing idlelib.idlever, now unused by Idle itself (#21499).
>

I consider IDLE so far outside the normal process of everything when it
comes to stdlib that it is exempt from everything so I don't care if you
take a module out completely.


>
> > The approaches to module deprecation I have seen are:
> > 1. Nothing changes to the deprecation process; you deprecate a module
> > and remove it in one to two releases
> > 2. Deprecate the module but with no plans for removal until Python 2.7
> > reaches its EOL (I have been calling this Python 4)
>
> For either 1 or 2, the 2.7 code should get a py3 warning.
>

I think that's redundant. People who need to run in both Python 2 and 3
will see the warning under Python 3. I view Py3kWarning for things that
would pass silently otherwise or have an odd error message under Python 3.
In this case the message will be clear in Python 3 and thus not a problem.


>
> > 3. Document the deprecation but no actual code deprecation
>
> Number 3 creates a discrepancy between code and doc.  This is normally
> considered a bug, and might be seen as such by someone reading both
> unless a comment were inserted into the code.
>
> > I'm personally in the #2 camp. I want users to be fully aware that the
> > module in question is not being updated and possibly not even getting
> > non-critical bugfixes, but it's still there in Python 3 in order to make
> > sure that you can have code which straddles Python 2 & 3 more easily.
>
> There will be people who convert after 2020, but the final 3.x before
> removal will always be available.  I also see this as the best of
> imperfect choices.
>

Yep. And people who want to see the modules to continue to exist can take
the modules and either vendor them or develop their own group of developers
around it and continue their maintenance outside of the stdlib.

-Brett


>
> > I don't like #1 because when the module exists in python 2.7 as it makes
> > transitioning from Python 2 a bit harder. Leaving code in the stdlib as
> > deprecated isn't going to kill us, especially if we make it clear the
> > code only exists for transitioning purposes and you very well may have
> > to work around any bugs you come across (and yes, this means changing my
> > stance for the formatter module's deprecation).
>
> Idlelib currently has about 6 module-naming conventions, and it was
> omitted from the 3.0 renaming. Even without an immediate mass PEP8
> rename (#24225), which would help Idle maintenance, new files from
> refactoring and ttk conversions will result in a large number of
> eventually unused old files. I would prefer to remove them before 2020.
>
> > I don't like #3 because if you have an API memorized or you copied some
> > code you found online you very well may not realize a module is
> > deprecated. It's not difficult to silence a deprecation warning and you
> > can make it so that even if you use -Werror your deprecated module
> > imports continue to work without throwing an exception while all other
> > deprecations do throw an exception.
> >
> > Whatever decision we come to I will update PEP 4 and then personally go
> > through the various deprecated modules in Python 3.6 and tweak them as
> > necessary to follow whatever policy we come up with.
>
> --
> Terry Jan Reedy
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/c95d3b92/attachment.html>

From barry at python.org  Tue Sep  8 20:57:39 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 8 Sep 2015 14:57:39 -0400
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <CAP7+vJ+AA=_GM1cxNEjz=x5PFgybjwP4HsW_Vf2wwjGHOJtjnw@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
 <CAP7+vJ+AA=_GM1cxNEjz=x5PFgybjwP4HsW_Vf2wwjGHOJtjnw@mail.gmail.com>
Message-ID: <20150908145739.304b56e2@limelight.wooz.org>

On Sep 08, 2015, at 10:02 AM, Guido van Rossum wrote:

>#2 sounds fine to me.

Agreed.
-Barry

From python-ideas at mgmiller.net  Tue Sep  8 20:21:54 2015
From: python-ideas at mgmiller.net (Mike Miller)
Date: Tue, 8 Sep 2015 11:21:54 -0700
Subject: [Python-Dev] String Interpolation Best Practices
In-Reply-To: <CAP7+vJ+dG9D_QYvXQgu0xZW8z+YgeCQptPZrLH_Pmi17PFrj2g@mail.gmail.com>
References: <55EE8B92.401@mgmiller.net>
 <CAP7+vJ+dG9D_QYvXQgu0xZW8z+YgeCQptPZrLH_Pmi17PFrj2g@mail.gmail.com>
Message-ID: <55EF2742.1090202@mgmiller.net>

Ok, I thought that's what you and others were asking for in previous threads.

-Mike


On 09/08/2015 10:32 AM, Guido van Rossum wrote:
> Sounds awfully premature. Style guides are typically updated in response to the

From python-ideas at mgmiller.net  Tue Sep  8 20:40:03 2015
From: python-ideas at mgmiller.net (Mike Miller)
Date: Tue, 8 Sep 2015 11:40:03 -0700
Subject: [Python-Dev] String Interpolation Best Practices
In-Reply-To: <CAP7+vJKKBoYLkKXYoF9UXFv+0j1Cr+bnmcwTrOZZDQ-yYvi-HA@mail.gmail.com>
References: <55EE8B92.401@mgmiller.net>
 <CAP7+vJ+dG9D_QYvXQgu0xZW8z+YgeCQptPZrLH_Pmi17PFrj2g@mail.gmail.com>
 <55EF2742.1090202@mgmiller.net>
 <CAP7+vJKKBoYLkKXYoF9UXFv+0j1Cr+bnmcwTrOZZDQ-yYvi-HA@mail.gmail.com>
Message-ID: <55EF2B83.2040207@mgmiller.net>

Perhaps, here is my mention of it yesterday and response:

     https://mail.python.org/pipermail/python-dev/2015-September/141487.html

Some have been asking for guidance on the subject though (see other links in 
this thread).  Maybe style-guide is the wrong terminology, but the idea wasn't 
intended to be insulting, haha.

I'll drop it and cut down PEP 502 a bit.  It is the easiest path for me, so no 
complaints.

-Mike


On 09/08/2015 11:25 AM, Guido van Rossum wrote:
> I was not asking for style rules. Maybe you're thinking of my encouraging words
> regarding turning PEP 502 into an overview of the thinking that led to PEP 498?
> Or maybe I wasn't clear enough that that's what I was encouraging. :-)
>
> On Tue, Sep 8, 2015 at 11:21 AM, Mike Miller <python-ideas at mgmiller.net
> <mailto:python-ideas at mgmiller.net>> wrote:
>
>     Ok, I thought that's what you and others were asking for in previous threads.
>
>     -Mike
>
>
>
>     On 09/08/2015 10:32 AM, Guido van Rossum wrote:
>
>         Sounds awfully premature. Style guides are typically updated in response
>         to the
>

From garyrob at me.com  Tue Sep  8 21:58:52 2015
From: garyrob at me.com (Gary Robinson)
Date: Tue, 08 Sep 2015 15:58:52 -0400
Subject: [Python-Dev] Yet another "A better story for multi-core
	Python"	comment
Message-ID: <D45A1D59-5090-494D-9518-FCB498E9869E@me.com>

> 
> Trent seems to be on to something that requires only a bit of a tilt
> ;-), and despite the caveat above, I agree with David, check it out:

I emailed with Trent a couple years ago about this very topic. The biggest issue for me was that it was Windows-only, but it sounds like that restriction may be getting closer to possibly going away? (?)



-- 

Gary Robinson
garyrob at me.com
http://www.garyrobinson.net


From jsbueno at python.org.br  Tue Sep  8 22:56:39 2015
From: jsbueno at python.org.br (Joao S. O. Bueno)
Date: Tue, 8 Sep 2015 17:56:39 -0300
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
	comment
In-Reply-To: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
Message-ID: <CAH0mxTTE0Wrfexdzyi7_KJRdjd_1NJONC08DMbn8WCovuD2hpw@mail.gmail.com>

Maybe you just have a job for Cap'n'proto?
https://capnproto.org/

On 8 September 2015 at 11:12, Gary Robinson <garyrob at me.com> wrote:
> Folks,
>
> If it?s out of line in some way for me to make this comment on this list, let me know and I?ll stop! But I do feel strongly about one issue and think it?s worth mentioning, so here goes.
>
> I read the "A better story for multi-core Python? with great interest because the GIL has actually been a major hindrance to me. I know that for many uses, it?s a non-issue. But it was for me.
>
> My situation was that I had a huge (technically mutable, but unchanging) data structure which needed a lot of analysis. CPU time was a major factor ? things took days to run. But even so, my time as a programmer was much more important than CPU time. I needed to prototype different algorithms very quickly. Even Cython would have slowed me down too much. Also, I had a lot of reason to want to make use of the many great statistical functions in SciPy, so Python was an excellent choice for me in that way.
>
> So, even though pure Python might not be the right choice for this program in a production environment, it was the right choice for me at the time. And, if I could have accessed as many cores as I wanted, it may have been good enough in production too. But my work was hampered by one thing:
>
> There was a huge data structure that all the analysis needed to access. Using a database would have slowed things down too much. Ideally, I needed to access this same structure from many cores at once. On a Power8 system, for example, with its larger number of cores, performance may well have been good enough for production. In any case, my experimentation and prototyping would have gone more quickly with more cores.
>
> But this data structure was simply too big. Replicating it in different processes used memory far too quickly and was the limiting factor on the number of cores I could use. (I could fork with the big data structure already in memory, but copy-on-write issues due to reference counting caused multiple copies to exist anyway.)
>
> So, one thing I am hoping comes out of any effort in the ?A better story? direction would be a way to share large data structures between processes. Two possible solutions:
>
> 1) More the reference counts away from data structures, so copy-on-write isn?t an issue. That sounds like a lot of work ? I have no idea whether it?s practical. It has been mentioned in the ?A better story? discussion, but I wanted to bring it up again in the context of my specific use-case. Also, it seems worth reiterating that even though copy-on-write forking is a Unix thing, the midipix project appears to bring it to Windows as well. (http://midipix.org)
>
> 2) Have a mode where a particular data structure is not reference counted or garbage collected. The programmer would be entirely responsible for manually calling del on the structure if he wants to free that memory. I would imagine this would be controversial because Python is currently designed in a very different way. However, I see no actual risk if one were to use an @manual_memory_management decorator or some technique like that to make it very clear that the programmer is taking responsibility. I.e., in general, information sharing between subinterpreters would occur through message passing. But there would be the option of the programmer taking responsibility of memory management for a particular structure. In my case, the amount of work required for this would have been approximately zero ? once the structure was created, it was needed for the lifetime of the process.
>
> Under this second solution, there would be little need to actually remove the reference counts from the data structures ? they just wouldn?t be accessed. Maybe it?s not a practical solution, if only because of the overhead of Python needing to check whether a given structure is manually managed or not. In that case, the first solution makes more sense.
>
> In any case I thought this was worth mentioning,  because it has been a real problem for me, and I assume it has been a real problem for other people as well. If a solution is both possible and practical, that would be great.
>
> Thank you for listening,
> Gary
>
>
> --
>
> Gary Robinson
> garyrob at me.com
> http://www.garyrobinson.net
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br

From cwillu at cwillu.com  Tue Sep  8 23:02:20 2015
From: cwillu at cwillu.com (cwillu)
Date: Tue, 8 Sep 2015 15:02:20 -0600
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
	comment
In-Reply-To: <D7302E7A-2907-426B-A39A-EC9DC96C106A@me.com>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
 <CACac1F8Rasijzyq-b5qtrwHKSviJJw96ryJWNwQCGMEefsZ-zA@mail.gmail.com>
 <D7302E7A-2907-426B-A39A-EC9DC96C106A@me.com>
Message-ID: <CAE5mzvhbfMHjq=+2cwtW6RUs9wZc4o7vXbQCsgqwG0TM-KL4zA@mail.gmail.com>

On 8 September 2015 at 11:07, Gary Robinson <garyrob at me.com> wrote:
>> I guess a third possible solution, although it would probably have
>> meant developing something for yourself which would have hit the same
>> "programmer time is critical" issue that you noted originally, would
>> be to create a module that managed the data structure in shared
>> memory, and then use that to access the data from the multiple
>> processes.
>
> I think you mean, write a non-python data structure in shared memory, such as writing it in C? If so, you?re right, I want to avoid the time overhead for writing something like that. Although I have used C data in shared-memory in the past when the data structure was simple enough. It?s not a foreign concept to me ? it just would have been a real nuisance in this case.
>
> An in-memory SQLLite database would have been too slow, at least if I used any kind of ORM. Without an ORM it still would have slowed things down while making for code that?s harder to read  and write. While I have used in-memory SQLite code at times, I?m not sure how much slowdown it would have engendered in this case.
>
>> Your suggestion (2), of having a non-refcounted data structure is
>> essentially this, doable as an extension module. The core data
>> structures all use refcounting, and that's unlikely to change, but
>> there's nothing to say that an extension module couldn't implement
>> fast data structures with objects allocated from a pool of
>> preallocated memory which is only freed as a complete block.
>
> Again, I think you?re talking about non-Python data structures, for instance C structures, which could be written to be ?fast?? Again, I want to avoid writing that kind of code. Sure, for a production project where I had more programmer time, that would be a solution, but that wasn?t my situation. And, ideally, even if I had more time, I would greatly prefer not to have to spend it on that kind of code. I like Python because it saves me time and eliminates potential bugs that are associated with language like C but not with Python (primarily memory management related). To the extent that I have to write and debug external modules in C or C++, it doesn?t.

I've used cffi to good effect to gain some of the benefits of the
"share a lump of memory" model.

From guido at python.org  Wed Sep  9 02:27:53 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 8 Sep 2015 17:27:53 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
	pronouncement
In-Reply-To: <CAP1=2W5S-NU030pWUBJXeaDjMSuXVuTWNjqcMafNK6=Nh4p-sg@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <55EEB8DF.3040002@lucidity.plus.com>
 <CAP1=2W5S-NU030pWUBJXeaDjMSuXVuTWNjqcMafNK6=Nh4p-sg@mail.gmail.com>
Message-ID: <CAP7+vJKv0b+h5Rv4v7mjy5wbCbAjeytaU6dfR4+wgh+JLfCPpQ@mail.gmail.com>

I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who
contributed. A lot of thought and discussion went into this -- Eric himself
was against the idea when it first came up!

For those wondering about the fate of PEPs 501 and 502: 501 will be
deferred, and 502 will be turned into an informational PEP with background
information on string interpolation across the ages (so to speak :-).
Thanks to Nick Coghlan and Mike Miller for being good sports about it, and
for contributing valuable tire-kicking and devil's advocacy of PEP 498.

Now if only PEP 495 could be as easy... :-)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/4fcd1027/attachment.html>

From eric at trueblade.com  Wed Sep  9 02:37:17 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Tue, 8 Sep 2015 20:37:17 -0400
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <CAP7+vJKv0b+h5Rv4v7mjy5wbCbAjeytaU6dfR4+wgh+JLfCPpQ@mail.gmail.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <55EEB8DF.3040002@lucidity.plus.com>
 <CAP1=2W5S-NU030pWUBJXeaDjMSuXVuTWNjqcMafNK6=Nh4p-sg@mail.gmail.com>
 <CAP7+vJKv0b+h5Rv4v7mjy5wbCbAjeytaU6dfR4+wgh+JLfCPpQ@mail.gmail.com>
Message-ID: <55EF7F3D.2060206@trueblade.com>

On 9/8/2015 8:27 PM, Guido van Rossum wrote:
> I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who
> contributed. A lot of thought and discussion went into this -- Eric
> himself was against the idea when it first came up!

Thanks, Guido. In the next few days I'll update the implementation in
issue 24965 to reflect some changes in the PEP.

Thanks to Mike, Nick, Guido, and everyone else who helped improve the PEP.

Eric.


From python-ideas at mgmiller.net  Wed Sep  9 05:02:30 2015
From: python-ideas at mgmiller.net (Mike Miller)
Date: Tue, 8 Sep 2015 20:02:30 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <55EF7F3D.2060206@trueblade.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <55EEB8DF.3040002@lucidity.plus.com>
 <CAP1=2W5S-NU030pWUBJXeaDjMSuXVuTWNjqcMafNK6=Nh4p-sg@mail.gmail.com>
 <CAP7+vJKv0b+h5Rv4v7mjy5wbCbAjeytaU6dfR4+wgh+JLfCPpQ@mail.gmail.com>
 <55EF7F3D.2060206@trueblade.com>
Message-ID: <55EFA146.6060402@mgmiller.net>

Yeah, can't wait to use it!

-Mike


On 09/08/2015 05:37 PM, Eric V. Smith wrote:
> On 9/8/2015 8:27 PM, Guido van Rossum wrote:
>> I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who
>> contributed. A lot of thought and discussion went into this -- Eric
>> himself was against the idea when it first came up!
>
> Thanks, Guido. In the next few days I'll update the implementation in
> issue 24965 to reflect some changes in the PEP.
>
> Thanks to Mike, Nick, Guido, and everyone else who helped improve the PEP.
>
> Eric.
>

From python-ideas at mgmiller.net  Wed Sep  9 06:29:04 2015
From: python-ideas at mgmiller.net (Mike Miller)
Date: Tue, 8 Sep 2015 21:29:04 -0700
Subject: [Python-Dev] PEP 498: Literal String Interpolation is ready for
 pronouncement
In-Reply-To: <55EF7F3D.2060206@trueblade.com>
References: <55EA494D.7090206@trueblade.com>
 <CAP7+vJJ3X+HUuCYDm5aW6HOf2iHdFDU-0sFJpd6huwTHRW9dkA@mail.gmail.com>
 <55EEB8DF.3040002@lucidity.plus.com>
 <CAP1=2W5S-NU030pWUBJXeaDjMSuXVuTWNjqcMafNK6=Nh4p-sg@mail.gmail.com>
 <CAP7+vJKv0b+h5Rv4v7mjy5wbCbAjeytaU6dfR4+wgh+JLfCPpQ@mail.gmail.com>
 <55EF7F3D.2060206@trueblade.com>
Message-ID: <55EFB590.50200@mgmiller.net>

And thanks for making it a reality.  ;)

-Mike

On 09/08/2015 05:37 PM, Eric V. Smith wrote:

From tjreedy at udel.edu  Wed Sep  9 07:33:44 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 9 Sep 2015 01:33:44 -0400
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
	comment
In-Reply-To: <87egi8238o.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
 <20150908171730.E85FD1B10005@webabinitio.net>
 <87egi8238o.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <msogcf$pra$1@ger.gmane.org>

On 9/8/2015 2:08 PM, Stephen J. Turnbull wrote:
> R. David Murray writes:
>   > On Tue, 08 Sep 2015 10:12:37 -0400, Gary Robinson <garyrob at me.com> wrote:
>   > > 2) Have a mode where a particular data structure is not reference
>   > > counted or garbage collected.
>   >
>   > This sounds kind of like what Trent did in PyParallel (in a more generic
>   > way).
>
> Except Gary has a large persistent data structure, and Trent's only
> rule is "don't persist objects you want to operate on in parallel."
> The similarity may be purely superficial, though.

That rule, which includes not modifying persistent data, is only for the 
parallel threads. In his wikipedia search example, the main thread loads 
60 GB of data (and perhaps occasionally updates it) while multiple 
parallel threads, running of multiple cores, search the persistent data 
like busy little bees.

-- 
Terry Jan Reedy


From ncoghlan at gmail.com  Wed Sep  9 08:04:13 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 9 Sep 2015 16:04:13 +1000
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <CAP1=2W5+k6X6Jh1+-gjj5qXgV=5BZn9aPvdU+eDxaCSphvnnzw@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
 <msn9pb$kf5$1@ger.gmane.org>
 <CAP1=2W5+k6X6Jh1+-gjj5qXgV=5BZn9aPvdU+eDxaCSphvnnzw@mail.gmail.com>
Message-ID: <CADiSq7d8GFLHi8C00D=mzHw-1-NBuR63W8P46U=poMw8U2a-EA@mail.gmail.com>

On 9 September 2015 at 04:56, Brett Cannon <brett at python.org> wrote:
> On Tue, 8 Sep 2015 at 11:36 Terry Reedy <tjreedy at udel.edu> wrote:
>> > The approaches to module deprecation I have seen are:
>> > 1. Nothing changes to the deprecation process; you deprecate a module
>> > and remove it in one to two releases
>> > 2. Deprecate the module but with no plans for removal until Python 2.7
>> > reaches its EOL (I have been calling this Python 4)
>>
>> For either 1 or 2, the 2.7 code should get a py3 warning.
>
> I think that's redundant. People who need to run in both Python 2 and 3 will
> see the warning under Python 3. I view Py3kWarning for things that would
> pass silently otherwise or have an odd error message under Python 3. In this
> case the message will be clear in Python 3 and thus not a problem.

I was going to make the same suggestion as Terry, but you're right,
seeing the warning under 3.x will suffice in these cases.

So +1 for simple deprecation without removal until after 2.7 enters
security fix only mode.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From arigo at tunes.org  Wed Sep  9 09:43:30 2015
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 9 Sep 2015 09:43:30 +0200
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
	comment
In-Reply-To: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
Message-ID: <CAMSv6X1QefvMYn+2edpZsV9GFcLmdDLJ6cXGQktVkSoMrp47Bw@mail.gmail.com>

Hi Gary,

On Tue, Sep 8, 2015 at 4:12 PM, Gary Robinson <garyrob at me.com> wrote:
> 1) More the reference counts away from data structures, so copy-on-write isn?t an issue.

A general note about PyPy --- sorry, it probably doesn't help your use
case because SciPy is not supported right now...

Right now, PyPy hits the same problem as CPython, despite not being
based on reference counting, because every major collection needs to
write flag bits inside the header of every object.  However, fixing
this issue is much more straightforward here: there are
well-documented ways that other virtual machines (for other languages)
already do.  Mostly, instead of writing one bit in the GC header, we'd
write one bit in some compact out-of-line array of bits.  Moreover, it
is an issue that we hear about every now and again, so we may
eventually just do it.


A bient?t,

Armin.

From berker.peksag at gmail.com  Wed Sep  9 14:21:23 2015
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Wed, 9 Sep 2015 15:21:23 +0300
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
Message-ID: <CAF4280+nNn_GRSGvfuUhcDdUP6RXtT_QCkibddJaNq57O4aP6w@mail.gmail.com>

On Tue, Sep 8, 2015 at 7:59 PM, Brett Cannon <bcannon at gmail.com> wrote:
> There are two discussions going on in the issue tracker about deprecating
> some modules and it has led to the inevitable discussion of Python 2/3
> compatibility (I'm not even going to bother mentioning the issue #s as this
> thread is not about the modules specifically but module deprecation in
> general). Because I'm tired of rehashing the same discussion every time a
> module deprecation comes up I would like to make an official decision that
> we can follow any time we decide to deprecate a module.
>
> The approaches to module deprecation I have seen are:
> 1. Nothing changes to the deprecation process; you deprecate a module and
> remove it in one to two releases
> 2. Deprecate the module but with no plans for removal until Python 2.7
> reaches its EOL (I have been calling this Python 4)
> 3. Document the deprecation but no actual code deprecation
>
> I'm personally in the #2 camp. I want users to be fully aware that the
> module in question is not being updated and possibly not even getting
> non-critical bugfixes, but it's still there in Python 3 in order to make
> sure that you can have code which straddles Python 2 & 3 more easily.

+1

--Berker

From larry at hastings.org  Wed Sep  9 15:42:02 2015
From: larry at hastings.org (Larry Hastings)
Date: Wed, 9 Sep 2015 06:42:02 -0700
Subject: [Python-Dev] [RELEASED] Python 3.5.0rc4 is now available!
Message-ID: <55F0372A.3050007@hastings.org>



On behalf of the Python development community and the Python 3.5 release 
team, I'm surprised to announce the availability of Python 3.5.0rc4, 
also known as Python 3.5.0 Release Candidate 4.

Python 3.5.0 Release Candidate 3 was only released about a day ago.  
However: during testing, a major regression was discovered, reported on 
the issue tracker as #25027:

    http://bugs.python.org/issue25027

Python 3.5 includes some big changes on how Python is built on Windows.  
One of those changes resulted in Python processes on Windows exceeding 
the maximum number of loadable shared libraries.  As a result Windows 
builds of Python could no longer run major Python software stacks like 
Pandas and Jupyter. Fixing this required non-trivial last-minute changes 
to the Windows build--and those changes need testing.  We therefore 
elected to insert an extra release candidate before the final release, 
to get these changes into your hands as soon as possible, so that 
Windows users could test these changes.

As with all other Python 3.5 releases to date, this is a preview 
release, and its use is not recommended for production settings.  
However, users are encouraged to test with Python 3.5.0rc4, /especially/ 
Windows users who build or make use of numerous external packages.  
(Non-Windows users will find little difference between Python 3.5.0rc3 
and Python 3.5.0rc4.)


You can find Python 3.5.0rc4 here:

     https://www.python.org/downloads/release/python-350rc4/

Windows and Mac users: please read the important platform-specific 
"Notes on this release" section near the end of that page.


Please kick the tires,


//arry/

p.s.  Special thanks from the Python 3.5 release team to Christoph 
Gohlke for the bug report!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150909/f18df8b7/attachment.html>

From p.f.moore at gmail.com  Wed Sep  9 16:30:24 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 9 Sep 2015 15:30:24 +0100
Subject: [Python-Dev] Embedding Python 3.5
Message-ID: <CACac1F-+EQ3OZJJN0nn36qSt6oQVmOUB97p_qQ91UsidF7MOvQ@mail.gmail.com>

First of all, an apology. I know this is probably going to be of
limited interest for many on python-dev, but I'm honestly not sure
where there's a better audience for the question. As it's related to
how people should use the new "embeddable" distribution of Python 3.5,
I'm hoping it's sufficiently relevant - but if not, feel free to
direct me to a better forum.

I've been trying to use the new embeddable distribution to build a
Windows installation of vim that includes a Python interpreter, rather
than relying on the user having a system install of Python on PATH.
This strikes me as precisely the sort of usage that the embeddable
distribution would be great for. And indeed, it works fine for that.
But when it comes to distribution, I have an issue.

The problem is that for vim to find the Python DLL, it needs to be
alongside vim.exe (there's a small complication here I'll come to
later, but let's ignore that for now). So I unzip the embeddable
distribution into the directory containing vim.exe.

However, I want that directory on PATH (so I can run vim from the
command line). Now, as the embeddable distribution includes
python.exe, this pollutes my PATH with an extra copy of python, which
may or may not be picked up in preference to my "real" python,
depending on how I install python. That's bad - I can delete
python.exe and pythonw.exe from my vim installation, but I still have
a load of Python DLLs on PATH that could potentially mess up other
Python installations on my machine (I honestly don't know how likely
that is, particularly if I distribute my vim build to other users with
different setups).

What I'd like to do is to put the Python stuff in a subdirectory of
the Vim installation, so it's safely isolated. In the case of vim, I
can do this, as vim has an option to dynamically load the Python DLL
via LoadLibrary, and I can patch vim to look in <vim dir>\python
before searching PATH. But the LoadLibrary stuff is horribly fragile,
and I doubt anyone else embedding Pthon in their application is likely
to do that - they will probably just link to python35.dll at
load-time.

I'm not aware of any way to adjust the loader's search path for DLLs
to include a subdirectory that's not on PATH, so it seems to me that
there's no good way to avoid having the embeddable distribution
visible via the user's PATH.

For vim, I'll probably go for the dynamic loading approach with a
patch to look in a subdirectory. But have I missed any other
approaches that make an embedded Python more isolated from the user's
system?

Paul

From cmkleffner at gmail.com  Wed Sep  9 17:11:58 2015
From: cmkleffner at gmail.com (Carl Kleffner)
Date: Wed, 9 Sep 2015 17:11:58 +0200
Subject: [Python-Dev] Embedding Python 3.5
In-Reply-To: <CACac1F-+EQ3OZJJN0nn36qSt6oQVmOUB97p_qQ91UsidF7MOvQ@mail.gmail.com>
References: <CACac1F-+EQ3OZJJN0nn36qSt6oQVmOUB97p_qQ91UsidF7MOvQ@mail.gmail.com>
Message-ID: <CAGGsPMx8vZW_afAnZ=iUkE8Fx1c0UMASM7o4j_+3b9FbOuwS8g@mail.gmail.com>

A good overview on this topic is given on
https://github.com/numpy/numpy/wiki/windows-dll-notes. As a side note the
PATH is usually the latest place in the search order of DLLs. Pre-loading
python35.dll into the process space from within vim could be a possible
solution.


2015-09-09 16:30 GMT+02:00 Paul Moore <p.f.moore at gmail.com>:

> First of all, an apology. I know this is probably going to be of
> limited interest for many on python-dev, but I'm honestly not sure
> where there's a better audience for the question. As it's related to
> how people should use the new "embeddable" distribution of Python 3.5,
> I'm hoping it's sufficiently relevant - but if not, feel free to
> direct me to a better forum.
>
> I've been trying to use the new embeddable distribution to build a
> Windows installation of vim that includes a Python interpreter, rather
> than relying on the user having a system install of Python on PATH.
> This strikes me as precisely the sort of usage that the embeddable
> distribution would be great for. And indeed, it works fine for that.
> But when it comes to distribution, I have an issue.
>
> The problem is that for vim to find the Python DLL, it needs to be
> alongside vim.exe (there's a small complication here I'll come to
> later, but let's ignore that for now). So I unzip the embeddable
> distribution into the directory containing vim.exe.
>
> However, I want that directory on PATH (so I can run vim from the
> command line). Now, as the embeddable distribution includes
> python.exe, this pollutes my PATH with an extra copy of python, which
> may or may not be picked up in preference to my "real" python,
> depending on how I install python. That's bad - I can delete
> python.exe and pythonw.exe from my vim installation, but I still have
> a load of Python DLLs on PATH that could potentially mess up other
> Python installations on my machine (I honestly don't know how likely
> that is, particularly if I distribute my vim build to other users with
> different setups).
>
> What I'd like to do is to put the Python stuff in a subdirectory of
> the Vim installation, so it's safely isolated. In the case of vim, I
> can do this, as vim has an option to dynamically load the Python DLL
> via LoadLibrary, and I can patch vim to look in <vim dir>\python
> before searching PATH. But the LoadLibrary stuff is horribly fragile,
> and I doubt anyone else embedding Pthon in their application is likely
> to do that - they will probably just link to python35.dll at
> load-time.
>
> I'm not aware of any way to adjust the loader's search path for DLLs
> to include a subdirectory that's not on PATH, so it seems to me that
> there's no good way to avoid having the embeddable distribution
> visible via the user's PATH.
>
> For vim, I'll probably go for the dynamic loading approach with a
> patch to look in a subdirectory. But have I missed any other
> approaches that make an embedded Python more isolated from the user's
> system?
>
> Paul
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150909/75a6caa1/attachment.html>

From p.f.moore at gmail.com  Wed Sep  9 17:19:18 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 9 Sep 2015 16:19:18 +0100
Subject: [Python-Dev] Embedding Python 3.5
In-Reply-To: <CAGGsPMx8vZW_afAnZ=iUkE8Fx1c0UMASM7o4j_+3b9FbOuwS8g@mail.gmail.com>
References: <CACac1F-+EQ3OZJJN0nn36qSt6oQVmOUB97p_qQ91UsidF7MOvQ@mail.gmail.com>
 <CAGGsPMx8vZW_afAnZ=iUkE8Fx1c0UMASM7o4j_+3b9FbOuwS8g@mail.gmail.com>
Message-ID: <CACac1F_j_pP+R1ZUrRJtnRGzv0v807-k6Rhj1N7wQz013e__aA@mail.gmail.com>

On 9 September 2015 at 16:11, Carl Kleffner <cmkleffner at gmail.com> wrote:
> A good overview on this topic is given on
> https://github.com/numpy/numpy/wiki/windows-dll-notes. As a side note the
> PATH is usually the latest place in the search order of DLLs. Pre-loading
> python35.dll into the process space from within vim could be a possible
> solution.

Thank you for this. From a very quick read, it looks like I could put
the embedded Python files in a directory ...\gvim.exe.local. I'll give
that a try (there's a downside, in that I'd need a duplicate copy in
...\vim.exe.local if I wanted the console version to work too). It
looks like SxS assemblies might help too, but that'll need a bit more
reading before I understand it :-)

Paul

From hxu1 at ltu.edu  Wed Sep  9 17:31:25 2015
From: hxu1 at ltu.edu (Hansong Xu)
Date: Wed, 9 Sep 2015 11:31:25 -0400
Subject: [Python-Dev] Network simulator 3 ("python-dev" missing) on macports
Message-ID: <CAKtWSyzO8-X=ep0y756ZT_Vq6azXPdu78OF9QEm6DJCNz2U=kA@mail.gmail.com>

Dear
I was trying to install NS3 on my mac os, it seems missed the python-dev
installed.
However, the 'sudo port install python-dev'is not working because the port
can not be found. please help for install the 'python-dev'
thanks!!
best
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150909/a418afaf/attachment.html>

From brett at python.org  Wed Sep  9 17:44:41 2015
From: brett at python.org (Brett Cannon)
Date: Wed, 09 Sep 2015 15:44:41 +0000
Subject: [Python-Dev] Network simulator 3 ("python-dev" missing) on
	macports
In-Reply-To: <CAKtWSyzO8-X=ep0y756ZT_Vq6azXPdu78OF9QEm6DJCNz2U=kA@mail.gmail.com>
References: <CAKtWSyzO8-X=ep0y756ZT_Vq6azXPdu78OF9QEm6DJCNz2U=kA@mail.gmail.com>
Message-ID: <CAP1=2W6TtoOqWwuFgLd27aiStK58QeUR6zrWXZgFrdB8BzXARA@mail.gmail.com>

This mailing list is for the development *of* Python and not *with* it.
Your best bet is to ask NS3 or macports for help as we have nothing to do
with macports.

On Wed, 9 Sep 2015 at 08:41 Hansong Xu <hxu1 at ltu.edu> wrote:

> Dear
> I was trying to install NS3 on my mac os, it seems missed the python-dev
> installed.
> However, the 'sudo port install python-dev'is not working because the
> port can not be found. please help for install the 'python-dev'
> thanks!!
> best
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150909/c7e3184e/attachment.html>

From steve.dower at python.org  Wed Sep  9 18:16:56 2015
From: steve.dower at python.org (Steve Dower)
Date: Wed, 9 Sep 2015 09:16:56 -0700
Subject: [Python-Dev] Embedding Python 3.5
In-Reply-To: <CACac1F_j_pP+R1ZUrRJtnRGzv0v807-k6Rhj1N7wQz013e__aA@mail.gmail.com>
References: <CACac1F-+EQ3OZJJN0nn36qSt6oQVmOUB97p_qQ91UsidF7MOvQ@mail.gmail.com>
 <CAGGsPMx8vZW_afAnZ=iUkE8Fx1c0UMASM7o4j_+3b9FbOuwS8g@mail.gmail.com>
 <CACac1F_j_pP+R1ZUrRJtnRGzv0v807-k6Rhj1N7wQz013e__aA@mail.gmail.com>
Message-ID: <55F05B78.8060806@python.org>

On 09Sep2015 0819, Paul Moore wrote:
> On 9 September 2015 at 16:11, Carl Kleffner <cmkleffner at gmail.com> wrote:
>> A good overview on this topic is given on
>> https://github.com/numpy/numpy/wiki/windows-dll-notes. As a side note the
>> PATH is usually the latest place in the search order of DLLs. Pre-loading
>> python35.dll into the process space from within vim could be a possible
>> solution.
>
> Thank you for this. From a very quick read, it looks like I could put
> the embedded Python files in a directory ...\gvim.exe.local. I'll give
> that a try (there's a downside, in that I'd need a duplicate copy in
> ...\vim.exe.local if I wanted the console version to work too). It
> looks like SxS assemblies might help too, but that'll need a bit more
> reading before I understand it :-)

Don't bother reading into SxS assemblies. It may work, but it will 
destroy more brain cells than are worth wasting on it. :)

Certainly putting the distro into a subdirectory is what I had expected 
would be common. In general, putting application directories in PATH is 
considered poor form, but unfortunately we don't have a better approach 
(there are App Paths, but those only work via the shell).

Another approach you could use is making a separate directory to put on 
PATH that contains stub executables (or symlinks?) to launch the actual 
ones from a separate directory. That way you can control exactly what is 
available on PATH while still launching from a directory that is not on 
PATH.

Cheers,
Steve

> Paul


From storchaka at gmail.com  Wed Sep  9 18:58:51 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 9 Sep 2015 19:58:51 +0300
Subject: [Python-Dev] devguide: Drop myself from issue assignment list
In-Reply-To: <20150628061403.5679.62098@psf.io>
References: <20150628061403.5679.62098@psf.io>
Message-ID: <55F0654B.7020504@gmail.com>

On 28.06.15 09:14, nick.coghlan wrote:
> https://hg.python.org/devguide/rev/452f840bac9f
> changeset:   749:452f840bac9f
> user:        Nick Coghlan <ncoghlan at gmail.com>
> date:        Sun Jun 28 16:13:54 2015 +1000
> summary:
>    Drop myself from issue assignment list
>
> files:
>    experts.rst |  6 +++---
>    1 files changed, 3 insertions(+), 3 deletions(-)
>
>
> diff --git a/experts.rst b/experts.rst
> --- a/experts.rst
> +++ b/experts.rst
> @@ -1,4 +1,4 @@
> -.. _experts:
> +    .. _experts:

Was this change made intentionally? May be it broke the completion in 
Nosy List on the tracker.


From storchaka at gmail.com  Wed Sep  9 19:33:50 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 9 Sep 2015 20:33:50 +0300
Subject: [Python-Dev] devguide: Drop myself from issue assignment list
In-Reply-To: <55F0654B.7020504@gmail.com>
References: <20150628061403.5679.62098@psf.io> <55F0654B.7020504@gmail.com>
Message-ID: <mspqhu$lng$1@ger.gmane.org>

Sorry for the nose. I sent this message to the list I accidentally.


From steve.dower at python.org  Wed Sep  9 19:50:33 2015
From: steve.dower at python.org (Steve Dower)
Date: Wed, 9 Sep 2015 10:50:33 -0700
Subject: [Python-Dev] [RELEASED] Python 3.5.0rc4 is now available!
In-Reply-To: <55F0372A.3050007@hastings.org>
References: <55F0372A.3050007@hastings.org>
Message-ID: <55F07169.9050604@python.org>

On 09Sep2015 0642, Larry Hastings wrote:
> On behalf of the Python development community and the Python 3.5 release
> team, I'm surprised to announce the availability of Python 3.5.0rc4,
> also known as Python 3.5.0 Release Candidate 4.
>
> Python 3.5.0 Release Candidate 3 was only released about a day ago.
> However: during testing, a major regression was discovered, reported on
> the issue tracker as #25027:
>
>     http://bugs.python.org/issue25027
>
> Python 3.5 includes some big changes on how Python is built on Windows.
> One of those changes resulted in Python processes on Windows exceeding
> the maximum number of loadable shared libraries.  As a result Windows
> builds of Python could no longer run major Python software stacks like
> Pandas and Jupyter. Fixing this required non-trivial last-minute changes
> to the Windows build--and those changes need testing.  We therefore
> elected to insert an extra release candidate before the final release,
> to get these changes into your hands as soon as possible, so that
> Windows users could test these changes.
>

For more background and info about the change on Windows, I've written a 
follow-up post to my previous one.

http://stevedower.id.au/blog/building-for-python-3-5-part-two/

The short version is that we now include a shared dependency in the 
installer (vcruntime140.dll), and extensions built with future versions 
of the compiler but targeting Python 3.5 will include their own private 
copy of this dependency (which will be named vcruntime1#0.dll where # != 4).

Cheers,
Steve


From levkivskyi at gmail.com  Wed Sep  9 20:02:38 2015
From: levkivskyi at gmail.com (Ivan Levkivskyi)
Date: Wed, 9 Sep 2015 20:02:38 +0200
Subject: [Python-Dev] what is wrong with hg.python.org
Message-ID: <CAOMjWkkq=wyQb_OfncmPMDPOp8DmbOE-cO9ABjip3WN_Kzj0zw@mail.gmail.com>

Hi,

https://hg.python.org/ returns 503 Service Unavailable for an hour or so.
Is it a maintenance? When it is expected to end?

Best regards,
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150909/58fca9c8/attachment.html>

From rdmurray at bitdance.com  Wed Sep  9 20:16:04 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 09 Sep 2015 14:16:04 -0400
Subject: [Python-Dev] what is wrong with hg.python.org
In-Reply-To: <CAOMjWkkq=wyQb_OfncmPMDPOp8DmbOE-cO9ABjip3WN_Kzj0zw@mail.gmail.com>
References: <CAOMjWkkq=wyQb_OfncmPMDPOp8DmbOE-cO9ABjip3WN_Kzj0zw@mail.gmail.com>
Message-ID: <20150909181604.731C81B1000A@webabinitio.net>

On Wed, 09 Sep 2015 20:02:38 +0200, Ivan Levkivskyi <levkivskyi at gmail.com> wrote:
> https://hg.python.org/ returns 503 Service Unavailable for an hour or so.
> Is it a maintenance? When it is expected to end?

It was an attempt at maintenance (upgrade) that went bad.  No ETA yet,
I'm afraid.  The repo is still ssh accessible, but not via https or hgweb.

--David

From storchaka at gmail.com  Wed Sep  9 21:20:44 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 9 Sep 2015 22:20:44 +0300
Subject: [Python-Dev] devguide: Drop myself from issue assignment list
In-Reply-To: <mspqhu$lng$1@ger.gmane.org>
References: <20150628061403.5679.62098@psf.io> <55F0654B.7020504@gmail.com>
 <mspqhu$lng$1@ger.gmane.org>
Message-ID: <msq0qd$1b1$1@ger.gmane.org>

On 09.09.15 20:33, Serhiy Storchaka wrote:
> Sorry for the nose. I sent this message to the list I accidentally.
>
s/nose/noise/



From p.f.moore at gmail.com  Wed Sep  9 21:39:03 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 9 Sep 2015 20:39:03 +0100
Subject: [Python-Dev] Embedding Python 3.5
In-Reply-To: <55F05B78.8060806@python.org>
References: <CACac1F-+EQ3OZJJN0nn36qSt6oQVmOUB97p_qQ91UsidF7MOvQ@mail.gmail.com>
 <CAGGsPMx8vZW_afAnZ=iUkE8Fx1c0UMASM7o4j_+3b9FbOuwS8g@mail.gmail.com>
 <CACac1F_j_pP+R1ZUrRJtnRGzv0v807-k6Rhj1N7wQz013e__aA@mail.gmail.com>
 <55F05B78.8060806@python.org>
Message-ID: <CACac1F9ju-Cw9gw=VTgOJqMSmoiq9587o=dbvH6BKgq3Rd78gg@mail.gmail.com>

On 9 September 2015 at 17:16, Steve Dower <steve.dower at python.org> wrote:
> Don't bother reading into SxS assemblies. It may work, but it will destroy
> more brain cells than are worth wasting on it. :)

:-) Yeah, I looked at SxS once before and sprained my brain. But the
summary on the numpy wiki looked like a digestible summary, so I may
just take another look for curiosity. (That's probably what the guys
who summoned Cthulhu thought... ;-))

> Certainly putting the distro into a subdirectory is what I had expected
> would be common. In general, putting application directories in PATH is
> considered poor form, but unfortunately we don't have a better approach
> (there are App Paths, but those only work via the shell).

Yep, that's sort of the norm, and I don't *really* object to it. But
I'd delete python(w).exe so they didn't hide a full distribution.

> Another approach you could use is making a separate directory to put on PATH
> that contains stub executables (or symlinks?) to launch the actual ones from
> a separate directory. That way you can control exactly what is available on
> PATH while still launching from a directory that is not on PATH.

That's nice. The only problems with that are that I've never been
comfortable with symlinks on Windows (because they need admin privs,
mainly) and I prefer to avoid stubs because they mean there's an extra
process - that latter's a bit of a silly objection (it works fine for
py.exe and pip's executable wrappers), though.

Thanks for the ideas. As I thought, it's more of a general Windows
development question in the end, rather than a Python one. So sorry
for the off-topic question (I blame the Python community for being so
helpful ;-))

Paul

From trent at snakebite.org  Wed Sep  9 22:33:49 2015
From: trent at snakebite.org (Trent Nelson)
Date: Wed, 9 Sep 2015 16:33:49 -0400
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
 comment
In-Reply-To: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
Message-ID: <20150909203349.GB26835@trent.me>

On Tue, Sep 08, 2015 at 10:12:37AM -0400, Gary Robinson wrote:
> There was a huge data structure that all the analysis needed to
> access. Using a database would have slowed things down too much.
> Ideally, I needed to access this same structure from many cores at
> once. On a Power8 system, for example, with its larger number of
> cores, performance may well have been good enough for production. In
> any case, my experimentation and prototyping would have gone more
> quickly with more cores.
>
> But this data structure was simply too big. Replicating it in
> different processes used memory far too quickly and was the limiting
> factor on the number of cores I could use. (I could fork with the big
> data structure already in memory, but copy-on-write issues due to
> reference counting caused multiple copies to exist anyway.)

This problem is *exactly* the type of thing that PyParallel excels at,
just FYI.  PyParallel can load large, complex data structures now, and
then access them freely from within multiple threads.  I'd recommended
taking a look at the "instantaneous Wikipedia search server" example as
a start:

https://github.com/pyparallel/pyparallel/blob/branches/3.3-px/examples/wiki/wiki.py

That loads trie with 27 million entries, creates ~27.1 million
PyObjects, loads a huge NumPy array, and has a WSS of ~11GB.  I've
actually got a new version in development that loads 6 tries of the
most frequent terms for character lengths 1-6.  Once everything is
loaded, the data structures can be accessed for free in parallel
threads.

There are more details regarding how this is achieved on the landing
page:

https://github.com/pyparallel/pyparallel

I've done a couple of consultancy projects now that were very data
science oriented (with huge data sets), so I really gained an
appreciation for how common the situation you describe is.  It is
probably the best demonstration of PyParallel's strengths.

> Gary Robinson garyrob at me.com http://www.garyrobinson.net

    Trent.

From ethan at stoneleaf.us  Wed Sep  9 22:43:19 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 09 Sep 2015 13:43:19 -0700
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
 comment
In-Reply-To: <20150909203349.GB26835@trent.me>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
 <20150909203349.GB26835@trent.me>
Message-ID: <55F099E7.20403@stoneleaf.us>

On 09/09/2015 01:33 PM, Trent Nelson wrote:

> This problem is *exactly* the type of thing that PyParallel excels at [...]

Sorry if I missed it, but is PyParallel still Windows only?

--
~Ethan~

From trent at snakebite.org  Wed Sep  9 22:52:39 2015
From: trent at snakebite.org (Trent Nelson)
Date: Wed, 9 Sep 2015 16:52:39 -0400
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
 comment
In-Reply-To: <55F099E7.20403@stoneleaf.us>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
 <20150909203349.GB26835@trent.me> <55F099E7.20403@stoneleaf.us>
Message-ID: <20150909205238.GC26835@trent.me>

On Wed, Sep 09, 2015 at 01:43:19PM -0700, Ethan Furman wrote:
> On 09/09/2015 01:33 PM, Trent Nelson wrote:
> 
> >This problem is *exactly* the type of thing that PyParallel excels at [...]
> 
> Sorry if I missed it, but is PyParallel still Windows only?

Yeah, still Windows only.  Still based off 3.3.5.  I'm hoping to rebase
off 3.5 after its tagged and get it into a state where it can at least
build on POSIX (i.e. stub enough functions such that it'll compile).

That's going to be a lot of work though, would love to get some help
with it.

    Trent.

From garyrob at me.com  Wed Sep  9 22:52:39 2015
From: garyrob at me.com (Gary Robinson)
Date: Wed, 09 Sep 2015 16:52:39 -0400
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
 comment
In-Reply-To: <20150909203349.GB26835@trent.me>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
 <20150909203349.GB26835@trent.me>
Message-ID: <94836BE6-8A8B-4B1F-BF13-E05BC41EC142@me.com>

I?m going to seriously consider installing Windows or using a dedicated hosted windows box next time I have this problem so that I can try your solution. It does seem pretty ideal, although the STM branch of PyPy (using http://codespeak.net/execnet/ to access SciPy) might also work at this point.

Thanks!

I still hope CPython has a solution at some point? maybe PyParallelel functionality will be integrated into Python 4 circa 2023? :)



-- 

Gary Robinson
garyrob at me.com
http://www.garyrobinson.net

> On Sep 9, 2015, at 4:33 PM, Trent Nelson <trent at snakebite.org> wrote:
> 
> On Tue, Sep 08, 2015 at 10:12:37AM -0400, Gary Robinson wrote:
>> There was a huge data structure that all the analysis needed to
>> access. Using a database would have slowed things down too much.
>> Ideally, I needed to access this same structure from many cores at
>> once. On a Power8 system, for example, with its larger number of
>> cores, performance may well have been good enough for production. In
>> any case, my experimentation and prototyping would have gone more
>> quickly with more cores.
>> 
>> But this data structure was simply too big. Replicating it in
>> different processes used memory far too quickly and was the limiting
>> factor on the number of cores I could use. (I could fork with the big
>> data structure already in memory, but copy-on-write issues due to
>> reference counting caused multiple copies to exist anyway.)
> 
> This problem is *exactly* the type of thing that PyParallel excels at,
> just FYI.  PyParallel can load large, complex data structures now, and
> then access them freely from within multiple threads.  I'd recommended
> taking a look at the "instantaneous Wikipedia search server" example as
> a start:
> 
> https://github.com/pyparallel/pyparallel/blob/branches/3.3-px/examples/wiki/wiki.py
> 
> That loads trie with 27 million entries, creates ~27.1 million
> PyObjects, loads a huge NumPy array, and has a WSS of ~11GB.  I've
> actually got a new version in development that loads 6 tries of the
> most frequent terms for character lengths 1-6.  Once everything is
> loaded, the data structures can be accessed for free in parallel
> threads.
> 
> There are more details regarding how this is achieved on the landing
> page:
> 
> https://github.com/pyparallel/pyparallel
> 
> I've done a couple of consultancy projects now that were very data
> science oriented (with huge data sets), so I really gained an
> appreciation for how common the situation you describe is.  It is
> probably the best demonstration of PyParallel's strengths.
> 
>> Gary Robinson garyrob at me.com http://www.garyrobinson.net
> 
>    Trent.


From trent at snakebite.org  Thu Sep 10 01:02:39 2015
From: trent at snakebite.org (Trent Nelson)
Date: Wed, 9 Sep 2015 19:02:39 -0400
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
 comment
In-Reply-To: <94836BE6-8A8B-4B1F-BF13-E05BC41EC142@me.com>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
 <20150909203349.GB26835@trent.me>
 <94836BE6-8A8B-4B1F-BF13-E05BC41EC142@me.com>
Message-ID: <20150909230239.GB27237@trent.me>

On Wed, Sep 09, 2015 at 04:52:39PM -0400, Gary Robinson wrote:
> I?m going to seriously consider installing Windows or using a
> dedicated hosted windows box next time I have this problem so that I
> can try your solution. It does seem pretty ideal, although the STM
> branch of PyPy (using http://codespeak.net/execnet/ to access SciPy)
> might also work at this point.

I'm not sure how up-to-date this is:

http://pypy.readthedocs.org/en/latest/stm.html

But it sounds like there's a 1.5GB memory limit (or maybe 2.5GB now, I
just peaked at core.h linked in that page) and a 4-core segment limit.

PyParallel has no memory limit (although it actually does have support
for throttling back memory pressure by not accepting new connections
when the system hits 90% physical memory used) and no core limit, and it
scales linearly with cores+concurrency.

PyPy-STM and PyParallel are both pretty bleeding edge and experimental
though so I'm sure we both crash as much as each other when exercised
outside of our comfort zones :-)

I haven't tried getting the SciPy stack running with PyParallel yet.

    Trent.

From garyrob at me.com  Thu Sep 10 02:59:34 2015
From: garyrob at me.com (Gary Robinson)
Date: Wed, 09 Sep 2015 20:59:34 -0400
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
 comment
In-Reply-To: <20150909230239.GB27237@trent.me>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
 <20150909203349.GB26835@trent.me>
 <94836BE6-8A8B-4B1F-BF13-E05BC41EC142@me.com>
 <20150909230239.GB27237@trent.me>
Message-ID: <13BC98BE-8D9A-4387-B0DD-4D2890F44B72@me.com>

> 
> I haven't tried getting the SciPy stack running with PyParallel yet.

That would be essential for my use. I would assume a lot of potential PyParallel users are in the same boat.

Thanks for the info about PyPy limits. You have a really interesting project. 

-- 

Gary Robinson
garyrob at me.com
http://www.garyrobinson.net

> On Sep 9, 2015, at 7:02 PM, Trent Nelson <trent at snakebite.org> wrote:
> 
> On Wed, Sep 09, 2015 at 04:52:39PM -0400, Gary Robinson wrote:
>> I?m going to seriously consider installing Windows or using a
>> dedicated hosted windows box next time I have this problem so that I
>> can try your solution. It does seem pretty ideal, although the STM
>> branch of PyPy (using http://codespeak.net/execnet/ to access SciPy)
>> might also work at this point.
> 
> I'm not sure how up-to-date this is:
> 
> http://pypy.readthedocs.org/en/latest/stm.html
> 
> But it sounds like there's a 1.5GB memory limit (or maybe 2.5GB now, I
> just peaked at core.h linked in that page) and a 4-core segment limit.
> 
> PyParallel has no memory limit (although it actually does have support
> for throttling back memory pressure by not accepting new connections
> when the system hits 90% physical memory used) and no core limit, and it
> scales linearly with cores+concurrency.
> 
> PyPy-STM and PyParallel are both pretty bleeding edge and experimental
> though so I'm sure we both crash as much as each other when exercised
> outside of our comfort zones :-)
> 
> I haven't tried getting the SciPy stack running with PyParallel yet.
> 
>    Trent.


From fijall at gmail.com  Thu Sep 10 09:23:53 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 10 Sep 2015 09:23:53 +0200
Subject: [Python-Dev] semantics of subclassing things from itertools
Message-ID: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>

Hi

I would like to know what are the semantics if you subclass something
from itertools (e.g. islice).

Right now it's allowed and people do it, which is why the
documentation is incorrect. It states "equivalent to: a function-or a
generator", but you can't subclass whatever it is equivalent to, which
is why in PyPy we're unable to make it work in pure python.

I would like some clarification on that.

Cheers,
fijal

From storchaka at gmail.com  Thu Sep 10 10:26:08 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 10 Sep 2015 11:26:08 +0300
Subject: [Python-Dev] semantics of subclassing things from itertools
In-Reply-To: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
References: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
Message-ID: <msrer1$pp$1@ger.gmane.org>

On 10.09.15 10:23, Maciej Fijalkowski wrote:
> I would like to know what are the semantics if you subclass something
> from itertools (e.g. islice).
>
> Right now it's allowed and people do it, which is why the
> documentation is incorrect. It states "equivalent to: a function-or a
> generator", but you can't subclass whatever it is equivalent to, which
> is why in PyPy we're unable to make it work in pure python.
>
> I would like some clarification on that.

There is another reason why itertools iterators can't be implemented as 
simple generator functions. All iterators are pickleable in 3.x.


From storchaka at gmail.com  Thu Sep 10 12:27:42 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 10 Sep 2015 13:27:42 +0300
Subject: [Python-Dev] Can't post to bugs.python.org
Message-ID: <msrluv$m3d$1@ger.gmane.org>

I can't neither post a message to existing issue nor open a new issue. 
The irker854 bot on IRC channel #python-dev cites my message and the 
tracker updates activity time of existing issue, but doesn't show my 
message and doesn't reflect changes of status. Posting via e-mail 
doesn't work as well.

Web server replies:

An error has occurred
A problem was encountered processing your request. The tracker 
maintainers have been notified of the problem.

E-mail server replies:

Subject: Failed issue tracker submission

You are not a registered user. Please register at:

http://bugs.python.org/user?@template=register

...before sending mail to the tracker.


From fijall at gmail.com  Thu Sep 10 14:50:33 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 10 Sep 2015 14:50:33 +0200
Subject: [Python-Dev] semantics of subclassing things from itertools
In-Reply-To: <msrer1$pp$1@ger.gmane.org>
References: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
 <msrer1$pp$1@ger.gmane.org>
Message-ID: <CAK5idxRvNcJKXSer-40rZF-wtt_=qssgBWof1Jw+Qrj7w1CWJg@mail.gmail.com>

On Thu, Sep 10, 2015 at 10:26 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 10.09.15 10:23, Maciej Fijalkowski wrote:
>>
>> I would like to know what are the semantics if you subclass something
>> from itertools (e.g. islice).
>>
>> Right now it's allowed and people do it, which is why the
>> documentation is incorrect. It states "equivalent to: a function-or a
>> generator", but you can't subclass whatever it is equivalent to, which
>> is why in PyPy we're unable to make it work in pure python.
>>
>> I would like some clarification on that.
>
>
> There is another reason why itertools iterators can't be implemented as
> simple generator functions. All iterators are pickleable in 3.x.

maybe the documentation should reflect that? (note that generators are
pickleable on pypy anyway)

From rdmurray at bitdance.com  Thu Sep 10 15:02:01 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 10 Sep 2015 09:02:01 -0400
Subject: [Python-Dev] Can't post to bugs.python.org
In-Reply-To: <msrluv$m3d$1@ger.gmane.org>
References: <msrluv$m3d$1@ger.gmane.org>
Message-ID: <20150910130201.86B1AB14151@webabinitio.net>

On Thu, 10 Sep 2015 13:27:42 +0300, Serhiy Storchaka <storchaka at gmail.com> wrote:
> I can't neither post a message to existing issue nor open a new issue. 
> The irker854 bot on IRC channel #python-dev cites my message and the 
> tracker updates activity time of existing issue, but doesn't show my 
> message and doesn't reflect changes of status. Posting via e-mail 
> doesn't work as well.
> 
> Web server replies:
> 
> An error has occurred
> A problem was encountered processing your request. The tracker 
> maintainers have been notified of the problem.
> 
> E-mail server replies:
> 
> Subject: Failed issue tracker submission
> 
> You are not a registered user. Please register at:
> 
> http://bugs.python.org/user?@template=register
> 
> ...before sending mail to the tracker.

I haven't tried the email gateway, but I can update issues.  I see the
irker message from when you tried to create one and indeed that issue
does not exist.  However, there are no messages among those sent to the
tracker administrators that show errors around that time or for a few
hours before it.

If this continues to plague you, we'll probably need to do some live
debugging.  You can ping me (bitdancer) on IRC, I should be on for the
next 8 hours
or so.

--David

From rdmurray at bitdance.com  Thu Sep 10 16:18:17 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 10 Sep 2015 10:18:17 -0400
Subject: [Python-Dev] Can't post to bugs.python.org
In-Reply-To: <20150910130201.86B1AB14151@webabinitio.net>
References: <msrluv$m3d$1@ger.gmane.org>
 <20150910130201.86B1AB14151@webabinitio.net>
Message-ID: <20150910141817.ED84AB14151@webabinitio.net>

On Thu, 10 Sep 2015 09:02:01 -0400, "R. David Murray" <rdmurray at bitdance.com> wrote:
> If this continues to plague you, we'll probably need to do some live
> debugging.  You can ping me (bitdancer) on IRC, I should be on for the
> next 8 hours or so.

This turns out to have been specific to Serhiy (or any issue on which he
was nosy) and was due to a keyboard error on my part.  It is now fixed.

--David

From martin at martindengler.com  Thu Sep 10 18:38:42 2015
From: martin at martindengler.com (Martin Dengler)
Date: Thu, 10 Sep 2015 17:38:42 +0100
Subject: [Python-Dev] Yet another "A better story for multi-core Python"
 comment
In-Reply-To: <20150909203349.GB26835@trent.me>
References: <322A81BF-146E-4FB7-B698-07C10BB33D00@me.com>
 <20150909203349.GB26835@trent.me>
Message-ID: <20150910163842.GE5894@ops-13.ops-13.xades.com>

On Wed, Sep 09, 2015 at 04:33:49PM -0400, Trent Nelson wrote:
>PyObjects, loads a huge NumPy array, and has a WSS of ~11GB.
[...]
>I've done a couple of consultancy projects now that were very data
>science oriented (with huge data sets), so I really gained an
>appreciation for how common the situation you describe is.  It is
>probably the best demonstration of PyParallel's strengths.

This problem is also common in well-heeled financial services places, many of
which are non-Windows.  There might be some good opportunities there.

>    Trent.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150910/ef795dfe/attachment.sig>

From tjreedy at udel.edu  Thu Sep 10 23:01:50 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 10 Sep 2015 17:01:50 -0400
Subject: [Python-Dev] semantics of subclassing things from itertools
In-Reply-To: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
References: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
Message-ID: <mssr4n$u2v$1@ger.gmane.org>

On 9/10/2015 3:23 AM, Maciej Fijalkowski wrote:
> Hi
>
> I would like to know what are the semantics if you subclass something
> from itertools (e.g. islice).

I believe people are depending on an undocumented internal speed 
optimization.  See below.

> Right now it's allowed and people do it, which is why the
> documentation is incorrect. It states "equivalent to: a function-or a
> generator",

I believe Raymond has said that 'equivalent' should be taken as 
'equivalent in essential function for iterating' rather than 'exactly 
equivalent for all operations'.  The results of type() and isinstance() 
are not relevant for this.  The itertools doc begins with "This module 
implements a number of iterator building blocks ..." After listing them, 
it says "The following module *functions* all construct and return 
iterators." (These part of the doc are unchanged from the original in 
2.3. I added the emphasis.) The generator functions are mathematically 
equivalent if they produce equivalent iterators for the same inputs. 
The iterators are equivalent if they produce the same stream of objects 
when iterated. If they do, the doc is correct; if not, the doc is buggy 
and should be fixed.

I see the undocumented fact that the module *functions* are implemented 
as C classes as an internal implementation detail to optimize speed.  I 
believe Raymond intentionally used 'function' rather than 'class' and 
intended the equivalents to be usable by other implementations. Ask 
Raymond directly (he is not currently active on pydev) if I am correct.

> but you can't subclass whatever it is equivalent to, which
> is why in PyPy we're unable to make it work in pure python.

You could write equivalent iterator classes in Python, but the result 
would be significantly slower.

-- 
Terry Jan Reedy


From storchaka at gmail.com  Fri Sep 11 00:16:40 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Fri, 11 Sep 2015 01:16:40 +0300
Subject: [Python-Dev] cpython (3.5): whatsnew/3.5: Editorialization pass
 on library section
In-Reply-To: <20150910213608.11999.12766@psf.io>
References: <20150910213608.11999.12766@psf.io>
Message-ID: <mssvg8$d9j$1@ger.gmane.org>

On 11.09.15 00:36, yury.selivanov wrote:
> https://hg.python.org/cpython/rev/3265f33df731
> changeset:   97874:3265f33df731
> branch:      3.5
> parent:      97872:70c97a626c41
> user:        Yury Selivanov <yselivanov at sprymix.com>
> date:        Thu Sep 10 17:35:38 2015 -0400
> summary:
>    whatsnew/3.5: Editorialization pass on library section
>
> Patch by Elvis Pranskevichus

>   io
>   --
>
> -* New Python implementation of :class:`io.FileIO` to make dependency on
> -  ``_io`` module optional.
> -  (Contributed by  Serhiy Storchaka in :issue:`21859`.)
> +:class:`io.FileIO` has been implemented in Python which makes C implementation
> +of :mod:`io` module entirely optional. (Contributed by  Serhiy Storchaka
> +in :issue:`21859`.)

Unfortunately this is not true. Python implementation is required to 
make the _io module optional, but it is not enough. io and _pyio still 
depend from _io (issue17984).

May be it is not worth to mention this change at all. End users unlikely 
will encounter Python implementation.


From yselivanov.ml at gmail.com  Fri Sep 11 00:32:27 2015
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Thu, 10 Sep 2015 18:32:27 -0400
Subject: [Python-Dev] cpython (3.5): whatsnew/3.5: Editorialization pass
 on library section
In-Reply-To: <mssvg8$d9j$1@ger.gmane.org>
References: <20150910213608.11999.12766@psf.io> <mssvg8$d9j$1@ger.gmane.org>
Message-ID: <55F204FB.5030903@gmail.com>



On 2015-09-10 6:16 PM, Serhiy Storchaka wrote:
> On 11.09.15 00:36, yury.selivanov wrote:
>> https://hg.python.org/cpython/rev/3265f33df731
>> changeset:   97874:3265f33df731
>> branch:      3.5
>> parent:      97872:70c97a626c41
>> user:        Yury Selivanov <yselivanov at sprymix.com>
>> date:        Thu Sep 10 17:35:38 2015 -0400
>> summary:
>>    whatsnew/3.5: Editorialization pass on library section
>>
>> Patch by Elvis Pranskevichus
>
>>   io
>>   --
>>
>> -* New Python implementation of :class:`io.FileIO` to make dependency on
>> -  ``_io`` module optional.
>> -  (Contributed by  Serhiy Storchaka in :issue:`21859`.)
>> +:class:`io.FileIO` has been implemented in Python which makes C 
>> implementation
>> +of :mod:`io` module entirely optional. (Contributed by  Serhiy 
>> Storchaka
>> +in :issue:`21859`.)
>
> Unfortunately this is not true. Python implementation is required to 
> make the _io module optional, but it is not enough. io and _pyio still 
> depend from _io (issue17984).
>
> May be it is not worth to mention this change at all. End users 
> unlikely will encounter Python implementation.

Alright, I dropped it.

Thanks!
Yury

From raymond.hettinger at gmail.com  Fri Sep 11 01:48:29 2015
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Thu, 10 Sep 2015 19:48:29 -0400
Subject: [Python-Dev] semantics of subclassing things from itertools
In-Reply-To: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
References: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
Message-ID: <E4833933-12FE-4ADC-9604-134FE953E9A8@gmail.com>


> On Sep 10, 2015, at 3:23 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> 
> I would like to know what are the semantics if you subclass something
> from itertools (e.g. islice).
> 
> Right now it's allowed and people do it, which is why the
> documentation is incorrect. It states "equivalent to: a function-or a
> generator", but you can't subclass whatever it is equivalent to, which
> is why in PyPy we're unable to make it work in pure python.
> 
> I would like some clarification on that.

The docs should say "roughly equivalent to" not "exactly equivalent to".
The intended purpose of the examples in the itertools docs is to use
pure python code to help people better understand each tool.  It is not
is intended to dictate that tool x is a generator or is a function.

The intended semantics are that the itertools are classes (not functions
and not generators).  They are intended to be sub-classable (that is
why they have Py_TPFLAGS_BASETYPE defined).

The description as a function was perhaps used too loosely (in much the
same way that we tend to think of int(3.14) as being a function when int
is really a class).  I tend to think about mapping, filtering, accumulating,
as being functions while at the same time knowing that they are actually
classes that produce iterators.

The section called "itertools functions" is a misnomer but is also useful
because the patterns of documenting functions better fit the itertools
and because documenting them as classes suggest that they should
each have a list of methods on that class (which doesn't make send
because the itertools are each one trick ponies with no aspirations 
to grow a pool of methods).

When I get a chance, I'll go through those docs and make them more precise.
Sorry for the ambiguity.


Raymond




From status at bugs.python.org  Fri Sep 11 18:08:28 2015
From: status at bugs.python.org (Python tracker)
Date: Fri, 11 Sep 2015 18:08:28 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20150911160828.A85EF56896@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2015-09-04 - 2015-09-11)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    5076 (+19)
  closed 31753 (+49)
  total  36829 (+68)

Open issues with patches: 2258 


Issues opened (46)
==================

#8232: webbrowser.open incomplete on Windows
http://bugs.python.org/issue8232  reopened by larry

#24199: Idle: remove idlelib.idlever.py and its use in About dialog
http://bugs.python.org/issue24199  reopened by terry.reedy

#25001: Make --nowindows argument to regrtest propagate when running w
http://bugs.python.org/issue25001  opened by brett.cannon

#25002: Deprecate asyncore/asynchat
http://bugs.python.org/issue25002  opened by gvanrossum

#25003: os.urandom() should call getrandom(2) not getentropy(2) on Sol
http://bugs.python.org/issue25003  opened by jbeck

#25006: List pybind11 binding generator
http://bugs.python.org/issue25006  opened by wenzel

#25007: Add support of copy protocol to zlib compressors and decompres
http://bugs.python.org/issue25007  opened by serhiy.storchaka

#25008: Deprecate smtpd
http://bugs.python.org/issue25008  opened by brett.cannon

#25011: Smarter rl complete: hide private and special names
http://bugs.python.org/issue25011  opened by serhiy.storchaka

#25012: pathlib should allow converting to absolute paths without reso
http://bugs.python.org/issue25012  opened by mu_mind

#25013: run_pdb() in test_pdb.py always returns stderr as None
http://bugs.python.org/issue25013  opened by xdegaye

#25015: Idle: scroll Text faster with mouse wheel
http://bugs.python.org/issue25015  opened by terry.reedy

#25017: htmllib deprecated: Which library to use? Missing sane default
http://bugs.python.org/issue25017  opened by guettli

#25020: IDLE - centralize ui policies and small utilities
http://bugs.python.org/issue25020  opened by markroseman

#25021: product_setstate() Out-of-bounds Read
http://bugs.python.org/issue25021  opened by JohnLeitch

#25023: time.strftime('%a'), ValueError: embedded null byte, in ko loc
http://bugs.python.org/issue25023  opened by sy LEE

#25024: Allow passing "delete=False" to TemporaryDirectory
http://bugs.python.org/issue25024  opened by Antony.Lee

#25026: (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type 
http://bugs.python.org/issue25026  opened by koobs

#25027: Python 3.5.0rc3 on Windows can not load more than 127 C extens
http://bugs.python.org/issue25027  opened by cgohlke

#25031: IDLE - file list improvements
http://bugs.python.org/issue25031  opened by markroseman

#25032: IDLE - same menubar across application
http://bugs.python.org/issue25032  opened by markroseman

#25034: string.Formatter accepts empty fields but displays wrong when 
http://bugs.python.org/issue25034  opened by anthon

#25035: Getter/setter for argparse keys
http://bugs.python.org/issue25035  opened by Sworddragon

#25036: IDLE - infrastructure changes so editors don't assume they're 
http://bugs.python.org/issue25036  opened by markroseman

#25039: Docs: Link to Stackless Python in Design and History FAQ secti
http://bugs.python.org/issue25039  opened by Winterflower

#25040: xml.sax.make_parser makes bad use of parser_list argument defa
http://bugs.python.org/issue25040  opened by Gautier Portet

#25041: document AF_PACKET socket address format
http://bugs.python.org/issue25041  opened by Tim.Tisdall

#25042: Create an "embedding SDK" distribution?
http://bugs.python.org/issue25042  opened by paul.moore

#25043: document socket constants for Bluetooth
http://bugs.python.org/issue25043  opened by Tim.Tisdall

#25044: bring BTPROTO_SCO inline with other Bluetooth protocols
http://bugs.python.org/issue25044  opened by Tim.Tisdall

#25045: smtplib throws exception TypeError: readline()
http://bugs.python.org/issue25045  opened by phlambotte

#25047: xml.etree.ElementTree encoding declaration should be capital (
http://bugs.python.org/issue25047  opened by zimeon

#25049: Strange behavior under doctest: staticmethods have different _
http://bugs.python.org/issue25049  opened by jneb

#25050: windows installer does not allow 32 and 64 installs side by si
http://bugs.python.org/issue25050  opened by Adam.Groszer

#25053: Possible race condition in Pool
http://bugs.python.org/issue25053  opened by Stanislaw Izaak Pitucha

#25054: Capturing start of line '^'
http://bugs.python.org/issue25054  opened by Alcolo Alcolo

#25056: no support for Bluetooth LE in socket
http://bugs.python.org/issue25056  opened by Tim.Tisdall

#25057: Make parameter of io.base to be positional and keyword
http://bugs.python.org/issue25057  opened by introom

#25058: Right square bracket argparse metavar
http://bugs.python.org/issue25058  opened by cortopy

#25059: Mistake in input-output tutorial regarding print() seperator
http://bugs.python.org/issue25059  opened by Saimadhav.Heblikar

#25061: Add native enum support for argparse
http://bugs.python.org/issue25061  opened by desbma

#25063: shutil.copyfileobj should internally use os.sendfile when poss
http://bugs.python.org/issue25063  opened by desbma

#25064: Adjust tempfile documentation for bytes filename support
http://bugs.python.org/issue25064  opened by martin.panter

#25066: Better repr for multiprocessing.synchronize objects
http://bugs.python.org/issue25066  opened by davin

#25068: The proxy key's string should ignore case.
http://bugs.python.org/issue25068  opened by Chuang Cao

#25070: Python 2.6 - Python 3.4 allows unparenthesized generator with 
http://bugs.python.org/issue25070  opened by ztane



Most recent 15 issues with no replies (15)
==========================================

#25064: Adjust tempfile documentation for bytes filename support
http://bugs.python.org/issue25064

#25056: no support for Bluetooth LE in socket
http://bugs.python.org/issue25056

#25049: Strange behavior under doctest: staticmethods have different _
http://bugs.python.org/issue25049

#25036: IDLE - infrastructure changes so editors don't assume they're 
http://bugs.python.org/issue25036

#25032: IDLE - same menubar across application
http://bugs.python.org/issue25032

#25020: IDLE - centralize ui policies and small utilities
http://bugs.python.org/issue25020

#25007: Add support of copy protocol to zlib compressors and decompres
http://bugs.python.org/issue25007

#25006: List pybind11 binding generator
http://bugs.python.org/issue25006

#24997: mock.call_args compares as equal and not equal
http://bugs.python.org/issue24997

#24985: Python install test fails - OpenSSL - "dh key too small"
http://bugs.python.org/issue24985

#24970: Make distutils.Command an ABC
http://bugs.python.org/issue24970

#24942: Remove domain from ipaddress.reverse_pointer property and add 
http://bugs.python.org/issue24942

#24940: RotatingFileHandler uses tell in non-binary mode to determine 
http://bugs.python.org/issue24940

#24936: Idle: handle 'raise' properly when running with subprocess (2.
http://bugs.python.org/issue24936

#24925: Allow doctest to find line number of __test__ strings if forma
http://bugs.python.org/issue24925



Most recent 15 issues waiting for review (15)
=============================================

#25066: Better repr for multiprocessing.synchronize objects
http://bugs.python.org/issue25066

#25064: Adjust tempfile documentation for bytes filename support
http://bugs.python.org/issue25064

#25057: Make parameter of io.base to be positional and keyword
http://bugs.python.org/issue25057

#25043: document socket constants for Bluetooth
http://bugs.python.org/issue25043

#25036: IDLE - infrastructure changes so editors don't assume they're 
http://bugs.python.org/issue25036

#25034: string.Formatter accepts empty fields but displays wrong when 
http://bugs.python.org/issue25034

#25031: IDLE - file list improvements
http://bugs.python.org/issue25031

#25027: Python 3.5.0rc3 on Windows can not load more than 127 C extens
http://bugs.python.org/issue25027

#25021: product_setstate() Out-of-bounds Read
http://bugs.python.org/issue25021

#25013: run_pdb() in test_pdb.py always returns stderr as None
http://bugs.python.org/issue25013

#25011: Smarter rl complete: hide private and special names
http://bugs.python.org/issue25011

#25003: os.urandom() should call getrandom(2) not getentropy(2) on Sol
http://bugs.python.org/issue25003

#24988: IDLE: debugger context menus not working on Mac
http://bugs.python.org/issue24988

#24982: shutil.make_archive doesn't archive empty directories
http://bugs.python.org/issue24982

#24980: Allow for providing 'on_new_thread' callback to 'concurrent.fu
http://bugs.python.org/issue24980



Top 10 most discussed issues (10)
=================================

#23517: datetime.utcfromtimestamp rounds results incorrectly
http://bugs.python.org/issue23517  52 msgs

#25002: Deprecate asyncore/asynchat
http://bugs.python.org/issue25002  17 msgs

#25027: Python 3.5.0rc3 on Windows can not load more than 127 C extens
http://bugs.python.org/issue25027  17 msgs

#24999: Segfault in test_re.test_sre_character_class_literals() when P
http://bugs.python.org/issue24999  16 msgs

#25003: os.urandom() should call getrandom(2) not getentropy(2) on Sol
http://bugs.python.org/issue25003  15 msgs

#23551: IDLE to provide menu link to PIP gui.
http://bugs.python.org/issue23551  12 msgs

#8232: webbrowser.open incomplete on Windows
http://bugs.python.org/issue8232   9 msgs

#24915: Profile Guided Optimization improvements (better training, llv
http://bugs.python.org/issue24915   9 msgs

#22980: C extension naming doesn't take bitness into account
http://bugs.python.org/issue22980   8 msgs

#24965: Implement PEP 498: Literal String Formatting
http://bugs.python.org/issue24965   8 msgs



Issues closed (48)
==================

#15989: Possible integer overflow of PyLong_AsLong() results
http://bugs.python.org/issue15989  closed by serhiy.storchaka

#16180: cannot quit pdb when there is a syntax error in the debuggee (
http://bugs.python.org/issue16180  closed by terry.reedy

#17849: Missing size argument in readline() method for httplib's class
http://bugs.python.org/issue17849  closed by martin.panter

#23144: html.parser.HTMLParser: setting 'convert_charrefs = True' lead
http://bugs.python.org/issue23144  closed by ezio.melotti

#23406: interning and list comprehension leads to unexpected behavior
http://bugs.python.org/issue23406  closed by martin.panter

#23415: add-to-pydotorg does not support .exe installers for Windows
http://bugs.python.org/issue23415  closed by larry

#24225: Idlelib: changing file names
http://bugs.python.org/issue24225  closed by terry.reedy

#24272: PEP 484 docs
http://bugs.python.org/issue24272  closed by gvanrossum

#24305: The new import system makes it inconvenient to correctly issue
http://bugs.python.org/issue24305  closed by larry

#24488: ConfigParser.getboolean fails on boolean options
http://bugs.python.org/issue24488  closed by lukasz.langa

#24585: Windows installer does not detect existing installs
http://bugs.python.org/issue24585  closed by steve.dower

#24635: test_typing is flaky
http://bugs.python.org/issue24635  closed by larry

#24684: socket.getaddrinfo(host) doesn't ensure that host.encode() ret
http://bugs.python.org/issue24684  closed by haypo

#24748: Change of behavior for importlib between 3.4 and 3.5 with DLL 
http://bugs.python.org/issue24748  closed by larry

#24889: Idle: always start with focus
http://bugs.python.org/issue24889  closed by terry.reedy

#24910: Windows MSIs don't have unique display names
http://bugs.python.org/issue24910  closed by steve.dower

#24912: The type of cached objects is mutable
http://bugs.python.org/issue24912  closed by gvanrossum

#24917: time_strftime() Buffer Over-read
http://bugs.python.org/issue24917  closed by steve.dower

#24938: Measure if _warnings.c is still worth having
http://bugs.python.org/issue24938  closed by brett.cannon

#24956: Default value for an argument that is not in the choices list 
http://bugs.python.org/issue24956  closed by r.david.murray

#24957: python -m pdb error.py:  stuck in unexitable infinite prompt l
http://bugs.python.org/issue24957  closed by terry.reedy

#24969: functools.lru_cache: a way to set decorator arguments at runti
http://bugs.python.org/issue24969  closed by rhettinger

#24984: document AF_BLUETOOTH socket address formats
http://bugs.python.org/issue24984  closed by berker.peksag

#25000: _mock_call does not properly grab args and kwargs
http://bugs.python.org/issue25000  closed by michael.foord

#25004: test_mmap should catch f.close() failure in LargeMmapTests._ma
http://bugs.python.org/issue25004  closed by martin.panter

#25005: webbrowser breaks on query strings with multiple fields on Win
http://bugs.python.org/issue25005  closed by larry

#25009: queue.Queue() does not validate the maxsize argument
http://bugs.python.org/issue25009  closed by rhettinger

#25010: minor typo in PCBuild readme.txt
http://bugs.python.org/issue25010  closed by python-dev

#25014: Add contextlib.itercm()
http://bugs.python.org/issue25014  closed by ncoghlan

#25016: defaultdict's pop gives a KeyError
http://bugs.python.org/issue25016  closed by r.david.murray

#25018: test_shutil.test_make_archive() fails on Windows 8.1
http://bugs.python.org/issue25018  closed by serhiy.storchaka

#25019: xmlparse_setattro() Type Confusion
http://bugs.python.org/issue25019  closed by serhiy.storchaka

#25022: Remove PC/example_nt/
http://bugs.python.org/issue25022  closed by python-dev

#25025: Missing 3.5.0 RC3 tarballs (FTP) on Fastly nodes
http://bugs.python.org/issue25025  closed by berker.peksag

#25028: Reading unicode json string fails depending on LANG env
http://bugs.python.org/issue25028  closed by martin.panter

#25029: MemoryError in test_strptime
http://bugs.python.org/issue25029  closed by steve.dower

#25030: io.[Text]IOBase.seek doesn't take keyword parameter
http://bugs.python.org/issue25030  closed by martin.panter

#25033: Python 2.7.10 make - fails on some Standard Library Modules
http://bugs.python.org/issue25033  closed by r.david.murray

#25037: ValueError: invalid literal for int() with base 16: b'[\r\n'
http://bugs.python.org/issue25037  closed by martin.panter

#25038: test_os.TestSendfile.test_keywords() introduced a regression
http://bugs.python.org/issue25038  closed by martin.panter

#25046: ImportError: No module named Multiprocessing
http://bugs.python.org/issue25046  closed by r.david.murray

#25048: %e Directive Missing in Datetime Documentation
http://bugs.python.org/issue25048  closed by r.david.murray

#25051: 'compile' refuses BOM.
http://bugs.python.org/issue25051  closed by eryksun

#25060: BUILD_MAP stack effect suboptimal
http://bugs.python.org/issue25060  closed by python-dev

#25062: Doc linter error:  [2] library/typing.rst:358: default role us
http://bugs.python.org/issue25062  closed by zach.ware

#25065: https://docs.python.org/library should redirect to Python 3 do
http://bugs.python.org/issue25065  closed by zach.ware

#25067: Spam
http://bugs.python.org/issue25067  closed by zach.ware

#25069: Clean issue when generator not exhausted (garbage collector re
http://bugs.python.org/issue25069  closed by r.david.murray

From python-dev at herbertkruitbosch.com  Fri Sep 11 09:56:33 2015
From: python-dev at herbertkruitbosch.com (Herbert Kruitbosch)
Date: Fri, 11 Sep 2015 09:56:33 +0200
Subject: [Python-Dev] Partial function application
Message-ID: <1441958193.1380974.380632185.1C782DFC@webmail.messagingengine.com>

Dear developers,

First of all, I'm a programmer for a data science company and I recently
graduated.

That being said, I have wondered why python does not have syntactical
support (like syntax sugar) for partial function application. I think
partial function application is a powerful concept, but also think that
the implementation in functional.partial as described here:

https://www.python.org/dev/peps/pep-0309/

is too verbose. Moreover I think the functional programming paradigm is
a powerful one in general, especially when implemented as much as
possible in an iterative language as python avoiding the typical
problems we have with purely functional languages like Haskell. An plea
for this concept is that, for example, small pieces Haskell (or
functional) code can be extremely expressive and concise.

I was wondering if there are considerations for including partial
function application?syntactically. I very often find myself writing
statements as:

data_sorted = sort(data, key = lambda x: x[0])

where I would prefer

data_sorted = sort(data, key = #1[0])

where the #1 is similar to the one used in Mathematica for the same
purpose. That is, an expression with #1  becomes an anonymous function
which takes one argument, and, obviously, if a #n is included, the
anonymous?function takes n arguments.

Notice that #1[0] does not seem like partial function application,
however it is if you (C++'isly) assume that the deference operation []
is a function dereference(subscriptable, subscript).

Obviously, I am only expecting that you get these type of suggestions
all the time and that there is a good change you do not find it adequate
for many reasons, for example keeping the language compact. I this case,
I would also like to hear so.

Yours sincerely and thank you in advance, Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/4341f242/attachment.html>

From bcannon at gmail.com  Fri Sep 11 19:42:02 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Fri, 11 Sep 2015 17:42:02 +0000
Subject: [Python-Dev] Choosing an official stance towards module
	deprecation in Python 3
In-Reply-To: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
Message-ID: <CAP1=2W4nzpc_w188JK_Y_nqCJiQZam7KX_Z0P466wU=oyVfX6w@mail.gmail.com>

Since everyone seems happy with the proposal to keep deprecated modules in
Python 3 until Python 2.7 reaches EOL, here are my proposed changes to PEP
4. If no one objects I will commit the change and then update formatter and
imp to say they will be removed once Python 2.7 is no longer supported.



--- a/pep-0004.txt Fri Sep 11 10:39:21 2015 -0700
+++ b/pep-0004.txt Fri Sep 11 10:39:24 2015 -0700
@@ -2,7 +2,7 @@
 Title: Deprecation of Standard Modules
 Version: $Revision$
 Last-Modified: $Date$
-Author: Martin von L?wis <martin at v.loewis.de>
+Author: Brett Cannon <brett at python.org>, Martin von L?wis <
martin at v.loewis.de>
 Status: Active
 Type: Process
 Content-Type: text/x-rst
@@ -50,6 +50,15 @@
 releases that immediately follows the deprecation; later releases may
 ship without the deprecated modules.

+For modules existing in both Python 2.7 and Python 3.5
+------------------------------------------------------
+In order to facilitate writing code that works in both Python 2 & 3
+simultaneously, any module deprecated from Python 3.5 onwards that
+also exists in Python 2.7 will not be removed from the standard
+library until Python 2.7 is no longer supported. Exempted from this
+is any module in the idlelib package as well as any exceptions
+granted by the Python development team.
+

 Procedure for declaring a module undeprecated
 =============================================
@@ -258,12 +267,16 @@
                    Remove from 2.7
     Documentation: None

+    Module name:   imp
+    Rationale:     Replaced by the importlib module.
+    Date:          2013-02-10
+    Documentation: Deprecated as of Python 3.4.
+
     Module name:   formatter
     Rationale:     Lack of use in the community, no tests to keep
                    code working.
-    Documentation: Deprecated as of Python 3.4 by raising
-                   PendingDeprecationWarning. Slated for removal in
-                   Python 3.6.
+    Date:          2013-08-12
+    Documentation: Deprecated as of Python 3.4.


 Deprecation of modules removed in Python 3.0



On Tue, 8 Sep 2015 at 09:59 Brett Cannon <bcannon at gmail.com> wrote:

> There are two discussions going on in the issue tracker about deprecating
> some modules and it has led to the inevitable discussion of Python 2/3
> compatibility (I'm not even going to bother mentioning the issue #s as this
> thread is not about the modules specifically but module deprecation in
> general). Because I'm tired of rehashing the same discussion every time a
> module deprecation comes up I would like to make an official decision that
> we can follow any time we decide to deprecate a module.
>
> The approaches to module deprecation I have seen are:
> 1. Nothing changes to the deprecation process; you deprecate a module and
> remove it in one to two releases
> 2. Deprecate the module but with no plans for removal until Python 2.7
> reaches its EOL (I have been calling this Python 4)
> 3. Document the deprecation but no actual code deprecation
>
> I'm personally in the #2 camp. I want users to be fully aware that the
> module in question is not being updated and possibly not even getting
> non-critical bugfixes, but it's still there in Python 3 in order to make
> sure that you can have code which straddles Python 2 & 3 more easily.
>
> I don't like #1 because when the module exists in python 2.7 as it makes
> transitioning from Python 2 a bit harder. Leaving code in the stdlib as
> deprecated isn't going to kill us, especially if we make it clear the code
> only exists for transitioning purposes and you very well may have to work
> around any bugs you come across (and yes, this means changing my stance for
> the formatter module's deprecation).
>
> I don't like #3 because if you have an API memorized or you copied some
> code you found online you very well may not realize a module is deprecated.
> It's not difficult to silence a deprecation warning and you can make it so
> that even if you use -Werror your deprecated module imports continue to
> work without throwing an exception while all other deprecations do throw an
> exception.
>
> Whatever decision we come to I will update PEP 4 and then personally go
> through the various deprecated modules in Python 3.6 and tweak them as
> necessary to follow whatever policy we come up with.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/8d698c37/attachment.html>

From guido at python.org  Fri Sep 11 19:47:36 2015
From: guido at python.org (Guido van Rossum)
Date: Fri, 11 Sep 2015 10:47:36 -0700
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <CAP1=2W4nzpc_w188JK_Y_nqCJiQZam7KX_Z0P466wU=oyVfX6w@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
 <CAP1=2W4nzpc_w188JK_Y_nqCJiQZam7KX_Z0P466wU=oyVfX6w@mail.gmail.com>
Message-ID: <CAP7+vJ+o5BB8eBjG2BgbTXDx1pzrCMSPjs=0adSRbuA+2dxK8Q@mail.gmail.com>

+1.

The language seems a bit ambiguous: "deprecated from 3.5 onward" -- what if
a module was deprecated in 3.3 or 3.4 but still present in 3.5? I assume
those are also included, but the language makes it possible to interpret
this as applying only to modules that were first marked as deprecated in
3.5...

On Fri, Sep 11, 2015 at 10:42 AM, Brett Cannon <bcannon at gmail.com> wrote:

> Since everyone seems happy with the proposal to keep deprecated modules in
> Python 3 until Python 2.7 reaches EOL, here are my proposed changes to PEP
> 4. If no one objects I will commit the change and then update formatter and
> imp to say they will be removed once Python 2.7 is no longer supported.
>
>
>
> --- a/pep-0004.txt Fri Sep 11 10:39:21 2015 -0700
> +++ b/pep-0004.txt Fri Sep 11 10:39:24 2015 -0700
> @@ -2,7 +2,7 @@
>  Title: Deprecation of Standard Modules
>  Version: $Revision$
>  Last-Modified: $Date$
> -Author: Martin von L?wis <martin at v.loewis.de>
> +Author: Brett Cannon <brett at python.org>, Martin von L?wis <
> martin at v.loewis.de>
>  Status: Active
>  Type: Process
>  Content-Type: text/x-rst
> @@ -50,6 +50,15 @@
>  releases that immediately follows the deprecation; later releases may
>  ship without the deprecated modules.
>
> +For modules existing in both Python 2.7 and Python 3.5
> +------------------------------------------------------
> +In order to facilitate writing code that works in both Python 2 & 3
> +simultaneously, any module deprecated from Python 3.5 onwards that
> +also exists in Python 2.7 will not be removed from the standard
> +library until Python 2.7 is no longer supported. Exempted from this
> +is any module in the idlelib package as well as any exceptions
> +granted by the Python development team.
> +
>
>  Procedure for declaring a module undeprecated
>  =============================================
> @@ -258,12 +267,16 @@
>                     Remove from 2.7
>      Documentation: None
>
> +    Module name:   imp
> +    Rationale:     Replaced by the importlib module.
> +    Date:          2013-02-10
> +    Documentation: Deprecated as of Python 3.4.
> +
>      Module name:   formatter
>      Rationale:     Lack of use in the community, no tests to keep
>                     code working.
> -    Documentation: Deprecated as of Python 3.4 by raising
> -                   PendingDeprecationWarning. Slated for removal in
> -                   Python 3.6.
> +    Date:          2013-08-12
> +    Documentation: Deprecated as of Python 3.4.
>
>
>  Deprecation of modules removed in Python 3.0
>
>
>
> On Tue, 8 Sep 2015 at 09:59 Brett Cannon <bcannon at gmail.com> wrote:
>
>> There are two discussions going on in the issue tracker about deprecating
>> some modules and it has led to the inevitable discussion of Python 2/3
>> compatibility (I'm not even going to bother mentioning the issue #s as this
>> thread is not about the modules specifically but module deprecation in
>> general). Because I'm tired of rehashing the same discussion every time a
>> module deprecation comes up I would like to make an official decision that
>> we can follow any time we decide to deprecate a module.
>>
>> The approaches to module deprecation I have seen are:
>> 1. Nothing changes to the deprecation process; you deprecate a module and
>> remove it in one to two releases
>> 2. Deprecate the module but with no plans for removal until Python 2.7
>> reaches its EOL (I have been calling this Python 4)
>> 3. Document the deprecation but no actual code deprecation
>>
>> I'm personally in the #2 camp. I want users to be fully aware that the
>> module in question is not being updated and possibly not even getting
>> non-critical bugfixes, but it's still there in Python 3 in order to make
>> sure that you can have code which straddles Python 2 & 3 more easily.
>>
>> I don't like #1 because when the module exists in python 2.7 as it makes
>> transitioning from Python 2 a bit harder. Leaving code in the stdlib as
>> deprecated isn't going to kill us, especially if we make it clear the code
>> only exists for transitioning purposes and you very well may have to work
>> around any bugs you come across (and yes, this means changing my stance for
>> the formatter module's deprecation).
>>
>> I don't like #3 because if you have an API memorized or you copied some
>> code you found online you very well may not realize a module is deprecated.
>> It's not difficult to silence a deprecation warning and you can make it so
>> that even if you use -Werror your deprecated module imports continue to
>> work without throwing an exception while all other deprecations do throw an
>> exception.
>>
>> Whatever decision we come to I will update PEP 4 and then personally go
>> through the various deprecated modules in Python 3.6 and tweak them as
>> necessary to follow whatever policy we come up with.
>>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/d71cd3d4/attachment-0001.html>

From brett at python.org  Fri Sep 11 19:52:07 2015
From: brett at python.org (Brett Cannon)
Date: Fri, 11 Sep 2015 17:52:07 +0000
Subject: [Python-Dev] Partial function application
In-Reply-To: <1441958193.1380974.380632185.1C782DFC@webmail.messagingengine.com>
References: <1441958193.1380974.380632185.1C782DFC@webmail.messagingengine.com>
Message-ID: <CAP1=2W4oAf62we6+ADbnssjZ90677F5gwo0ux-P4hCuG7sGutQ@mail.gmail.com>

On Fri, 11 Sep 2015 at 10:41 Herbert Kruitbosch <
python-dev at herbertkruitbosch.com> wrote:

> Dear developers,
>
> First of all, I'm a programmer for a data science company and I recently
> graduated.
>
> That being said, I have wondered why python does not have syntactical
> support (like syntax sugar) for partial function application. I think
> partial function application is a powerful concept, but also think that the
> implementation in functional.partial as described here:
>
> https://www.python.org/dev/peps/pep-0309/
>
> is too verbose. Moreover I think the functional programming paradigm is a
> powerful one in general, especially when implemented as much as possible in
> an iterative language as python avoiding the typical problems we have with
> purely functional languages like Haskell. An plea for this concept is that,
> for example, small pieces Haskell (or functional) code can be extremely
> expressive and concise.
>
> I was wondering if there are considerations for including partial function
> application syntactically. I very often find myself writing statements as:
>
> data_sorted = sort(data, key = lambda x: x[0])
>

To start off, I wouldn't write it that way, but this way:

data_sorted - sort(data, key=operator.itemgetter(0))


>
> where I would prefer
>
> data_sorted = sort(data, key = #1[0])
>

That syntax won't work because `#` is used to start a comment and there is
no way to disambiguate that in the grammar.


>
> where the #1 is similar to the one used in Mathematica for the same
> purpose. That is, an expression with #1 becomes an anonymous function which
> takes one argument, and, obviously, if a #n is included, the
> anonymous function takes n arguments.
>
> Notice that #1[0] does not seem like partial function application, however
> it is if you (C++'isly) assume that the deference operation [] is a
> function dereference(subscriptable, subscript).
>
> Obviously, I am only expecting that you get these type of suggestions all
> the time and that there is a good change you do not find it adequate for
> many reasons, for example keeping the language compact. I this case, I
> would also like to hear so.
>

In my code the few times I want partial function applications I have found
the functions in the operator module meet that need, else functools.partial
or a quickly written closure do the trick. I don't think dedicated syntax
is warranted when those other options already exist  to meet the same need.


>
> Yours sincerely and thank you in advance,
>

Thanks for the suggestion!

-Brett


> Herbert
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/c57111a4/attachment.html>

From bcannon at gmail.com  Fri Sep 11 19:57:15 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Fri, 11 Sep 2015 17:57:15 +0000
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <CAP7+vJ+o5BB8eBjG2BgbTXDx1pzrCMSPjs=0adSRbuA+2dxK8Q@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
 <CAP1=2W4nzpc_w188JK_Y_nqCJiQZam7KX_Z0P466wU=oyVfX6w@mail.gmail.com>
 <CAP7+vJ+o5BB8eBjG2BgbTXDx1pzrCMSPjs=0adSRbuA+2dxK8Q@mail.gmail.com>
Message-ID: <CAP1=2W4Y4D4kkGALM+Oz4-NiLJZddS3ztt9LxvfSqpLs0DnWyw@mail.gmail.com>

Tweaked wording that clearly state the mere existence in both Python 2.7
and 3.5 means the module won't be  removed until Python 2.7 is EOL'ed:

In order to facilitate writing code that works in both Python 2 & 3
simultaneously, any module that exists in both Python 3.5 and
Python 2.7 will not be removed from the standard library until
Python 2.7 is no longer supported as specified by PEP 373. Exempted
from this rule is any module in the idlelib package as well as any
exceptions granted by the Python development team.

On Fri, 11 Sep 2015 at 10:47 Guido van Rossum <guido at python.org> wrote:

> +1.
>
> The language seems a bit ambiguous: "deprecated from 3.5 onward" -- what
> if a module was deprecated in 3.3 or 3.4 but still present in 3.5? I assume
> those are also included, but the language makes it possible to interpret
> this as applying only to modules that were first marked as deprecated in
> 3.5...
>
> On Fri, Sep 11, 2015 at 10:42 AM, Brett Cannon <bcannon at gmail.com> wrote:
>
>> Since everyone seems happy with the proposal to keep deprecated modules
>> in Python 3 until Python 2.7 reaches EOL, here are my proposed changes to
>> PEP 4. If no one objects I will commit the change and then update formatter
>> and imp to say they will be removed once Python 2.7 is no longer supported.
>>
>>
>>
>> --- a/pep-0004.txt Fri Sep 11 10:39:21 2015 -0700
>> +++ b/pep-0004.txt Fri Sep 11 10:39:24 2015 -0700
>> @@ -2,7 +2,7 @@
>>  Title: Deprecation of Standard Modules
>>  Version: $Revision$
>>  Last-Modified: $Date$
>> -Author: Martin von L?wis <martin at v.loewis.de>
>> +Author: Brett Cannon <brett at python.org>, Martin von L?wis <
>> martin at v.loewis.de>
>>  Status: Active
>>  Type: Process
>>  Content-Type: text/x-rst
>> @@ -50,6 +50,15 @@
>>  releases that immediately follows the deprecation; later releases may
>>  ship without the deprecated modules.
>>
>> +For modules existing in both Python 2.7 and Python 3.5
>> +------------------------------------------------------
>> +In order to facilitate writing code that works in both Python 2 & 3
>> +simultaneously, any module deprecated from Python 3.5 onwards that
>> +also exists in Python 2.7 will not be removed from the standard
>> +library until Python 2.7 is no longer supported. Exempted from this
>> +is any module in the idlelib package as well as any exceptions
>> +granted by the Python development team.
>> +
>>
>>  Procedure for declaring a module undeprecated
>>  =============================================
>> @@ -258,12 +267,16 @@
>>                     Remove from 2.7
>>      Documentation: None
>>
>> +    Module name:   imp
>> +    Rationale:     Replaced by the importlib module.
>> +    Date:          2013-02-10
>> +    Documentation: Deprecated as of Python 3.4.
>> +
>>      Module name:   formatter
>>      Rationale:     Lack of use in the community, no tests to keep
>>                     code working.
>> -    Documentation: Deprecated as of Python 3.4 by raising
>> -                   PendingDeprecationWarning. Slated for removal in
>> -                   Python 3.6.
>> +    Date:          2013-08-12
>> +    Documentation: Deprecated as of Python 3.4.
>>
>>
>>  Deprecation of modules removed in Python 3.0
>>
>>
>>
>> On Tue, 8 Sep 2015 at 09:59 Brett Cannon <bcannon at gmail.com> wrote:
>>
>>> There are two discussions going on in the issue tracker about
>>> deprecating some modules and it has led to the inevitable discussion of
>>> Python 2/3 compatibility (I'm not even going to bother mentioning the issue
>>> #s as this thread is not about the modules specifically but module
>>> deprecation in general). Because I'm tired of rehashing the same discussion
>>> every time a module deprecation comes up I would like to make an official
>>> decision that we can follow any time we decide to deprecate a module.
>>>
>>> The approaches to module deprecation I have seen are:
>>> 1. Nothing changes to the deprecation process; you deprecate a module
>>> and remove it in one to two releases
>>> 2. Deprecate the module but with no plans for removal until Python 2.7
>>> reaches its EOL (I have been calling this Python 4)
>>> 3. Document the deprecation but no actual code deprecation
>>>
>>> I'm personally in the #2 camp. I want users to be fully aware that the
>>> module in question is not being updated and possibly not even getting
>>> non-critical bugfixes, but it's still there in Python 3 in order to make
>>> sure that you can have code which straddles Python 2 & 3 more easily.
>>>
>>> I don't like #1 because when the module exists in python 2.7 as it makes
>>> transitioning from Python 2 a bit harder. Leaving code in the stdlib as
>>> deprecated isn't going to kill us, especially if we make it clear the code
>>> only exists for transitioning purposes and you very well may have to work
>>> around any bugs you come across (and yes, this means changing my stance for
>>> the formatter module's deprecation).
>>>
>>> I don't like #3 because if you have an API memorized or you copied some
>>> code you found online you very well may not realize a module is deprecated.
>>> It's not difficult to silence a deprecation warning and you can make it so
>>> that even if you use -Werror your deprecated module imports continue to
>>> work without throwing an exception while all other deprecations do throw an
>>> exception.
>>>
>>> Whatever decision we come to I will update PEP 4 and then personally go
>>> through the various deprecated modules in Python 3.6 and tweak them as
>>> necessary to follow whatever policy we come up with.
>>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>>
> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/332fe520/attachment.html>

From alexander.belopolsky at gmail.com  Fri Sep 11 20:36:30 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Sep 2015 14:36:30 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
Message-ID: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>

On Tue, Sep 8, 2015 at 8:27 PM, Guido van Rossum <guido at python.org> wrote:

> Now if only PEP 495 could be as easy... :-)
>

I think we nailed the hard issues there.   The next update will have a
restored hash invariant and == that satisfies all three axioms of
equivalency.  I am not making a better progress because I am debating with
myself about the fate of < and > comparisons.  Cross-zone comparisons
strike in full force there as well because two times ordered in UTC may
appear in the opposite order in the local timezone where the clock is moved
back.  Note that I saved the hash invariant and the transitivity of == at
the expense of the loss of trichotomy in comparisons (we will have pairs of
aware datetimes that are neither equal nor < nor >).  I don't think we need
to change anything with < and > comparisons, but I am trying to come up
with the arguments that will at least be convincing to myself.  (I suspect
that if I am not the only one who worries about this, the other such people
can be counted by the values of the fold flag. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/ed18ac79/attachment.html>

From python-dev at herbertkruitbosch.com  Fri Sep 11 20:08:46 2015
From: python-dev at herbertkruitbosch.com (Herbert Kruitbosch)
Date: Fri, 11 Sep 2015 20:08:46 +0200
Subject: [Python-Dev] Partial function application
In-Reply-To: <CAP1=2W4oAf62we6+ADbnssjZ90677F5gwo0ux-P4hCuG7sGutQ@mail.gmail.com>
References: <1441958193.1380974.380632185.1C782DFC@webmail.messagingengine.com>
 <CAP1=2W4oAf62we6+ADbnssjZ90677F5gwo0ux-P4hCuG7sGutQ@mail.gmail.com>
Message-ID: <1441994926.3462011.381161417.2A2E42A7@webmail.messagingengine.com>

> On Fri, 11 Sep 2015 at 10:41 Herbert Kruitbosch <python-dev at herbertkruitbosch.com> wrote:
> __
>> data_sorted = sort(data, key = #1[0])
>
> That syntax won't work because `#` is used to start a comment and
> there is no way to disambiguate that in the grammar.

Obviously :) The #-syntax is used by Mathematica, which is why I used it
here. As you stated, it is not adequate for python3. You could imagine a
$n or ***n syntax. I'm not in any way well informed on the python3
syntax, nor what would be aesthetically appealing and readable.

>> where the #1 is similar to the one used in Mathematica for the same
>> purpose. That is, an expression with #1  becomes an anonymous
>> function which takes one argument, and, obviously, if a #n is
>> included, the anonymous?function takes n arguments.
>>
>> Notice that #1[0] does not seem like partial function application,
>> however it is if you (C++'isly) assume that the deference operation
>> [] is a function dereference(subscriptable, subscript).
>>
>> Obviously, I am only expecting that you get these type of suggestions
>> all the time and that there is a good change you do not find it
>> adequate for many reasons, for example keeping the language compact.
>> I this case, I would also like to hear so.
>
> In my code the few times I want partial function applications I have
> found the functions in the operator module meet that need, else
> functools.partial or a quickly written closure do the trick. I don't
> think dedicated syntax is warranted when those other options already
> exist ?to meet the same need.

I would guess it depends on personal preference. And like you stated,
there are many clear and intuitive workarounds. I never got to the point
where functools.partial and operator.* became part of my coding
equipment, and I  would adore this feature. I'm very curious if there
are more people on my team, but am also interested to hear about
opinions against such a feature.

> Thanks for the suggestion!

No problem, and thank you for reading it :)

Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/c0757393/attachment.html>

From tjreedy at udel.edu  Sat Sep 12 00:13:26 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 11 Sep 2015 18:13:26 -0400
Subject: [Python-Dev] Partial function application
In-Reply-To: <1441958193.1380974.380632185.1C782DFC@webmail.messagingengine.com>
References: <1441958193.1380974.380632185.1C782DFC@webmail.messagingengine.com>
Message-ID: <msvjn0$7kr$1@ger.gmane.org>

On 9/11/2015 3:56 AM, Herbert Kruitbosch wrote:


> I was wondering if there are considerations for including partial
> function application syntactically. I very often find myself writing
> statements as:
> data_sorted = sort(data, key = lambda x: x[0])
> where I would prefer
> data_sorted = sort(data, key = #1[0])
> where the #1 is similar to the one used in Mathematica for the same
> purpose. That is, an expression with #1 becomes an anonymous function
> which takes one argument, and, obviously, if a #n is included, the
> anonymous function takes n arguments.

For future reference, ideas like this belong on the python-list or 
python-ideas list. Pydev is more for discussion of policy, concrete 
issues for the next releases, and approval ideas that have been fully 
fleshed out in the form of a PEP.

-- 
Terry Jan Reedy


From raymond.hettinger at gmail.com  Sat Sep 12 00:39:20 2015
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Fri, 11 Sep 2015 18:39:20 -0400
Subject: [Python-Dev] Choosing an official stance towards module
	deprecation in Python 3
In-Reply-To: <CAP1=2W4Y4D4kkGALM+Oz4-NiLJZddS3ztt9LxvfSqpLs0DnWyw@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
 <CAP1=2W4nzpc_w188JK_Y_nqCJiQZam7KX_Z0P466wU=oyVfX6w@mail.gmail.com>
 <CAP7+vJ+o5BB8eBjG2BgbTXDx1pzrCMSPjs=0adSRbuA+2dxK8Q@mail.gmail.com>
 <CAP1=2W4Y4D4kkGALM+Oz4-NiLJZddS3ztt9LxvfSqpLs0DnWyw@mail.gmail.com>
Message-ID: <C2EA2E30-E15A-4D75-B14F-4DAA4DB60495@gmail.com>


> On Sep 11, 2015, at 1:57 PM, Brett Cannon <bcannon at gmail.com> wrote:
> 
> In order to facilitate writing code that works in both Python 2 & 3
> simultaneously, any module that exists in both Python 3.5 and
> Python 2.7 will not be removed from the standard library until
> Python 2.7 is no longer supported as specified by PEP 373. Exempted
> from this rule is any module in the idlelib package as well as any
> exceptions granted by the Python development team.

I think that reads nicely.  It makes a clear contract with developers
letting them know that we will avoid making their life unnecessarily difficult.


Raymond



From tjreedy at udel.edu  Sat Sep 12 00:45:29 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 11 Sep 2015 18:45:29 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
Message-ID: <msvlj4$423$1@ger.gmane.org>

On 9/11/2015 2:36 PM, Alexander Belopolsky wrote:
>
> On Tue, Sep 8, 2015 at 8:27 PM, Guido van Rossum <guido at python.org
> <mailto:guido at python.org>> wrote:
>
>     Now if only PEP 495 could be as easy... :-)
>
>
> I think we nailed the hard issues there.   The next update will have a
> restored hash invariant and == that satisfies all three axioms of
> equivalency.

You are trying to sanely deal with politically mandated insanity.
I think it essential that you not introduce mathematical insanity, but 
whatever you do will be less than completely satisfactory.

>  I am not making a better progress because I am debating
> with myself about the fate of < and > comparisons.

Both should not be true for the same pair ;-)

 > Cross-zone
> comparisons strike in full force there as well because two times ordered
> in UTC may appear in the opposite order in the local timezone where the
> clock is moved back.

Comparison of absolute Newtonion time, represented by UTC, and local 
'clock face' relative time with political hacks, are different concepts. 
  If I get up at 8:00 AM (in Delaware, USA) and you get up at 8:01 
wherever you are, which of us got up earlier?  It depends on what 
'earlier' means in the context and purpose of the question. Are we 
asking about wakeup discipline, or email exchange?

Pick whichever you and whoever consider to be most useful.  Presuming 
that one can convert to UTC before comparision, I suspect the local 
version.

>  Note that I saved the hash invariant and the
> transitivity of == at the expense of the loss of trichotomy in
> comparisons (we will have pairs of aware datetimes that are neither
> equal nor < nor >).

That is the nature of partial orders.

>  I don't think we need to change anything with < and
>  > comparisons,

I am guessing that the comparisons are currently local.

> but I am trying to come up with the arguments that will
> at least be convincing to myself.  (I suspect that if I am not the only
> one who worries about this, the other such people can be counted by the
> values of the fold flag. :-)

Good luck ;-)

-- 
Terry Jan Reedy


From alexander.belopolsky at gmail.com  Sat Sep 12 02:40:44 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Sep 2015 20:40:44 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <msvlj4$423$1@ger.gmane.org>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
Message-ID: <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>

On Fri, Sep 11, 2015 at 6:45 PM, Terry Reedy <tjreedy at udel.edu> wrote:

>
>> I think we nailed the hard issues there.   The next update will have a
>> restored hash invariant and == that satisfies all three axioms of
>> equivalency.
>>
>
> You are trying to sanely deal with politically mandated insanity.
> I think it essential that you not introduce mathematical insanity, but
> whatever you do will be less than completely satisfactory.


The insanity I am dealing with now is specific to Python datetime which
wisely blocks any binary operation that involves naive and aware datetimes,
but allows comparisons and subtractions of datetimes with different
timezones.  This is not an unusual situation given a limited supply of
binary operators, Python has to reuse them in less than ideal ways. For
example,

>>> a = 'a'
>>> b = 'b'
>>> c = 5
>>> (a + b) * c == a * c + b * c
False

is less than ideal if you hold the distributive law of arithmetic sacred.
Similarly, '-' is reused in datetime for two different operation: if s and
t are datetimes with the same tzinfo, s - t tells you how far to move hands
on the local clock to arrive at s when you start at t.  This is clearly a
very useful operation that forms the basis of everything else that we do in
datetime.  Note that for this operation, it does not matter what kind of
time your clock is showing or whether it is running at all.  We are not
asking how long one needs to wait to see s after t was shown.  We are just
asking how far to turn the knob on the back of the clock.  This operation
does not make sense when s and t have different tzinfos, so in this case a
'-' is reused for a different operation.  This operation is much more
involved.  We require an existence of some universal time (UTC) and a rule
to convert s and t to that time and define s - t as s.astimezone(UTC) -
t.timezone(UTC).  In the later expression '-' is taken in the "turns of the
knob" sense because the operands are in the same timezone (UTC).

Clearly, when we "abuse" the mathematical notation in this way, we cannot
expect mathematical identities to hold and it is easy to find for example,
aware datetimes u, t, and s such that (t - u) - (s - u) ? t - s.

Deciding when it is ok to sacrifice mathematical purity for practical
convenience is an art, not a science.  The case of interzone datetime
arithmetic is a borderline case.  I would much rather let users decide what
they want: s.astimezone(t.tzinfo) - t, s - t.astimezone(s.tzinfo) or
 s.astimezone(UTC) - t.astimezone(UTC) and not assume that s - t "clearly"
means the last of the three choices.  But the decision to allow interzone t
- s was made long time ago and it is a PEP 495 goal to change that.


>
>  I am not making a better progress because I am debating
>> with myself about the fate of < and > comparisons.
>>
>
> Both should not be true for the same pair ;-)


I'll give you that.  No worries.

>
>
> > Cross-zone
>
>> comparisons strike in full force there as well because two times ordered
>> in UTC may appear in the opposite order in the local timezone where the
>> clock is moved back.
>>
>
> Comparison of absolute Newtonion time, represented by UTC, and local
> 'clock face' relative time with political hacks, are different concepts.
> If I get up at 8:00 AM (in Delaware, USA) and you get up at 8:01 wherever
> you are, which of us got up earlier?  It depends on what 'earlier' means
> in the context and purpose of the question. Are we asking about wakeup
> discipline, or email exchange?
>

There is no "earlier" or "later".  There are "lesser" and "greater" which
are already defined for all pairs of aware datetimes.  PEP 495 doubles the
set of possible datetimes and they don't fit in one straight line anymore.
The whole point of PEP 495 is to introduce a "fold" in the timeline.


> Pick whichever you and whoever consider to be most useful.  Presuming that
> one can convert to UTC before comparision, I suspect the local version.


It is more delicate than that.  Are you willing to accept a possibility of
an infinite loop if you run a binary search for a UTC time in an ordered
list of local times?  We tolerate that with numbers, but you only have this
risk when you have a "nan" in your list.  I don't think the new PEP 495
datetimes will be nearly as bad as floating point NaNs: at least datetime
== will still be reflexive and transitive unlike  floating point ==.  Still
I am not ready to say that we have solved all the puzzles yet.  But we are
close.


>
>  Note that I saved the hash invariant and the
>> transitivity of == at the expense of the loss of trichotomy in
>> comparisons (we will have pairs of aware datetimes that are neither
>> equal nor < nor >).
>>
>
> That is the nature of partial orders.


Yes, but are we willing to accept that datetimes have only partial order?
And in Python 3 we consider comparison between unorderable objects to be an
error instead of silently returning False.  I am strongly against allowing
exceptions in astimezone(), ==, or hash()

>
>
>  I don't think we need to change anything with < and
>>  > comparisons,
>>
>
> I am guessing that the comparisons are currently local.


Yes, they are for naive datetime pairs and pairs with items sharing
tzinfo.  The problem is what to do with the interzone comparisons.


>
>
> but I am trying to come up with the arguments that will
>> at least be convincing to myself.  (I suspect that if I am not the only
>> one who worries about this, the other such people can be counted by the
>> values of the fold flag. :-)
>>
>
> Good luck ;-)


Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/569fbd4c/attachment.html>

From random832 at fastmail.com  Sat Sep 12 02:56:27 2015
From: random832 at fastmail.com (Random832)
Date: Fri, 11 Sep 2015 20:56:27 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
	is ready for pronouncement
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
Message-ID: <m2a8ssihfo.fsf@fastmail.com>

Alexander Belopolsky <alexander.belopolsky at gmail.com> writes:
> There is no "earlier" or "later". There are "lesser" and "greater"
> which are already defined for all pairs of aware datetimes. PEP 495
> doubles the set of possible datetimes

That depends on what you mean by "possible".

> and they don't fit in one
> straight line anymore. The whole point of PEP 495 is to introduce a
> "fold" in the timeline.

That doesn't make sense. Within a given timezone, any given moment of
UTC time (which is a straight line [shut up, no leap seconds here]) maps
to only one local time. The point of PEP 495 seems to be to eliminate
the cases where two UTC moments map to the same aware local time.

Out of curiosity, can "fold" ever be any value other than 0 or 1? I
don't know if there are any real-world examples (doubt it), but I could
easily contrive a timezone definition that had three of a particular
clock time.

> Yes, but are we willing to accept that datetimes have only partial
> order?

I apparently haven't been following the discussion closely enough to
understand how this can possibly be the case outside cases I assumed it
already was (naive vs aware comparisons being invalid).


From v+python at g.nevcal.com  Sat Sep 12 03:12:05 2015
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Fri, 11 Sep 2015 18:12:05 -0700
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
Message-ID: <55F37BE5.6030709@g.nevcal.com>

On 9/11/2015 5:40 PM, Alexander Belopolsky wrote:

> The insanity I am dealing with now
...
> But the decision to allow interzone t - s was made long time ago and 
> it is a PEP 495 goal to change that.

The first few paragraphs you wrote, which I elided, are a great 
explanation of why things work in ways that might be unexpected, and by 
including in the descriptions other things that might be unexpected, it 
helps people realize that the need to understand what the operators 
really mean, when applied to classes, rather than numbers.  Of course, 
even floating point number operations and integer division only 
approximate mathematical reality, if you are looking for more examples.

But the beginning phrase about "insanity" should probably be elided in 
documentation, yet the body could very well be appropriate for tutorial 
documentation, even if not reference documentation, although I'd not 
object to finding it there.

The last phrase, about it being a PEP 495 goal to change that, might be 
true, but if it changes it, then it would be a confusing and backward 
incompatible change.

>
> Yes, but are we willing to accept that datetimes have only partial order?

That's what the politicians gave us. These are datetime objects, not 
mathematical numbers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/af98dcf3/attachment.html>

From alexander.belopolsky at gmail.com  Sat Sep 12 03:23:45 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Sep 2015 21:23:45 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <m2a8ssihfo.fsf@fastmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <m2a8ssihfo.fsf@fastmail.com>
Message-ID: <CAP7h-xaCYNRBYYByPzgBWYQsmrjxxK+65QXNyD4NF=3ooHjBrw@mail.gmail.com>

On Fri, Sep 11, 2015 at 8:56 PM, Random832 <random832 at fastmail.com> wrote:

> Alexander Belopolsky <alexander.belopolsky at gmail.com> writes:
> > There is no "earlier" or "later". There are "lesser" and "greater"
> > which are already defined for all pairs of aware datetimes. PEP 495
> > doubles the set of possible datetimes
>
> That depends on what you mean by "possible".
>

What exactly depends on the meaning of  "possible"?  In this context
"possible" means "can appear in a Python program."



> > and they don't fit in one
> > straight line anymore. The whole point of PEP 495 is to introduce a
> > "fold" in the timeline.
>
> That doesn't make sense. Within a given timezone, any given moment of
> UTC time (which is a straight line [shut up, no leap seconds here]) maps
> to only one local time. The point of PEP 495 seems to be to eliminate
> the cases where two UTC moments map to the same aware local time.
>

Yes, but it does that at the cost of introducing the second local "01:30"
which is "later" than the first "01:40" while "obviously" (and according to
the current datetime rules)  "01:30" < "01:40".

>
> Out of curiosity, can "fold" ever be any value other than 0 or 1?
>

Thankfully, no.

>
> > Yes, but are we willing to accept that datetimes have only partial
> > order?
>
> I apparently haven't been following the discussion closely enough to
> understand how this can possibly be the case outside cases I assumed it
> already was (naive vs aware comparisons being invalid).


Local times that fall in the spring-forward gap cannot be ordered interzone
even without PEP 495.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/6091e83f/attachment.html>

From alexander.belopolsky at gmail.com  Sat Sep 12 03:26:38 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Sep 2015 21:26:38 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <55F37BE5.6030709@g.nevcal.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <55F37BE5.6030709@g.nevcal.com>
Message-ID: <CAP7h-xb2483i3hBwoPO=kN5nn+YKadDzERv2UfBVDvh8hdsmJg@mail.gmail.com>

On Fri, Sep 11, 2015 at 9:12 PM, Glenn Linderman <v+python at g.nevcal.com>
wrote:
[Alexander Belopolsky]

> But the decision to allow interzone t - s was made long time ago and it is
> a PEP 495 goal to change that.
>
> The last phrase, about it being a PEP 495 goal to change that, might be
> true, but if it changes it, then it would be a confusing and backward
> incompatible change.


Oops, a Freudian slip.  It is *not* a PEP 495 goal to change that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/56b7e3f1/attachment.html>

From alexander.belopolsky at gmail.com  Sat Sep 12 03:39:20 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Sep 2015 21:39:20 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <55F37BE5.6030709@g.nevcal.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <55F37BE5.6030709@g.nevcal.com>
Message-ID: <CAP7h-xavk8uQ-9PCTWjDy+_hxFRAZm1MyeDBupCipn7MwF0OQg@mail.gmail.com>

On Fri, Sep 11, 2015 at 9:12 PM, Glenn Linderman <v+python at g.nevcal.com>
wrote:

> That's what the politicians gave us. These are datetime objects, not
> mathematical numbers.


That's an argument for not defining mathematical operations like <, > or -
on them, but you cannot deny the convenience of having those.  Besides,
datetime objects are mathematical numbers as long as you only deal with one
timezone or restrict yourself to naive instances.  The problem with
interzone subtraction, for example, is that we start with nice (not so
little) integers and define an operation that is effectively op(x, y) =
f(x) - g(y) where f and g are arbitrary functions under the control of
the politicians.
It is convenient to equate op with subtraction and if f and g are simple
shifts, it is a subtraction, but in general it is not.  This is the root of
the problem, but datetime objects are still as close to mathematical
numbers as Python ints.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/cbe9765a/attachment.html>

From v+python at g.nevcal.com  Sat Sep 12 03:51:47 2015
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Fri, 11 Sep 2015 18:51:47 -0700
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <CAP7h-xavk8uQ-9PCTWjDy+_hxFRAZm1MyeDBupCipn7MwF0OQg@mail.gmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <55F37BE5.6030709@g.nevcal.com>
 <CAP7h-xavk8uQ-9PCTWjDy+_hxFRAZm1MyeDBupCipn7MwF0OQg@mail.gmail.com>
Message-ID: <55F38533.2060603@g.nevcal.com>

On 9/11/2015 6:39 PM, Alexander Belopolsky wrote:
> On Fri, Sep 11, 2015 at 9:12 PM, Glenn Linderman 
> <v+python at g.nevcal.com <mailto:v+python at g.nevcal.com>> wrote:
>
>     That's what the politicians gave us. These are datetime objects,
>     not mathematical numbers.
>
>
> That's an argument for not defining mathematical operations like <, > 
> or - on them, but you cannot deny the convenience of having those. 

It wasn't intended to argue for not defining the operations, just 
intended to justify that it is partial ordering... if the associated 
timezone implements daylight saving.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/9e72a566/attachment-0001.html>

From random832 at fastmail.com  Sat Sep 12 04:00:30 2015
From: random832 at fastmail.com (Random832)
Date: Fri, 11 Sep 2015 22:00:30 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
	is ready for pronouncement
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <m2a8ssihfo.fsf@fastmail.com>
 <CAP7h-xaCYNRBYYByPzgBWYQsmrjxxK+65QXNyD4NF=3ooHjBrw@mail.gmail.com>
Message-ID: <m24mj0iegx.fsf@fastmail.com>

Alexander Belopolsky <alexander.belopolsky at gmail.com> writes:
> Yes, but it does that at the cost of introducing the second local
> "01:30" which is "later" than the first "01:40" while "obviously" (and
> according to the current datetime rules) "01:30" < "01:40".

The current datetime rules, such as they are, as far as I am aware,
order all aware datetimes (except spring-forward) according to the UTC
moment they map to. I'm not sure what the benefit of changing this
invariant is.

>     Out of curiosity, can "fold" ever be any value other than 0 or 1?
>
> Thankfully, no.

What happens, then, if I were to define a timezone with three local
times from the same date? None may exist now, but the IANA data format
can certainly represent this case. Should we be talking about adding an
explicit offset member?  (Ultimately, this "fold=1 means the second one"
notion is a novel invention, and including the offset either explicitly
a la ISO8601, or implicitly by writing EST/EDT, is not)

>
>     > Yes, but are we willing to accept that datetimes have only
>     partial
>     > order?
>     
>     I apparently haven't been following the discussion closely enough
>     to
>     understand how this can possibly be the case outside cases I
>     assumed it
>     already was (naive vs aware comparisons being invalid).
>
> Local times that fall in the spring-forward gap cannot be ordered
> interzone even without PEP 495.

Hmm. If these have to be allowed to exist, then...

What about ordering times according to, notionally, a tuple of (UTC
timestamp of transition, number of "fake" seconds "after" the
transition) for a spring-forward time?

Also, can someone explain why this:
>>> ET = pytz.timezone("America/New_York")
>>> datetime.strftime(datetime.now(ET) + timedelta(days=90),
...                   "%Y%m%d %H%M%S %Z %z")
returns '20151210 214526 EDT -0400'

I don't know if I expected 214526 or 204526, but I certainly expected
the timezone info to say EST -0500. If EST and EDT are apparently two
distinct tzinfo values, then what exactly would a value landing near the
"fall back" transition have given for fold? fold=1 but EDT?

And if EST and EDT are, against all rationality, distinct tzinfo values,
then when exactly can fold ever actually be 1, and why is it needed?


From gvanrossum at gmail.com  Sat Sep 12 04:22:05 2015
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Fri, 11 Sep 2015 19:22:05 -0700
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <55F38533.2060603@g.nevcal.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <55F37BE5.6030709@g.nevcal.com>
 <CAP7h-xavk8uQ-9PCTWjDy+_hxFRAZm1MyeDBupCipn7MwF0OQg@mail.gmail.com>
 <55F38533.2060603@g.nevcal.com>
Message-ID: <CAP7+vJ+HiysjXoXodFFRHQk697qUJJxc0sm_YpTOf93N2DdfLA@mail.gmail.com>

I think we're getting into python-ideas territory here...

--Guido (on mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/e40e48d8/attachment.html>

From alexander.belopolsky at gmail.com  Sat Sep 12 04:34:59 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Sep 2015 22:34:59 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <55F38533.2060603@g.nevcal.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <55F37BE5.6030709@g.nevcal.com>
 <CAP7h-xavk8uQ-9PCTWjDy+_hxFRAZm1MyeDBupCipn7MwF0OQg@mail.gmail.com>
 <55F38533.2060603@g.nevcal.com>
Message-ID: <CAP7h-xb+9qO913iFMY91TVP=bLeOwqhVH2GCNqSSREBdv036hA@mail.gmail.com>

On Fri, Sep 11, 2015 at 9:51 PM, Glenn Linderman <v+python at g.nevcal.com>
wrote:

> It wasn't intended to argue for not defining the operations, just intended
> to justify that it is partial ordering...


It is not even that.  Note that even partial ordering still requires
transitivity of <=, but we don't have that in datetime:

>>> from datetime import *
>>> from datetimetester import Eastern
>>> UTC = timezone.utc
>>> a = datetime(2002, 4, 7, 1, 40, tzinfo=Eastern)
>>> b = datetime(2002, 4, 7, 2, tzinfo=Eastern)
>>> c = datetime(2002, 4, 7, 6, 20, tzinfo=UTC)
>>> a <= b <= c
True
>>> a <= c
False

The above session is run in the currently released python.  The Eastern
timezone implementation is imported from the CPython test suit.

The fact that transitivity of <= is already broken gives me little comfort
because pretty much everything involving "problem times" is currently
broken and users expect that.  PEP 495, however, is expected to fix the
issues with the problem times and not just replace one broken behavior with
another.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/1947d64b/attachment.html>

From alexander.belopolsky at gmail.com  Sat Sep 12 04:43:32 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Sep 2015 22:43:32 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <m24mj0iegx.fsf@fastmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <m2a8ssihfo.fsf@fastmail.com>
 <CAP7h-xaCYNRBYYByPzgBWYQsmrjxxK+65QXNyD4NF=3ooHjBrw@mail.gmail.com>
 <m24mj0iegx.fsf@fastmail.com>
Message-ID: <CAP7h-xY0KGe-xRNT7o9EbARHd8Nr4axPpEX6au2DR1o+25ZW4w@mail.gmail.com>

On Fri, Sep 11, 2015 at 10:00 PM, Random832 <random832 at fastmail.com> wrote:
>
> The current datetime rules, such as they are, as far as I am aware,
> order all aware datetimes (except spring-forward) according to the UTC
> moment they map to.


No.  See the library reference manual: "If both comparands are aware, and
have the same tzinfo attribute, the common tzinfo attribute is ignored and
the base datetimes are compared." <
https://docs.python.org/3/library/datetime.html>

The reasons for this have been explained at length in the recent
Datetime-SIG discussions.  Please check the archives if you are interested:
<https://mail.python.org/pipermail/datetime-sig/2015-August/000169.html>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/958348e8/attachment.html>

From alexander.belopolsky at gmail.com  Sat Sep 12 04:46:59 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Sep 2015 22:46:59 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <m24mj0iegx.fsf@fastmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <m2a8ssihfo.fsf@fastmail.com>
 <CAP7h-xaCYNRBYYByPzgBWYQsmrjxxK+65QXNyD4NF=3ooHjBrw@mail.gmail.com>
 <m24mj0iegx.fsf@fastmail.com>
Message-ID: <CAP7h-xYrKTUKhEe8odZ7d-=K5VaqydFzwkwX7tHpTtgBr_wPog@mail.gmail.com>

On Fri, Sep 11, 2015 at 10:00 PM, Random832 <random832 at fastmail.com> wrote:

> And if EST and EDT are, against all rationality, distinct tzinfo values,
> then when exactly can fold ever actually be 1, and why is it needed?
>

No, fold is not needed in the case of fixed offset timezones.  For an
obvious reason: there are no folds or gaps in those.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/32e8abae/attachment.html>

From alexander.belopolsky at gmail.com  Sat Sep 12 05:02:10 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Sep 2015 23:02:10 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <CAP7+vJ+HiysjXoXodFFRHQk697qUJJxc0sm_YpTOf93N2DdfLA@mail.gmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <55F37BE5.6030709@g.nevcal.com>
 <CAP7h-xavk8uQ-9PCTWjDy+_hxFRAZm1MyeDBupCipn7MwF0OQg@mail.gmail.com>
 <55F38533.2060603@g.nevcal.com>
 <CAP7+vJ+HiysjXoXodFFRHQk697qUJJxc0sm_YpTOf93N2DdfLA@mail.gmail.com>
Message-ID: <CAP7h-xYBCf=8=xB9nf6rrFspyLyzZaYb3cmxOjEOehG+rOhdgg@mail.gmail.com>

On Fri, Sep 11, 2015 at 10:22 PM, Guido van Rossum <gvanrossum at gmail.com>
wrote:

> I think we're getting into python-ideas territory here...


Well, a violation of transitivity of <= in the current CPython
implementation may be considered a bug by some.  This makes this discussion
appropriate for python-dev.  We could discuss this on Datetime-SIG, but I
think the question is more broad than just datetime.

When is it appropriate for Python operators to violate various mathematical
identities?  We know that some violations are unavoidable when you try to
represent real numbers in finite size objects, but when you effectively
deal with a subset of integers, what identities are important and what can
be ignored for practical reasons?

Intuitively, I feel that the hash invariant and the reflexivity and
transitivity of == are more important than say distribution law for + and
*, but where does it leave the transitivity of <=?  Is it as important as
== being an equivalence, or it's a nice to have like the distribution law?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/3acaf626/attachment.html>

From tim.peters at gmail.com  Sat Sep 12 05:03:14 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 11 Sep 2015 22:03:14 -0500
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <m24mj0iegx.fsf@fastmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <m2a8ssihfo.fsf@fastmail.com>
 <CAP7h-xaCYNRBYYByPzgBWYQsmrjxxK+65QXNyD4NF=3ooHjBrw@mail.gmail.com>
 <m24mj0iegx.fsf@fastmail.com>
Message-ID: <CAExdVNnRbQhK4hx2KsD6wdnrHtTqO54RB2Hn5q+KnyGh1375YA@mail.gmail.com>

[Random832 <random832 at fastmail.com>]
> ...
>
> Also, can someone explain why this:
> >>> ET = pytz.timezone("America/New_York")
> >>> datetime.strftime(datetime.now(ET) + timedelta(days=90),
> ...                   "%Y%m%d %H%M%S %Z %z")
> returns '20151210 214526 EDT -0400'

pytz lives in its own world here, and only uses eternally-fixed-offset
zones.  It's a magnificent hack to get around the lack of an "is_dst
bit" in datetime's design, and effectively records that bit via
_which_ fixed-offset zone it attaches to the datetime.

The tradeoff is that, to get results you expect, you _need_ to invoke
pytz's .normalize() after doing any arithmetic (and pytz's doc are
very clear about this - do read them).  That's required for pytz to
realize the tzinfo in the result is no longer appropriate for the
result's date and time, so it can (if needed) replace it with a
different fixed-offset tzinfo.


> I don't know if I expected 214526 or 204526, but I certainly expected
> the timezone info to say EST -0500. If EST and EDT are apparently two
> distinct tzinfo values,

In pytz, they are.  This isn't how tzinfos were _intended_ to work in
Python, but pytz does create an interesting set of tradeoffs.

> then what exactly would a value landing near the
> "fall back" transition have given for fold? fold=1 but EDT?

As above, pytz is in its own world here.  It doesn't need `fold`
because it has its own hack for disambiguating local times in a fold.


> And if EST and EDT are, against all rationality, distinct tzinfo values,
> then when exactly can fold ever actually be 1, and why is it needed?

pytz doesn't need it.  "Hybrid" tzinfos do, because there is currently
no way outside of pytz to disambiguate local times in a fold.

So, short course:  if you ask questions about pytz's behavior, you're
asking question about pytz, not  really about Python's datetime.

From python at mrabarnett.plus.com  Sat Sep 12 05:07:28 2015
From: python at mrabarnett.plus.com (MRAB)
Date: Sat, 12 Sep 2015 04:07:28 +0100
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <CAP7h-xaCYNRBYYByPzgBWYQsmrjxxK+65QXNyD4NF=3ooHjBrw@mail.gmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <m2a8ssihfo.fsf@fastmail.com>
 <CAP7h-xaCYNRBYYByPzgBWYQsmrjxxK+65QXNyD4NF=3ooHjBrw@mail.gmail.com>
Message-ID: <55F396F0.3070109@mrabarnett.plus.com>

On 2015-09-12 02:23, Alexander Belopolsky wrote:
>
> On Fri, Sep 11, 2015 at 8:56 PM, Random832 <random832 at fastmail.com
> <mailto:random832 at fastmail.com>> wrote:
>
>     Alexander Belopolsky <alexander.belopolsky at gmail.com
>     <mailto:alexander.belopolsky at gmail.com>> writes:
>     > There is no "earlier" or "later". There are "lesser" and "greater"
>     > which are already defined for all pairs of aware datetimes. PEP 495
>     > doubles the set of possible datetimes
>
>     That depends on what you mean by "possible".
>
> What exactly depends on the meaning of  "possible"?  In this context
> "possible" means "can appear in a Python program."
>
>     > and they don't fit in one
>     > straight line anymore. The whole point of PEP 495 is to introduce a
>     > "fold" in the timeline.
>
>     That doesn't make sense. Within a given timezone, any given moment of
>     UTC time (which is a straight line [shut up, no leap seconds here]) maps
>     to only one local time. The point of PEP 495 seems to be to eliminate
>     the cases where two UTC moments map to the same aware local time.
>
> Yes, but it does that at the cost of introducing the second local
> "01:30" which is "later" than the first "01:40" while "obviously" (and
> according to the current datetime rules)  "01:30" < "01:40".
>
>     Out of curiosity, can "fold" ever be any value other than 0 or 1?
>
> Thankfully, no.
>
[snip]
What would happen if it's decided to stay on DST and then, later on, to
reintroduce DST?

Or what would happen in the case of "British Double Summer Time" (go
forward twice in the spring and backward twice in the autumn)?

https://en.wikipedia.org/wiki/British_Summer_Time


From alexander.belopolsky at gmail.com  Sat Sep 12 05:11:17 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Sep 2015 23:11:17 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <CAExdVNnRbQhK4hx2KsD6wdnrHtTqO54RB2Hn5q+KnyGh1375YA@mail.gmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <m2a8ssihfo.fsf@fastmail.com>
 <CAP7h-xaCYNRBYYByPzgBWYQsmrjxxK+65QXNyD4NF=3ooHjBrw@mail.gmail.com>
 <m24mj0iegx.fsf@fastmail.com>
 <CAExdVNnRbQhK4hx2KsD6wdnrHtTqO54RB2Hn5q+KnyGh1375YA@mail.gmail.com>
Message-ID: <CAP7h-xZBQQ=U=3juV8m=ekgsw4BEpgZSnp+pZEWVQ5gJzA9c-A@mail.gmail.com>

On Fri, Sep 11, 2015 at 11:03 PM, Tim Peters <tim.peters at gmail.com> wrote:

> > then what exactly would a value landing near the
> > "fall back" transition have given for fold? fold=1 but EDT?
>
> As above, pytz is in its own world here.  It doesn't need `fold`
> because it has its own hack for disambiguating local times in a fold.


But I consider it as an imperative that pytz's hack continues to work in
the post-PEP 495 world.  Fortunately, this is not a hard requirement to
satisfy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/1fef0cf9/attachment.html>

From alexander.belopolsky at gmail.com  Sat Sep 12 05:17:00 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Sep 2015 23:17:00 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <55F396F0.3070109@mrabarnett.plus.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <m2a8ssihfo.fsf@fastmail.com>
 <CAP7h-xaCYNRBYYByPzgBWYQsmrjxxK+65QXNyD4NF=3ooHjBrw@mail.gmail.com>
 <55F396F0.3070109@mrabarnett.plus.com>
Message-ID: <CAP7h-xbbgmb69nOsp_Q7abL_p=rtbmNiocyFtpfo9XuxT8MaOQ@mail.gmail.com>

On Fri, Sep 11, 2015 at 11:07 PM, MRAB <python at mrabarnett.plus.com> wrote:

> What would happen if it's decided to stay on DST and then, later on, to
> reintroduce DST?
>

No problem as long as you don't move the clock back x minutes and then
decide that you did not move it back enough and move it again before x
minutes have passed.  Fortunately, no government in the world can pass a
new law in an hour.  More so in an hour between 01:00 and 02:00 AM. :-)

An interesting possibility is a fold straddling a leap second, but
hopefully those who pass the timekeeping laws have learned about the leap
seconds by now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/1e462414/attachment.html>

From random832 at fastmail.com  Sat Sep 12 05:52:29 2015
From: random832 at fastmail.com (Random832)
Date: Fri, 11 Sep 2015 23:52:29 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
	is ready for pronouncement
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <m2a8ssihfo.fsf@fastmail.com>
 <CAP7h-xaCYNRBYYByPzgBWYQsmrjxxK+65QXNyD4NF=3ooHjBrw@mail.gmail.com>
 <55F396F0.3070109@mrabarnett.plus.com>
Message-ID: <m24mj0thtu.fsf@fastmail.com>

MRAB <python at mrabarnett.plus.com> writes:
> What would happen if it's decided to stay on DST and then, later on, to
> reintroduce DST?
>
> Or what would happen in the case of "British Double Summer Time" (go
> forward twice in the spring and backward twice in the autumn)?
>
> https://en.wikipedia.org/wiki/British_Summer_Time

"backward twice" could theoretically do it, if you literally went back
an hour, waited an hour (or any nonzero amount less than two hours), and
went back an hour again, rather than just going back two hours. I don't
know if any real-life authorities have ever done such a thing; that's
why I asked.

You could also have them if you had a "timezone" representing the
real-time local time of someone who traveled across timezone boundaries
multiple times in close succession, rather than the time of a
geographical place.


From tjreedy at udel.edu  Sat Sep 12 07:20:24 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Sep 2015 01:20:24 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
Message-ID: <mt0cnj$b5$1@ger.gmane.org>

On 9/11/2015 8:40 PM, Alexander Belopolsky wrote:

> The insanity I am dealing with now is specific to Python datetime which
> wisely blocks any binary operation that involves naive and aware
> datetimes, but allows comparisons and subtractions of datetimes with
> different timezones.  This is not an unusual situation given a limited
> supply of binary operators, Python has to reuse them in less than ideal
> ways. For example,
>
>  >>> a = 'a'
>  >>> b = 'b'
>  >>> c = 5
>  >>> (a + b) * c == a * c + b * c
> False
>
> is less than ideal if you hold the distributive law of arithmetic
> sacred.

In mathematics, algebra is, put simply, the study of binary operations. 
None of the laws for particular operations on particular sets is 
'sacred'.  They are simply facts. Or possibly axioms whose consequences 
are to be explored.  A mathematician has no problem with 'a'+'b' != 
'b'+'a'.  After closure, associativity is the most 'basic' operation, 
but non-associative operations are studied.

The equality relation, mapping pairs of members of a set to True or 
False is a different matter.  Being an equivalence relation is 
fundamental to both normal logic, algebraic proofs, and the definition 
of sets.  It is also required for the 'proper' operation of Python's 
sets. (Lets leave nans out of the discussion).

>  Similarly, '-' is reused in datetime for two different
> operation: if s and t are datetimes with the same tzinfo, s - t tells
> you how far to move hands on the local clock to arrive at s when you
> start at t.  This is clearly a very useful operation that forms the
> basis of everything else that we do in datetime.  Note that for this
> operation, it does not matter what kind of time your clock is showing or
> whether it is running at all.  We are not asking how long one needs to
> wait to see s after t was shown.  We are just asking how far to turn the
> knob on the back of the clock.  This operation does not make sense when
> s and t have different tzinfos, so in this case a '-' is reused for a
> different operation.  This operation is much more involved.  We require
> an existence of some universal time (UTC) and a rule to convert s and t
> to that time and define s - t as s.astimezone(UTC) - t.timezone(UTC).
> In the later expression '-' is taken in the "turns of the knob" sense
> because the operands are in the same timezone (UTC).

Datetime members, are rather unusual beasts. They are triples consisting 
of a member of a discrete sequence (with some odd gaps), a tz tag, and a 
0/1 fold tag. The tz tags divide datetimes into equivalence classes. 
The '-' operation is also unusual in being defined differently for pairs 
in the same or different equivalence classes.

> Clearly, when we "abuse" the mathematical notation in this way,

Mathematicians wildly overload operater/relation symbols. '=' is the 
only one I can think of with more-or-less universal properties.

> we cannot expect mathematical identities

which are context dependent

> to hold

in a different context.  Right.

> and it is easy to find for
> example, aware datetimes u, t, and s such that (t - u) - (s - u) ? t - s.

Datetime '-' (subtraction) should be documented as an unusual overloaded 
use which does not have the normal properties that the naive might expect.

Within the constraint on '=', there are two choices for designing an 
operation.
1. Define the operation the way you want, and live with the consequent 
properties (or absence of properties).
2. Decide the properties you require, and live with the consequent 
restriction on the definition.

-- 
Terry Jan Reedy



From storchaka at gmail.com  Sat Sep 12 07:48:20 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 12 Sep 2015 08:48:20 +0300
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
Message-ID: <mt0eb5$il5$1@ger.gmane.org>

On 08.09.15 19:59, Brett Cannon wrote:
> The approaches to module deprecation I have seen are:
> 1. Nothing changes to the deprecation process; you deprecate a module
> and remove it in one to two releases
> 2. Deprecate the module but with no plans for removal until Python 2.7
> reaches its EOL (I have been calling this Python 4)
> 3. Document the deprecation but no actual code deprecation

Of course #2 LGTM. What if at the same time add Py3k warning in next 2.7 
bugfix release?



From phd at phdru.name  Sat Sep 12 15:56:41 2015
From: phd at phdru.name (Oleg Broytman)
Date: Sat, 12 Sep 2015 15:56:41 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150912135451.GA13004@phdru.name>
References: <20150912135451.GA13004@phdru.name>
Message-ID: <20150912135641.GB13004@phdru.name>

On Sat, Sep 12, 2015 at 03:54:51PM +0200, Oleg Broytman <phd at phdru.name> wrote:
> PEP: XXX
> Title: Collecting information about git

   HTMLized version: http://phdru.name/Software/Python/PEPs/pep-git.html
   git repo: http://git.phdru.name/?p=pep-git.git;a=summary

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From phd at phdru.name  Sat Sep 12 15:54:51 2015
From: phd at phdru.name (Oleg Broytman)
Date: Sat, 12 Sep 2015 15:54:51 +0200
Subject: [Python-Dev] PEP: Collecting information about git
Message-ID: <20150912135451.GA13004@phdru.name>

PEP: XXX
Title: Collecting information about git
Version: $Revision$
Last-Modified: $Date$
Author: Oleg Broytman <phd at phdru.name>
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 01-Jun-2015
Post-History: 12-Sep-2015

Abstract
========

This Informational PEP collects information about git. There is, of
course, a lot of documentation for git, so the PEP concentrates on
more complex (and more related to Python development) issues,
scenarios and examples.

The plan is to extend the PEP in the future collecting information
about equivalence of Mercurial and git scenarios to help migrating
Python development from Mercurial to git.

The author of the PEP doesn't currently plan to write a Process PEP on
migration Python development from Mercurial to git.


Documentation
=============

Git is accompanied with a lot of documentation, both online and
offline.


Documentation for starters
--------------------------

Git Tutorial: `part 1
<https://www.kernel.org/pub/software/scm/git/docs/gittutorial.html>`_,
`part 2
<https://www.kernel.org/pub/software/scm/git/docs/gittutorial-2.html>`_.

`Git User's manual
<https://www.kernel.org/pub/software/scm/git/docs/user-manual.html>`_.
`Everyday GIT With 20 Commands Or So
<https://www.kernel.org/pub/software/scm/git/docs/everyday.html>`_.
`Git workflows
<https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html>`_.


Advanced documentation
----------------------

`Git Magic
<http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html>`_,
with a number of translations.

`Pro Git <https://git-scm.com/book>`_. The Book about git. Buy it at
Amazon or download in PDF, mobi, or ePub form. It has translations to
many different languages. Download Russian translation from `GArik
<https://github.com/GArik/progit/wiki>`_.

`Git Wiki <https://git.wiki.kernel.org/index.php/Main_Page>`_.


Offline documentation
---------------------

Git has builtin help: run ``git help $TOPIC``. For example, run
``git help git`` or ``git help help``.


Quick start
===========

Download and installation
-------------------------

Unix users: `download and install using your package manager
<https://git-scm.com/download/linux>`_.

Microsoft Windows: download `git-for-windows
<https://github.com/git-for-windows/git/releases>`_ or `msysGit
<https://github.com/msysgit/msysgit/releases>`_.

MacOS X: use git installed with `XCode
<https://developer.apple.com/xcode/downloads/>`_ or download from
`MacPorts <https://www.macports.org/ports.php?by=name&substr=git>`_ or
`git-osx-installer
<http://sourceforge.net/projects/git-osx-installer/files/>`_ or
install git with `Homebrew <http://brew.sh/>`_: ``brew install git``.

`git-cola <https://git-cola.github.io/index.html>`_ is a Git GUI
written in Python and GPL licensed. Linux, Windows, MacOS X.

`TortoiseGit <https://tortoisegit.org/>`_ is a Windows Shell Interface
to Git based on TortoiseSVN; open source.


Initial configuration
---------------------

This simple code is often appears in documentation, but it is
important so let repeat it here. Git stores author and committer
names/emails in every commit, so configure your real name and
preferred email::

    $ git config --global user.name "User Name"
    $ git config --global user.email user.name at example.org


Examples in this PEP
====================

Examples of git commands in this PEP use the following approach. It is
supposed that you, the user, works with a local repository named
``python`` that has an upstream remote repo named ``origin``. Your
local repo has two branches ``v1`` and ``master``. For most examples
the currently checked out branch is ``master``. That is, it's assumed
you have done something like that::

    $ git clone https://git.python.org/python.git
    $ cd python
    $ git branch v1 origin/v1

The first command clones remote repository into local directory
`python``, creates a new local branch master, sets
remotes/origin/master as its upstream remote-tracking branch and
checks it out into the working directory.

The last command creates a new local branch v1 and sets
remotes/origin/v1 as its upstream remote-tracking branch.

The same result can be achieved with commands::

    $ git clone -b v1 https://git.python.org/python.git
    $ cd python
    $ git checkout --track origin/master

The last command creates a new local branch master, sets
remotes/origin/master as its upstream remote-tracking branch and
checks it out into the working directory.


Branches and branches
=====================

Git terminology can be a bit misleading. Take, for example, the term
"branch". In git it has two meanings. A branch is a directed line of
commits (possibly with merges). And a branch is a label or a pointer
assigned to a line of commits. It is important to distinguish when you
talk about commits and when about their labels. Lines of commits are
by itself unnamed and are usually only lengthening and merging.
Labels, on the other hand, can be created, moved, renamed and deleted
freely.


Remote repositories and remote branches
=======================================

Remote-tracking branches are branches (pointers to commits) in your
local repository. They are there for git (and for you) to remember
what branches and commits have been pulled from and pushed to what
remote repos (you can pull from and push to many remotes).
Remote-tracking branches live under ``remotes/$REMOTE`` namespaces,
e.g. ``remotes/origin/master``.

To see the status of remote-tracking branches run::

    $ git branch -rv

To see local and remote-tracking branches (and tags) pointing to
commits::

    $ git log --decorate

You never do your own development on remote-tracking branches. You
create a local branch that has a remote branch as upstream and do
development on that local branch. On push git pushes commits to the
remote repo and updates remote-tracking branches, on pull git fetches
commits from the remote repo, updates remote-tracking branches and
fast-forwards, merges or rebases local branches.

When you do an initial clone like this::

    $ git clone -b v1 https://git.python.org/python.git

git clones remote repository ``https://git.python.org/python.git`` to
directory ``python``, creates a remote named ``origin``, creates
remote-tracking branches, creates a local branch ``v1``, configure it
to track upstream remotes/origin/v1 branch and checks out ``v1`` into
the working directory.


Updating local and remote-tracking branches
-------------------------------------------

There is a major difference between

::

    $ git fetch $REMOTE $BRANCH

and

::

    $ git fetch $REMOTE $BRANCH:$BRANCH

The first command fetches commits from the named $BRANCH in the
$REMOTE repository that are not in your repository, updates
remote-tracking branch and leaves the id (the hash) of the head commit
in file .git/FETCH_HEAD.

The second command fetches commits from the named $BRANCH in the
$REMOTE repository that are not in your repository and updates both
the local branch $BRANCH and its upstream remote-tracking branch. But
it refuses to update branches in case of non-fast-forward. And it
refuses to update the current branch (currently checked out branch,
where HEAD is pointing to).

The first command is used internally by ``git pull``.

::

    $ git pull $REMOTE $BRANCH

is equivalent to

::

    $ git fetch $REMOTE $BRANCH
    $ git merge FETCH_HEAD

Certainly, $BRANCH in that case should be your current branch. If you
want to merge a different branch into your current branch first update
that non-current branch and then merge::

    $ git fetch origin v1:v1  # Update v1
    $ git pull --rebase origin master  # Update the current branch master
                                       # using rebase instead of merge
    $ git merge v1

If you have not yet pushed commits on ``v1``, though, the scenario has
to become a bit more complex. Git refuses to update
non-fast-forwardable branch, and you don't want to do force-pull
because that would remove your non-pushed commits and you would need
to recover. So you want to rebase ``v1`` but you cannot rebase
non-current branch. Hence, checkout ``v1`` and rebase it before
merging::

    $ git checkout v1
    $ git pull --rebase origin v1
    $ git checkout master
    $ git pull --rebase origin master
    $ git merge v1

It is possible to configure git to make it fetch/pull a few branches
or all branches at once, so you can simply run

::

    $ git pull origin

or even

::

    $ git pull

Default remote repository for fetching/pulling is ``origin``. Default
set of references to fetch is calculated using matching algorithm: git
fetches all branches having the same name on both ends.


Push
''''

Pushing is a bit simpler. There is only one command ``push``. When you
run

::

    $ git push origin v1 master

git pushes local v1 to remote v1 and local master to remote master.
The same as::

    $ git push origin v1:v1 master:master

Git pushes commits to the remote repo and updates remote-tracking
branches. Git refuses to push commits that aren't fast-forwardable.
You can force-push anyway, but please remember - you can force-push to
your own repositories but don't force-push to public or shared repos.
If you find git refuses to push commits that aren't fast-forwardable,
better fetch and merge commits from the remote repo (or rebase your
commits on top of the fetched commits), then push. Only force-push if
you know what you do and why you do it. See the section `Commit
editing and caveats`_ below.

It is possible to configure git to make it push a few branches or all
branches at once, so you can simply run

::

    $ git push origin

or even

::

    $ git push

Default remote repository for pushing is ``origin``. Default set of
references to push in git before 2.0 is calculated using matching
algorithm: git pushes all branches having the same name on both ends.
Default set of references to push in git 2.0+ is calculated using
simple algorithm: git pushes the current branch back to its
@{upstream}.

To configure git before 2.0 to the new behaviour run::

$ git config push.default simple

To configure git 2.0+ to the old behaviour run::

$ git config push.default matching

Git doesn't allow to push a branch if it's the current branch in the
remote non-bare repository: git refuses to update remote working
directory. You really should push only to bare repositories. For
non-bare repositories git prefers pull-based workflow.

When you want to deploy code on a remote host and can only use push
(because your workstation is behind a firewall and you cannot pull
from it) you do that in two steps using two repositories: you push
from the workstation to a bare repo on the remote host, ssh to the
remote host and pull from the bare repo to a non-bare deployment repo.

That changed in git 2.3, but see `the blog post
<https://github.com/blog/1957-git-2-3-has-been-released#push-to-deploy>`_
for caveats; in 2.4 the push-to-deploy feature was `further improved
<https://github.com/blog/1994-git-2-4-atomic-pushes-push-to-deploy-and-more#push-to-deploy-improvements>`_.


Tags
''''

Git automatically fetches tags that point to commits being fetched
during fetch/pull. To fetch all tags (and commits they point to) run
``git fetch --tags origin``. To fetch some specific tags fetch them
explicitly::

    $ git fetch origin tag $TAG1 tag $TAG2...

For example::

    $ git fetch origin tag 1.4.2
    $ git fetch origin v1:v1 tag 2.1.7

Git doesn't automatically pushes tags. That allows you to have private
tags. To push tags list them explicitly::

    $ git push origin tag 1.4.2
    $ git push origin v1 master tag 2.1.7

Or push all tags at once::

    $ git push --tags origin

Don't move tags with ``git tag -f`` or remove tags with ``git tag -d``
after they have been published.


Private information
'''''''''''''''''''

When cloning/fetching/pulling/pushing git copies only database objects
(commits, trees, files and tags) and symbolic references (branches and
lightweight tags). Everything else is private to the repository and
never cloned, updated or pushed. It's your config, your hooks, your
private exclude file.

If you want to distribute hooks, copy them to the working tree, add,
commit, push and instruct the team to update and install the hooks
manually.


Commit editing and caveats
==========================

A warning not to edit published (pushed) commits also appears in
documentation but it's repeated here anyway as it's very important.

It is possible to recover from a forced push but it's PITA for the
entire team. Please avoid it.

To see what commits have not been published yet compare the head of the
branch with its upstream remote-tracking branch::

    $ git log origin/master..  # from origin/master to HEAD (of master)
    $ git log origin/v1..v1  # from origin/v1 to the head of v1

For every branch that has an upstream remote-tracking branch git
maintains an alias @{upstream} (short version @{u}), so the commands
above can be given as::

    $ git log @{u}..
    $ git log v1@{u}..v1

To see the status of all branches::

    $ git branch -avv

To compare the status of local branches with a remote repo::

    $ git remote show origin

Read `how to recover from upstream rebase
<https://git-scm.com/docs/git-rebase#_recovering_from_upstream_rebase>`_.
It is in ``git help rebase``.

On the other hand don't be too afraid about commit editing. You can
safely edit, reorder, remove, combine and split commits that haven't
been pushed yet. You can even push commits to your own (backup) repo,
edit them later and force-push edited commits to replace what have
already been pushed. Not a problem until commits are in a public
or shared repository.


Undo
====

Whatever you do, don't panic. Almost anything in git can be undone.


git checkout: restore file's content
------------------------------------

``git checkout``, for example, can be used to restore the content of
file(s) to that one of a commit. Like this::

    git checkout HEAD~ README

The commands restores the contents of README file to the last but one
commit in the current branch. By default the commit ID is simply HEAD;
i.e. ``git checkout README`` restores README to the latest commit.

(Do not use ``git checkout`` to view a content of a file in a commit,
use ``git cat-file -p``; e.g. ``git cat-file -p HEAD~:path/to/README``).


git reset: remove (non-pushed) commits
--------------------------------------

``git reset`` moves the head of the current branch. The head can be
moved to point to any commit but it's often used to remove a commit or
a few (preferably, non-pushed ones) from the top of the branch - that
is, to move the branch backward in order to undo a few (non-pushed)
commits.

``git reset`` has three modes of operation - soft, hard and mixed.
Default is mixed. ProGit `explains
<https://git-scm.com/book/en/Git-Tools-Reset-Demystified>`_ the
difference very clearly. Bare repositories don't have indices or
working trees so in a bare repo only soft reset is possible.


Unstaging
'''''''''

Mixed mode reset with a path or paths can be used to unstage changes -
that is, to remove from index changes added with ``git add`` for
committing. See `The Book
<https://git-scm.com/book/en/Git-Basics-Undoing-Things>`_ for details
about unstaging and other undo tricks.


git reflog: reference log
-------------------------

Removing commits with ``git reset`` or moving the head of a branch
sounds dangerous and it is. But there is a way to undo: another
reset back to the original commit. Git doesn't remove commits
immediately; unreferenced commits (in git terminology they are called
"dangling commits") stay in the database for some time (default is two
weeks) so you can reset back to it or create a new branch pointing to
the original commit.

For every move of a branch's head - with ``git commit``, ``git
checkout``, ``git fetch``, ``git pull``, ``git rebase``, ``git reset``
and so on - git stores a reference log (reflog for short). For every
move git stores where the head was. Command ``git reflog`` can be used
to view (and manipulate) the log.

In addition to the moves of the head of every branch git stores the
moves of the HEAD - a symbolic reference that (usually) names the
current branch. HEAD is changed with ``git checkout $BRANCH``.

By default ``git reflog`` shows the moves of the HEAD, i.e. the
command is equivalent to ``git reflog HEAD``. To show the moves of the
head of a branch use the command ``git reflog $BRANCH``.

So to undo a ``git reset`` lookup the original commit in ``git
reflog``, verify it with ``git show`` or ``git log`` and run ``git
reset $COMMIT_ID``. Git stores the move of the branch's head in
reflog, so you can undo that undo later again.

In a more complex situation you'd want to move some commits along with
resetting the head of the branch. Cherry-pick them to the new branch.
For example, if you want to reset the branch ``master`` back to the
original commit but preserve two commits created in the current branch
do something like::

    $ git branch save-master # create a new branch saving master
    $ git reflog # find the original place of master
    $ git reset $COMMIT_ID
    $ git cherry-pick save-master~ save-master
    $ git branch -D save-master # remove temporary branch


git revert: revert a commit
---------------------------

``git revert`` reverts a commit or commits, that is, it creates a new
commit or commits that revert(s) the effects of the given commits.
It's the only way to undo published commits (``git commit --amend``,
``git rebase`` and ``git reset`` change the branch in
non-fast-forwardable ways so they should only be used for non-pushed
commits.)

There is a problem with reverting a merge commit. ``git revert`` can
undo the code created by the merge commit but it cannot undo the fact
of merge. See the discussion `How to revert a faulty merge
<https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html>`_.


One thing that cannot be undone
-------------------------------

Whatever you undo, there is one thing that cannot be undone -
overwritten uncommitted changes. Uncommitted changes don't belong to
git so git cannot help preserving them.

Most of the time git warns you when you're going to execute a command
that overwrites uncommitted changes. Git doesn't allow you to switch
branches with ``git checkout``. It stops you when you're going to
rebase with non-clean working tree. It refuses to pull new commits
over non-committed files.

But there are commands that do exactly that - overwrite files in the
working tree. Commands like ``git checkout $PATHs`` or ``git reset
--hard`` silently overwrite files including your uncommitted changes.

With that in mind you can understand the stance "commit early, commit
often". Commit as often as possible. Commit on every save in your
editor or IDE. You can edit your commits before pushing - edit commit
messages, change commits, reorder, combine, split, remove. But save
your changes in git database, either commit changes or at least stash
them with ``git stash``.


Merge or rebase?
================

Internet is full of heated discussions on the topic: "merge or
rebase?" Most of them are meaningless. When a DVCS is being used in a
big team with a big and complex project with many branches there is
simply no way to avoid merges. So the question's diminished to
"whether to use rebase, and if yes - when to use rebase?" Considering
that it is very much recommended not to rebase published commits the
question's diminished even further: "whether to use rebase on
non-pushed commits?"

That small question is for the team to decide. The author of the PEP
recommends to use rebase when pulling, i.e. always do ``git pull
--rebase`` or even configure automatic setup of rebase for every new
branch::

    $ git config branch.autosetuprebase always

and configure rebase for existing branches::

    $ git config branch.$NAME.rebase true

For example::

    $ git config branch.v1.rebase true
    $ git config branch.master.rebase true

After that ``git pull origin master`` becomes equivalent to ``git pull
--rebase origin master``.

It is recommended to create new commits in a separate feature or topic
branch while using rebase to update the mainline branch. When the
topic branch is ready merge it into mainline. To avoid a tedious task
of resolving large number of conflicts at once you can merge the topic
branch to the mainline from time to time and switch back to the topic
branch to continue working on it. The entire workflow would be
something like::

    $ git checkout -b issue-42  # create a new issue branch and switch to it
        ...edit/test/commit...
    $ git checkout master
    $ git pull --rebase origin master  # update master from the upstream
    $ git merge issue-42
    $ git branch -d issue-42  # delete the topic branch
    $ git push origin master

When the topic branch is deleted only the label is removed, commits
are stayed in the database, they are now merged into master::

    o--o--o--o--o--M--< master - the mainline branch
        \         /
         --*--*--*             - the topic branch, now unnamed

The topic branch is deleted to avoid cluttering branch namespace with
small topic branches. Information on what issue was fixed or what
feature was implemented should be in the commit messages.


Null-merges
===========

Git has a builtin merge strategy for what Python core developers call
"null-merge"::

    $ git merge -s ours v1  # null-merge v1 into master


Advanced configuration
======================

Line endings
------------

Git has builtin mechanisms to handle line endings between platforms
with different end-of-line styles. To allow git to do CRLF conversion
assign ``text`` attribute to files using `.gitattributes
<https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html>`_.
For files that have to have specific line endings assign ``eol``
attribute. For binary files the attribute is, naturally, ``binary``.

For example::

    $ cat .gitattributes
    *.py text
    *.txt text
    *.png binary
    /readme.txt eol=CRLF

To check what attributes git uses for files use ``git check-attr``
command. For example::

$ git check-attr -a -- \*.py


Advanced topics
===============

Staging area
------------

Staging area aka index aka cache is a distinguishing feature of git.
Staging area is where git collects patches before committing them.
Separation between collecting patches and commit phases provides a
very useful feature of git: you can review collected patches before
commit and even edit them - remove some hunks, add new hunks and
review again.

To add files to the index use ``git add``. Collecting patches before
committing means you need to do that for every change, not only to add
new (untracked) files. To simplify committing in case you just want to
commit everything without reviewing run ``git commit --all`` (or just
``-a``) - the command adds every changed tracked file to the index and
then commit. To commit a file or files regardless of patches collected
in the index run ``git commit [--only|-o] -- $FILE...``.

To add hunks of patches to the index use ``git add --patch`` (or just
``-p``). To remove collected files from the index use ``git reset HEAD
-- $FILE...`` To add/inspect/remove collected hunks use ``git add
--interactive`` (``-i``).

To see the diff between the index and the last commit (i.e., collected
patches) use ``git diff --cached``. To see the diff between the
working tree and the index (i.e., uncollected patches) use just ``git
diff``. To see the diff between the working tree and the last commit
(i.e., both collected and uncollected patches) run ``git diff HEAD``.

See `WhatIsTheIndex
<https://git.wiki.kernel.org/index.php/WhatIsTheIndex>`_ and
`IndexCommandQuickref
<https://git.wiki.kernel.org/index.php/IndexCommandQuickref>`_ in Git
Wiki.


ReReRe
======

Rerere is a mechanism that helps to resolve repeated merge conflicts.
The most frequent source of recurring merge conflicts are topic
branches that are merged into mainline and then the merge commits are
removed; that's often performed to test the topic branches and train
rerere; merge commits are removed to have clean linear history and
finish the topic branch with only one last merge commit.

Rerere works by remembering the states of tree before and after a
successful commit. That way rerere can automatically resolve conflicts
if they appear in the same files.

Rerere can be used manually with ``git rerere`` command but most often
it's used automatically. Enable rerere with these commands in a
working tree::

    $ git config rerere.enabled true
    $ git config rerere.autoupdate true

You don't need to turn rerere on globally - you don't want rerere in
bare repositories or single-branche repositories; you only need rerere
in repos where you often perform merges and resolve merge conflicts.

See `Rerere <https://git-scm.com/book/en/Git-Tools-Rerere>`_ in The
Book.


Database maintenance
====================

Git object database and other files/directories under ``.git`` require
periodic maintenance and cleanup. For example, commit editing left
unreferenced objects (dangling objects, in git terminology) and these
objects should be pruned to avoid collecting cruft in the DB. The
command ``git gc`` is used for maintenance. Git automatically runs
``git gc --auto`` as a part of some commands to do quick maintenance.
Users are recommended to run ``git gc --aggressive`` from time to
time; ``git help gc`` recommends to run it  every few hundred
changesets; for more intensive projects it should be something like
once a week and less frequently (biweekly or monthly) for lesser
active projects.

``git gc --aggressive`` not only removes dangling objects, it also
repacks object database into indexed and better optimized pack(s); it
also packs symbolic references (branches and tags). Another way to do
it is to run ``git repack``.

There is a well-known `message
<https://gcc.gnu.org/ml/gcc/2007-12/msg00165.html>`_ from Linus
Torvalds regarding "stupidity" of ``git gc --aggressive``. The message
can safely be ignored now. It is old and outdated, ``git gc
--aggressive`` became much better since that time.

For those who still prefer ``git repack`` over ``git gc --aggressive``
the recommended parameters are ``git repack -a -d -f --depth=20
--window=250``. See `this detailed experiment
<http://vcscompare.blogspot.ru/2008/06/git-repack-parameters.html>`_
for explanation of the effects of these parameters.

>From time to time run ``git fsck [--strict]`` to verify integrity of
the database. ``git fsck`` may produce a list of dangling objects;
that's not an error, just a reminder to perform regular maintenance.


Tips and tricks
===============

Command-line options and arguments
----------------------------------

`git help cli
<https://www.kernel.org/pub/software/scm/git/docs/gitcli.html>`_
recommends not to combine short options/flags. Most of the times
combining works: ``git commit -av`` works perfectly, but there are
situations when it doesn't. E.g., ``git log -p -5`` cannot be combined
as ``git log -p5``.

Some options have arguments, some even have default arguments. In that
case the argument for such option must be spelled in a sticky way:
``-Oarg``, never ``-O arg`` because for an option that has a default
argument the latter means "use default value for option ``-O`` and
pass ``arg`` further to the option parser". For example, ``git grep``
has an option ``-O`` that passes a list of names of the found files to
a program; default program for ``-O`` is a pager (usually ``less``),
but you can use your editor::

    $ git grep -Ovim # but not -O vim

BTW, if git is instructed to use ``less`` as the pager (i.e., if pager
is not configured in git at all it uses ``less`` by default, or if it
gets ``less`` from GIT_PAGER or PAGER environment variables, or if it
was configured with ``git config --global core.pager less``, or
``less`` is used in the command ``git grep -Oless``) ``git grep``
passes ``+/$pattern`` option to ``less`` which is quite convenient.
Unfortunately, ``git grep`` doesn't pass the pattern if the pager is
not exactly ``less``, even if it's ``less`` with parameters (something
like ``git config --global core.pager less -FRSXgimq``); fortunately,
``git grep -Oless`` always passes the pattern.


bash/zsh completion
-------------------

It's a bit hard to type ``git rebase --interactive --preserve-merges
HEAD~5`` manually even for those who are happy to use command-line,
and this is where shell completion is of great help. Bash/zsh come
with programmable completion, often automatically installed and
enabled, so if you have bash/zsh and git installed, chances are you
are already done - just go and use it at the command-line.

If you don't have necessary bits installed, install and enable
bash_completion package. If you want to upgrade your git completion to
the latest and greatest download necessary file from `git contrib
<https://git.kernel.org/cgit/git/git.git/tree/contrib/completion>`_.

Git-for-windows comes with git-bash for which bash completion is
installed and enabled.


bash/zsh prompt
---------------

For command-line lovers shell prompt can carry a lot of useful
information. To include git information in the prompt use
`git-prompt.sh
<https://git.kernel.org/cgit/git/git.git/tree/contrib/completion/git-prompt.sh>`_.
Read the detailed instructions in the file.

Search the Net for "git prompt" to find other prompt variants.


git on server
=============

The simplest way to publish a repository or a group of repositories is
``git daemon``. The daemon provides anonymous access, by default it is
read-only. The repositories are accessible by git protocol (git://
URLs). Write access can be enabled but the protocol lacks any
authentication means, so it should be enabled only within a trusted
LAN. See ``git help daemon`` for details.

Git over ssh provides authentication and repo-level authorisation as
repositories can be made user- or group-writeable (see parameter
``core.sharedRepository`` in ``git help config``). If that's too
permissive or too restrictive for some project's needs there is a
wrapper `gitolite <http://gitolite.com/gitolite/index.html>`_ that can
be configured to allow access with great granularity; gitolite is
written in Perl and has a lot of documentation.

Web interface to browse repositories can be created using `gitweb
<https://git.kernel.org/cgit/git/git.git/tree/gitweb>`_ or `cgit
<http://git.zx2c4.com/cgit/about/>`_. Both are CGI scripts (written in
Perl and C). In addition to web interface both provide read-only dumb
http access for git (http(s):// URLs).

There are also more advanced web-based development environments that
include ability to manage users, groups and projects; private,
group-accessible and public repositories; they often include issue
trackers, wiki pages, pull requests and other tools for development
and communication. Among these environments are `Kallithea
<https://kallithea-scm.org/>`_ and `pagure <https://pagure.io/>`_,
both are written in Python; pagure was written by Fedora developers
and is being used to develop some Fedora projects. `Gogs
<http://gogs.io/>`_ is written in Go; there is a fork `Gitea
<http://gitea.io/>`_.

And last but not least, `Gitlab <https://about.gitlab.com/>`_. It's
perhaps the most advanced web-based development environment for git.
Written in Ruby, community edition is free and open source (MIT
license).


>From Mercurial to git
=====================

There are many tools to convert Mercurial repositories to git. The
most famous are, probably, `hg-git <https://hg-git.github.io/>`_ and
`fast-export <http://repo.or.cz/w/fast-export.git>`_ (many years ago
it was known under the name ``hg2git``).

But a better tool, perhaps the best, is `git-remote-hg
<https://github.com/felipec/git-remote-hg>`_. It provides transparent
bidirectional (pull and push) access to Mercurial repositories from
git. Its author wrote a `comparison of alternatives
<https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives>`_
that seems to be mostly objective.

To use git-remote-hg, install or clone it, add to your PATH (or copy
script ``git-remote-hg`` to a directory that's already in PATH) and
prepend ``hg::`` to Mercurial URLs. For example::

    $ git clone https://github.com/felipec/git-remote-hg.git
    $ PATH=$PATH:"`pwd`"/git-remote-hg
    $ git clone hg::https://hg.python.org/peps/ PEPs

To work with the repository just use regular git commands including
``git fetch/pull/push``.

To start converting your Mercurial habits to git see the page
`Mercurial for Git users
<https://mercurial.selenic.com/wiki/GitConcepts>`_ at Mercurial wiki.
At the second half of the page there is a table that lists
corresponding Mercurial and git commands. Should work perfectly in
both directions.


Copyright
=========

This document has been placed in the public domain.



..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End:
   vim: set fenc=us-ascii tw=70 :

From brett at python.org  Sat Sep 12 17:12:13 2015
From: brett at python.org (Brett Cannon)
Date: Sat, 12 Sep 2015 15:12:13 +0000
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150912135451.GA13004@phdru.name>
References: <20150912135451.GA13004@phdru.name>
Message-ID: <CAP1=2W6WZ94C_r28C5mNev53USFN3=RRz-f594Ucr8Nvv8b87A@mail.gmail.com>

I have not had a chance to read Oleg's PEP, but the devguide has the
reverse docs at https://docs.python.org/devguide/gitdevs.html so we have
the VCS docs down pat. :)

On Sat, Sep 12, 2015, 06:59 Oleg Broytman <phd at phdru.name> wrote:

> PEP: XXX
> Title: Collecting information about git
> Version: $Revision$
> Last-Modified: $Date$
> Author: Oleg Broytman <phd at phdru.name>
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 01-Jun-2015
> Post-History: 12-Sep-2015
>
> Abstract
> ========
>
> This Informational PEP collects information about git. There is, of
> course, a lot of documentation for git, so the PEP concentrates on
> more complex (and more related to Python development) issues,
> scenarios and examples.
>
> The plan is to extend the PEP in the future collecting information
> about equivalence of Mercurial and git scenarios to help migrating
> Python development from Mercurial to git.
>
> The author of the PEP doesn't currently plan to write a Process PEP on
> migration Python development from Mercurial to git.
>
>
> Documentation
> =============
>
> Git is accompanied with a lot of documentation, both online and
> offline.
>
>
> Documentation for starters
> --------------------------
>
> Git Tutorial: `part 1
> <https://www.kernel.org/pub/software/scm/git/docs/gittutorial.html>`_,
> `part 2
> <https://www.kernel.org/pub/software/scm/git/docs/gittutorial-2.html>`_.
>
> `Git User's manual
> <https://www.kernel.org/pub/software/scm/git/docs/user-manual.html>`_.
> `Everyday GIT With 20 Commands Or So
> <https://www.kernel.org/pub/software/scm/git/docs/everyday.html>`_.
> `Git workflows
> <https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html>`_.
>
>
> Advanced documentation
> ----------------------
>
> `Git Magic
> <http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html>`_,
> with a number of translations.
>
> `Pro Git <https://git-scm.com/book>`_. The Book about git. Buy it at
> Amazon or download in PDF, mobi, or ePub form. It has translations to
> many different languages. Download Russian translation from `GArik
> <https://github.com/GArik/progit/wiki>`_.
>
> `Git Wiki <https://git.wiki.kernel.org/index.php/Main_Page>`_.
>
>
> Offline documentation
> ---------------------
>
> Git has builtin help: run ``git help $TOPIC``. For example, run
> ``git help git`` or ``git help help``.
>
>
> Quick start
> ===========
>
> Download and installation
> -------------------------
>
> Unix users: `download and install using your package manager
> <https://git-scm.com/download/linux>`_.
>
> Microsoft Windows: download `git-for-windows
> <https://github.com/git-for-windows/git/releases>`_ or `msysGit
> <https://github.com/msysgit/msysgit/releases>`_.
>
> MacOS X: use git installed with `XCode
> <https://developer.apple.com/xcode/downloads/>`_ or download from
> `MacPorts <https://www.macports.org/ports.php?by=name&substr=git>`_ or
> `git-osx-installer
> <http://sourceforge.net/projects/git-osx-installer/files/>`_ or
> install git with `Homebrew <http://brew.sh/>`_: ``brew install git``.
>
> `git-cola <https://git-cola.github.io/index.html>`_ is a Git GUI
> written in Python and GPL licensed. Linux, Windows, MacOS X.
>
> `TortoiseGit <https://tortoisegit.org/>`_ is a Windows Shell Interface
> to Git based on TortoiseSVN; open source.
>
>
> Initial configuration
> ---------------------
>
> This simple code is often appears in documentation, but it is
> important so let repeat it here. Git stores author and committer
> names/emails in every commit, so configure your real name and
> preferred email::
>
>     $ git config --global user.name "User Name"
>     $ git config --global user.email user.name at example.org
>
>
> Examples in this PEP
> ====================
>
> Examples of git commands in this PEP use the following approach. It is
> supposed that you, the user, works with a local repository named
> ``python`` that has an upstream remote repo named ``origin``. Your
> local repo has two branches ``v1`` and ``master``. For most examples
> the currently checked out branch is ``master``. That is, it's assumed
> you have done something like that::
>
>     $ git clone https://git.python.org/python.git
>     $ cd python
>     $ git branch v1 origin/v1
>
> The first command clones remote repository into local directory
> `python``, creates a new local branch master, sets
> remotes/origin/master as its upstream remote-tracking branch and
> checks it out into the working directory.
>
> The last command creates a new local branch v1 and sets
> remotes/origin/v1 as its upstream remote-tracking branch.
>
> The same result can be achieved with commands::
>
>     $ git clone -b v1 https://git.python.org/python.git
>     $ cd python
>     $ git checkout --track origin/master
>
> The last command creates a new local branch master, sets
> remotes/origin/master as its upstream remote-tracking branch and
> checks it out into the working directory.
>
>
> Branches and branches
> =====================
>
> Git terminology can be a bit misleading. Take, for example, the term
> "branch". In git it has two meanings. A branch is a directed line of
> commits (possibly with merges). And a branch is a label or a pointer
> assigned to a line of commits. It is important to distinguish when you
> talk about commits and when about their labels. Lines of commits are
> by itself unnamed and are usually only lengthening and merging.
> Labels, on the other hand, can be created, moved, renamed and deleted
> freely.
>
>
> Remote repositories and remote branches
> =======================================
>
> Remote-tracking branches are branches (pointers to commits) in your
> local repository. They are there for git (and for you) to remember
> what branches and commits have been pulled from and pushed to what
> remote repos (you can pull from and push to many remotes).
> Remote-tracking branches live under ``remotes/$REMOTE`` namespaces,
> e.g. ``remotes/origin/master``.
>
> To see the status of remote-tracking branches run::
>
>     $ git branch -rv
>
> To see local and remote-tracking branches (and tags) pointing to
> commits::
>
>     $ git log --decorate
>
> You never do your own development on remote-tracking branches. You
> create a local branch that has a remote branch as upstream and do
> development on that local branch. On push git pushes commits to the
> remote repo and updates remote-tracking branches, on pull git fetches
> commits from the remote repo, updates remote-tracking branches and
> fast-forwards, merges or rebases local branches.
>
> When you do an initial clone like this::
>
>     $ git clone -b v1 https://git.python.org/python.git
>
> git clones remote repository ``https://git.python.org/python.git``
> <https://git.python.org/python.git> to
> directory ``python``, creates a remote named ``origin``, creates
> remote-tracking branches, creates a local branch ``v1``, configure it
> to track upstream remotes/origin/v1 branch and checks out ``v1`` into
> the working directory.
>
>
> Updating local and remote-tracking branches
> -------------------------------------------
>
> There is a major difference between
>
> ::
>
>     $ git fetch $REMOTE $BRANCH
>
> and
>
> ::
>
>     $ git fetch $REMOTE $BRANCH:$BRANCH
>
> The first command fetches commits from the named $BRANCH in the
> $REMOTE repository that are not in your repository, updates
> remote-tracking branch and leaves the id (the hash) of the head commit
> in file .git/FETCH_HEAD.
>
> The second command fetches commits from the named $BRANCH in the
> $REMOTE repository that are not in your repository and updates both
> the local branch $BRANCH and its upstream remote-tracking branch. But
> it refuses to update branches in case of non-fast-forward. And it
> refuses to update the current branch (currently checked out branch,
> where HEAD is pointing to).
>
> The first command is used internally by ``git pull``.
>
> ::
>
>     $ git pull $REMOTE $BRANCH
>
> is equivalent to
>
> ::
>
>     $ git fetch $REMOTE $BRANCH
>     $ git merge FETCH_HEAD
>
> Certainly, $BRANCH in that case should be your current branch. If you
> want to merge a different branch into your current branch first update
> that non-current branch and then merge::
>
>     $ git fetch origin v1:v1  # Update v1
>     $ git pull --rebase origin master  # Update the current branch master
>                                        # using rebase instead of merge
>     $ git merge v1
>
> If you have not yet pushed commits on ``v1``, though, the scenario has
> to become a bit more complex. Git refuses to update
> non-fast-forwardable branch, and you don't want to do force-pull
> because that would remove your non-pushed commits and you would need
> to recover. So you want to rebase ``v1`` but you cannot rebase
> non-current branch. Hence, checkout ``v1`` and rebase it before
> merging::
>
>     $ git checkout v1
>     $ git pull --rebase origin v1
>     $ git checkout master
>     $ git pull --rebase origin master
>     $ git merge v1
>
> It is possible to configure git to make it fetch/pull a few branches
> or all branches at once, so you can simply run
>
> ::
>
>     $ git pull origin
>
> or even
>
> ::
>
>     $ git pull
>
> Default remote repository for fetching/pulling is ``origin``. Default
> set of references to fetch is calculated using matching algorithm: git
> fetches all branches having the same name on both ends.
>
>
> Push
> ''''
>
> Pushing is a bit simpler. There is only one command ``push``. When you
> run
>
> ::
>
>     $ git push origin v1 master
>
> git pushes local v1 to remote v1 and local master to remote master.
> The same as::
>
>     $ git push origin v1:v1 master:master
>
> Git pushes commits to the remote repo and updates remote-tracking
> branches. Git refuses to push commits that aren't fast-forwardable.
> You can force-push anyway, but please remember - you can force-push to
> your own repositories but don't force-push to public or shared repos.
> If you find git refuses to push commits that aren't fast-forwardable,
> better fetch and merge commits from the remote repo (or rebase your
> commits on top of the fetched commits), then push. Only force-push if
> you know what you do and why you do it. See the section `Commit
> editing and caveats`_ below.
>
> It is possible to configure git to make it push a few branches or all
> branches at once, so you can simply run
>
> ::
>
>     $ git push origin
>
> or even
>
> ::
>
>     $ git push
>
> Default remote repository for pushing is ``origin``. Default set of
> references to push in git before 2.0 is calculated using matching
> algorithm: git pushes all branches having the same name on both ends.
> Default set of references to push in git 2.0+ is calculated using
> simple algorithm: git pushes the current branch back to its
> @{upstream}.
>
> To configure git before 2.0 to the new behaviour run::
>
> $ git config push.default simple
>
> To configure git 2.0+ to the old behaviour run::
>
> $ git config push.default matching
>
> Git doesn't allow to push a branch if it's the current branch in the
> remote non-bare repository: git refuses to update remote working
> directory. You really should push only to bare repositories. For
> non-bare repositories git prefers pull-based workflow.
>
> When you want to deploy code on a remote host and can only use push
> (because your workstation is behind a firewall and you cannot pull
> from it) you do that in two steps using two repositories: you push
> from the workstation to a bare repo on the remote host, ssh to the
> remote host and pull from the bare repo to a non-bare deployment repo.
>
> That changed in git 2.3, but see `the blog post
> <https://github.com/blog/1957-git-2-3-has-been-released#push-to-deploy>`_
> for caveats; in 2.4 the push-to-deploy feature was `further improved
> <
> https://github.com/blog/1994-git-2-4-atomic-pushes-push-to-deploy-and-more#push-to-deploy-improvements
> >`_.
>
>
> Tags
> ''''
>
> Git automatically fetches tags that point to commits being fetched
> during fetch/pull. To fetch all tags (and commits they point to) run
> ``git fetch --tags origin``. To fetch some specific tags fetch them
> explicitly::
>
>     $ git fetch origin tag $TAG1 tag $TAG2...
>
> For example::
>
>     $ git fetch origin tag 1.4.2
>     $ git fetch origin v1:v1 tag 2.1.7
>
> Git doesn't automatically pushes tags. That allows you to have private
> tags. To push tags list them explicitly::
>
>     $ git push origin tag 1.4.2
>     $ git push origin v1 master tag 2.1.7
>
> Or push all tags at once::
>
>     $ git push --tags origin
>
> Don't move tags with ``git tag -f`` or remove tags with ``git tag -d``
> after they have been published.
>
>
> Private information
> '''''''''''''''''''
>
> When cloning/fetching/pulling/pushing git copies only database objects
> (commits, trees, files and tags) and symbolic references (branches and
> lightweight tags). Everything else is private to the repository and
> never cloned, updated or pushed. It's your config, your hooks, your
> private exclude file.
>
> If you want to distribute hooks, copy them to the working tree, add,
> commit, push and instruct the team to update and install the hooks
> manually.
>
>
> Commit editing and caveats
> ==========================
>
> A warning not to edit published (pushed) commits also appears in
> documentation but it's repeated here anyway as it's very important.
>
> It is possible to recover from a forced push but it's PITA for the
> entire team. Please avoid it.
>
> To see what commits have not been published yet compare the head of the
> branch with its upstream remote-tracking branch::
>
>     $ git log origin/master..  # from origin/master to HEAD (of master)
>     $ git log origin/v1..v1  # from origin/v1 to the head of v1
>
> For every branch that has an upstream remote-tracking branch git
> maintains an alias @{upstream} (short version @{u}), so the commands
> above can be given as::
>
>     $ git log @{u}..
>     $ git log v1@{u}..v1
>
> To see the status of all branches::
>
>     $ git branch -avv
>
> To compare the status of local branches with a remote repo::
>
>     $ git remote show origin
>
> Read `how to recover from upstream rebase
> <https://git-scm.com/docs/git-rebase#_recovering_from_upstream_rebase>`_.
> It is in ``git help rebase``.
>
> On the other hand don't be too afraid about commit editing. You can
> safely edit, reorder, remove, combine and split commits that haven't
> been pushed yet. You can even push commits to your own (backup) repo,
> edit them later and force-push edited commits to replace what have
> already been pushed. Not a problem until commits are in a public
> or shared repository.
>
>
> Undo
> ====
>
> Whatever you do, don't panic. Almost anything in git can be undone.
>
>
> git checkout: restore file's content
> ------------------------------------
>
> ``git checkout``, for example, can be used to restore the content of
> file(s) to that one of a commit. Like this::
>
>     git checkout HEAD~ README
>
> The commands restores the contents of README file to the last but one
> commit in the current branch. By default the commit ID is simply HEAD;
> i.e. ``git checkout README`` restores README to the latest commit.
>
> (Do not use ``git checkout`` to view a content of a file in a commit,
> use ``git cat-file -p``; e.g. ``git cat-file -p HEAD~:path/to/README``).
>
>
> git reset: remove (non-pushed) commits
> --------------------------------------
>
> ``git reset`` moves the head of the current branch. The head can be
> moved to point to any commit but it's often used to remove a commit or
> a few (preferably, non-pushed ones) from the top of the branch - that
> is, to move the branch backward in order to undo a few (non-pushed)
> commits.
>
> ``git reset`` has three modes of operation - soft, hard and mixed.
> Default is mixed. ProGit `explains
> <https://git-scm.com/book/en/Git-Tools-Reset-Demystified>`_ the
> difference very clearly. Bare repositories don't have indices or
> working trees so in a bare repo only soft reset is possible.
>
>
> Unstaging
> '''''''''
>
> Mixed mode reset with a path or paths can be used to unstage changes -
> that is, to remove from index changes added with ``git add`` for
> committing. See `The Book
> <https://git-scm.com/book/en/Git-Basics-Undoing-Things>`_ for details
> about unstaging and other undo tricks.
>
>
> git reflog: reference log
> -------------------------
>
> Removing commits with ``git reset`` or moving the head of a branch
> sounds dangerous and it is. But there is a way to undo: another
> reset back to the original commit. Git doesn't remove commits
> immediately; unreferenced commits (in git terminology they are called
> "dangling commits") stay in the database for some time (default is two
> weeks) so you can reset back to it or create a new branch pointing to
> the original commit.
>
> For every move of a branch's head - with ``git commit``, ``git
> checkout``, ``git fetch``, ``git pull``, ``git rebase``, ``git reset``
> and so on - git stores a reference log (reflog for short). For every
> move git stores where the head was. Command ``git reflog`` can be used
> to view (and manipulate) the log.
>
> In addition to the moves of the head of every branch git stores the
> moves of the HEAD - a symbolic reference that (usually) names the
> current branch. HEAD is changed with ``git checkout $BRANCH``.
>
> By default ``git reflog`` shows the moves of the HEAD, i.e. the
> command is equivalent to ``git reflog HEAD``. To show the moves of the
> head of a branch use the command ``git reflog $BRANCH``.
>
> So to undo a ``git reset`` lookup the original commit in ``git
> reflog``, verify it with ``git show`` or ``git log`` and run ``git
> reset $COMMIT_ID``. Git stores the move of the branch's head in
> reflog, so you can undo that undo later again.
>
> In a more complex situation you'd want to move some commits along with
> resetting the head of the branch. Cherry-pick them to the new branch.
> For example, if you want to reset the branch ``master`` back to the
> original commit but preserve two commits created in the current branch
> do something like::
>
>     $ git branch save-master # create a new branch saving master
>     $ git reflog # find the original place of master
>     $ git reset $COMMIT_ID
>     $ git cherry-pick save-master~ save-master
>     $ git branch -D save-master # remove temporary branch
>
>
> git revert: revert a commit
> ---------------------------
>
> ``git revert`` reverts a commit or commits, that is, it creates a new
> commit or commits that revert(s) the effects of the given commits.
> It's the only way to undo published commits (``git commit --amend``,
> ``git rebase`` and ``git reset`` change the branch in
> non-fast-forwardable ways so they should only be used for non-pushed
> commits.)
>
> There is a problem with reverting a merge commit. ``git revert`` can
> undo the code created by the merge commit but it cannot undo the fact
> of merge. See the discussion `How to revert a faulty merge
> <
> https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html
> >`_.
>
>
> One thing that cannot be undone
> -------------------------------
>
> Whatever you undo, there is one thing that cannot be undone -
> overwritten uncommitted changes. Uncommitted changes don't belong to
> git so git cannot help preserving them.
>
> Most of the time git warns you when you're going to execute a command
> that overwrites uncommitted changes. Git doesn't allow you to switch
> branches with ``git checkout``. It stops you when you're going to
> rebase with non-clean working tree. It refuses to pull new commits
> over non-committed files.
>
> But there are commands that do exactly that - overwrite files in the
> working tree. Commands like ``git checkout $PATHs`` or ``git reset
> --hard`` silently overwrite files including your uncommitted changes.
>
> With that in mind you can understand the stance "commit early, commit
> often". Commit as often as possible. Commit on every save in your
> editor or IDE. You can edit your commits before pushing - edit commit
> messages, change commits, reorder, combine, split, remove. But save
> your changes in git database, either commit changes or at least stash
> them with ``git stash``.
>
>
> Merge or rebase?
> ================
>
> Internet is full of heated discussions on the topic: "merge or
> rebase?" Most of them are meaningless. When a DVCS is being used in a
> big team with a big and complex project with many branches there is
> simply no way to avoid merges. So the question's diminished to
> "whether to use rebase, and if yes - when to use rebase?" Considering
> that it is very much recommended not to rebase published commits the
> question's diminished even further: "whether to use rebase on
> non-pushed commits?"
>
> That small question is for the team to decide. The author of the PEP
> recommends to use rebase when pulling, i.e. always do ``git pull
> --rebase`` or even configure automatic setup of rebase for every new
> branch::
>
>     $ git config branch.autosetuprebase always
>
> and configure rebase for existing branches::
>
>     $ git config branch.$NAME.rebase true
>
> For example::
>
>     $ git config branch.v1.rebase true
>     $ git config branch.master.rebase true
>
> After that ``git pull origin master`` becomes equivalent to ``git pull
> --rebase origin master``.
>
> It is recommended to create new commits in a separate feature or topic
> branch while using rebase to update the mainline branch. When the
> topic branch is ready merge it into mainline. To avoid a tedious task
> of resolving large number of conflicts at once you can merge the topic
> branch to the mainline from time to time and switch back to the topic
> branch to continue working on it. The entire workflow would be
> something like::
>
>     $ git checkout -b issue-42  # create a new issue branch and switch to
> it
>         ...edit/test/commit...
>     $ git checkout master
>     $ git pull --rebase origin master  # update master from the upstream
>     $ git merge issue-42
>     $ git branch -d issue-42  # delete the topic branch
>     $ git push origin master
>
> When the topic branch is deleted only the label is removed, commits
> are stayed in the database, they are now merged into master::
>
>     o--o--o--o--o--M--< master - the mainline branch
>         \         /
>          --*--*--*             - the topic branch, now unnamed
>
> The topic branch is deleted to avoid cluttering branch namespace with
> small topic branches. Information on what issue was fixed or what
> feature was implemented should be in the commit messages.
>
>
> Null-merges
> ===========
>
> Git has a builtin merge strategy for what Python core developers call
> "null-merge"::
>
>     $ git merge -s ours v1  # null-merge v1 into master
>
>
> Advanced configuration
> ======================
>
> Line endings
> ------------
>
> Git has builtin mechanisms to handle line endings between platforms
> with different end-of-line styles. To allow git to do CRLF conversion
> assign ``text`` attribute to files using `.gitattributes
> <https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html>`_.
> For files that have to have specific line endings assign ``eol``
> attribute. For binary files the attribute is, naturally, ``binary``.
>
> For example::
>
>     $ cat .gitattributes
>     *.py text
>     *.txt text
>     *.png binary
>     /readme.txt eol=CRLF
>
> To check what attributes git uses for files use ``git check-attr``
> command. For example::
>
> $ git check-attr -a -- \*.py
>
>
> Advanced topics
> ===============
>
> Staging area
> ------------
>
> Staging area aka index aka cache is a distinguishing feature of git.
> Staging area is where git collects patches before committing them.
> Separation between collecting patches and commit phases provides a
> very useful feature of git: you can review collected patches before
> commit and even edit them - remove some hunks, add new hunks and
> review again.
>
> To add files to the index use ``git add``. Collecting patches before
> committing means you need to do that for every change, not only to add
> new (untracked) files. To simplify committing in case you just want to
> commit everything without reviewing run ``git commit --all`` (or just
> ``-a``) - the command adds every changed tracked file to the index and
> then commit. To commit a file or files regardless of patches collected
> in the index run ``git commit [--only|-o] -- $FILE...``.
>
> To add hunks of patches to the index use ``git add --patch`` (or just
> ``-p``). To remove collected files from the index use ``git reset HEAD
> -- $FILE...`` To add/inspect/remove collected hunks use ``git add
> --interactive`` (``-i``).
>
> To see the diff between the index and the last commit (i.e., collected
> patches) use ``git diff --cached``. To see the diff between the
> working tree and the index (i.e., uncollected patches) use just ``git
> diff``. To see the diff between the working tree and the last commit
> (i.e., both collected and uncollected patches) run ``git diff HEAD``.
>
> See `WhatIsTheIndex
> <https://git.wiki.kernel.org/index.php/WhatIsTheIndex>`_ and
> `IndexCommandQuickref
> <https://git.wiki.kernel.org/index.php/IndexCommandQuickref>`_ in Git
> Wiki.
>
>
> ReReRe
> ======
>
> Rerere is a mechanism that helps to resolve repeated merge conflicts.
> The most frequent source of recurring merge conflicts are topic
> branches that are merged into mainline and then the merge commits are
> removed; that's often performed to test the topic branches and train
> rerere; merge commits are removed to have clean linear history and
> finish the topic branch with only one last merge commit.
>
> Rerere works by remembering the states of tree before and after a
> successful commit. That way rerere can automatically resolve conflicts
> if they appear in the same files.
>
> Rerere can be used manually with ``git rerere`` command but most often
> it's used automatically. Enable rerere with these commands in a
> working tree::
>
>     $ git config rerere.enabled true
>     $ git config rerere.autoupdate true
>
> You don't need to turn rerere on globally - you don't want rerere in
> bare repositories or single-branche repositories; you only need rerere
> in repos where you often perform merges and resolve merge conflicts.
>
> See `Rerere <https://git-scm.com/book/en/Git-Tools-Rerere>`_ in The
> Book.
>
>
> Database maintenance
> ====================
>
> Git object database and other files/directories under ``.git`` require
> periodic maintenance and cleanup. For example, commit editing left
> unreferenced objects (dangling objects, in git terminology) and these
> objects should be pruned to avoid collecting cruft in the DB. The
> command ``git gc`` is used for maintenance. Git automatically runs
> ``git gc --auto`` as a part of some commands to do quick maintenance.
> Users are recommended to run ``git gc --aggressive`` from time to
> time; ``git help gc`` recommends to run it  every few hundred
> changesets; for more intensive projects it should be something like
> once a week and less frequently (biweekly or monthly) for lesser
> active projects.
>
> ``git gc --aggressive`` not only removes dangling objects, it also
> repacks object database into indexed and better optimized pack(s); it
> also packs symbolic references (branches and tags). Another way to do
> it is to run ``git repack``.
>
> There is a well-known `message
> <https://gcc.gnu.org/ml/gcc/2007-12/msg00165.html>`_ from Linus
> Torvalds regarding "stupidity" of ``git gc --aggressive``. The message
> can safely be ignored now. It is old and outdated, ``git gc
> --aggressive`` became much better since that time.
>
> For those who still prefer ``git repack`` over ``git gc --aggressive``
> the recommended parameters are ``git repack -a -d -f --depth=20
> --window=250``. See `this detailed experiment
> <http://vcscompare.blogspot.ru/2008/06/git-repack-parameters.html>`_
> for explanation of the effects of these parameters.
>
> From time to time run ``git fsck [--strict]`` to verify integrity of
> the database. ``git fsck`` may produce a list of dangling objects;
> that's not an error, just a reminder to perform regular maintenance.
>
>
> Tips and tricks
> ===============
>
> Command-line options and arguments
> ----------------------------------
>
> `git help cli
> <https://www.kernel.org/pub/software/scm/git/docs/gitcli.html>`_
> recommends not to combine short options/flags. Most of the times
> combining works: ``git commit -av`` works perfectly, but there are
> situations when it doesn't. E.g., ``git log -p -5`` cannot be combined
> as ``git log -p5``.
>
> Some options have arguments, some even have default arguments. In that
> case the argument for such option must be spelled in a sticky way:
> ``-Oarg``, never ``-O arg`` because for an option that has a default
> argument the latter means "use default value for option ``-O`` and
> pass ``arg`` further to the option parser". For example, ``git grep``
> has an option ``-O`` that passes a list of names of the found files to
> a program; default program for ``-O`` is a pager (usually ``less``),
> but you can use your editor::
>
>     $ git grep -Ovim # but not -O vim
>
> BTW, if git is instructed to use ``less`` as the pager (i.e., if pager
> is not configured in git at all it uses ``less`` by default, or if it
> gets ``less`` from GIT_PAGER or PAGER environment variables, or if it
> was configured with ``git config --global core.pager less``, or
> ``less`` is used in the command ``git grep -Oless``) ``git grep``
> passes ``+/$pattern`` option to ``less`` which is quite convenient.
> Unfortunately, ``git grep`` doesn't pass the pattern if the pager is
> not exactly ``less``, even if it's ``less`` with parameters (something
> like ``git config --global core.pager less -FRSXgimq``); fortunately,
> ``git grep -Oless`` always passes the pattern.
>
>
> bash/zsh completion
> -------------------
>
> It's a bit hard to type ``git rebase --interactive --preserve-merges
> HEAD~5`` manually even for those who are happy to use command-line,
> and this is where shell completion is of great help. Bash/zsh come
> with programmable completion, often automatically installed and
> enabled, so if you have bash/zsh and git installed, chances are you
> are already done - just go and use it at the command-line.
>
> If you don't have necessary bits installed, install and enable
> bash_completion package. If you want to upgrade your git completion to
> the latest and greatest download necessary file from `git contrib
> <https://git.kernel.org/cgit/git/git.git/tree/contrib/completion>`_.
>
> Git-for-windows comes with git-bash for which bash completion is
> installed and enabled.
>
>
> bash/zsh prompt
> ---------------
>
> For command-line lovers shell prompt can carry a lot of useful
> information. To include git information in the prompt use
> `git-prompt.sh
> <
> https://git.kernel.org/cgit/git/git.git/tree/contrib/completion/git-prompt.sh
> >`_.
> Read the detailed instructions in the file.
>
> Search the Net for "git prompt" to find other prompt variants.
>
>
> git on server
> =============
>
> The simplest way to publish a repository or a group of repositories is
> ``git daemon``. The daemon provides anonymous access, by default it is
> read-only. The repositories are accessible by git protocol (git://
> URLs). Write access can be enabled but the protocol lacks any
> authentication means, so it should be enabled only within a trusted
> LAN. See ``git help daemon`` for details.
>
> Git over ssh provides authentication and repo-level authorisation as
> repositories can be made user- or group-writeable (see parameter
> ``core.sharedRepository`` in ``git help config``). If that's too
> permissive or too restrictive for some project's needs there is a
> wrapper `gitolite <http://gitolite.com/gitolite/index.html>`_ that can
> be configured to allow access with great granularity; gitolite is
> written in Perl and has a lot of documentation.
>
> Web interface to browse repositories can be created using `gitweb
> <https://git.kernel.org/cgit/git/git.git/tree/gitweb>`_ or `cgit
> <http://git.zx2c4.com/cgit/about/>`_. Both are CGI scripts (written in
> Perl and C). In addition to web interface both provide read-only dumb
> http access for git (http(s):// URLs).
>
> There are also more advanced web-based development environments that
> include ability to manage users, groups and projects; private,
> group-accessible and public repositories; they often include issue
> trackers, wiki pages, pull requests and other tools for development
> and communication. Among these environments are `Kallithea
> <https://kallithea-scm.org/>`_ and `pagure <https://pagure.io/>`_,
> both are written in Python; pagure was written by Fedora developers
> and is being used to develop some Fedora projects. `Gogs
> <http://gogs.io/>`_ is written in Go; there is a fork `Gitea
> <http://gitea.io/>`_.
>
> And last but not least, `Gitlab <https://about.gitlab.com/>`_. It's
> perhaps the most advanced web-based development environment for git.
> Written in Ruby, community edition is free and open source (MIT
> license).
>
>
> From Mercurial to git
> =====================
>
> There are many tools to convert Mercurial repositories to git. The
> most famous are, probably, `hg-git <https://hg-git.github.io/>`_ and
> `fast-export <http://repo.or.cz/w/fast-export.git>`_ (many years ago
> it was known under the name ``hg2git``).
>
> But a better tool, perhaps the best, is `git-remote-hg
> <https://github.com/felipec/git-remote-hg>`_. It provides transparent
> bidirectional (pull and push) access to Mercurial repositories from
> git. Its author wrote a `comparison of alternatives
> <
> https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives
> >`_
> that seems to be mostly objective.
>
> To use git-remote-hg, install or clone it, add to your PATH (or copy
> script ``git-remote-hg`` to a directory that's already in PATH) and
> prepend ``hg::`` to Mercurial URLs. For example::
>
>     $ git clone https://github.com/felipec/git-remote-hg.git
>     $ PATH=$PATH:"`pwd`"/git-remote-hg
>     $ git clone hg::https://hg.python.org/peps/ PEPs
>
> To work with the repository just use regular git commands including
> ``git fetch/pull/push``.
>
> To start converting your Mercurial habits to git see the page
> `Mercurial for Git users
> <https://mercurial.selenic.com/wiki/GitConcepts>`_ at Mercurial wiki.
> At the second half of the page there is a table that lists
> corresponding Mercurial and git commands. Should work perfectly in
> both directions.
>
>
> Copyright
> =========
>
> This document has been placed in the public domain.
>
>
>
> ..
>    Local Variables:
>    mode: indented-text
>    indent-tabs-mode: nil
>    sentence-end-double-space: t
>    fill-column: 70
>    coding: utf-8
>    End:
>    vim: set fenc=us-ascii tw=70 :
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150912/32b85877/attachment-0001.html>

From brett at python.org  Sat Sep 12 17:13:46 2015
From: brett at python.org (Brett Cannon)
Date: Sat, 12 Sep 2015 15:13:46 +0000
Subject: [Python-Dev] Choosing an official stance towards module
 deprecation in Python 3
In-Reply-To: <mt0eb5$il5$1@ger.gmane.org>
References: <CAP1=2W7uDSiu3zZ-UQF1fWQOx10dZ7PF+K_pKQ7XG4Z4+Sp=NA@mail.gmail.com>
 <mt0eb5$il5$1@ger.gmane.org>
Message-ID: <CAP1=2W4ZnXLVn2C2ro61UTxkQMUZJ5iDYrHfOoL0tiuaSA1=Mg@mail.gmail.com>

Someone else brought up warnings in Python 2.7 and my response was that you
already get the warning in Python 3 so why get it twice across different
versions?

On Fri, Sep 11, 2015, 22:48 Serhiy Storchaka <storchaka at gmail.com> wrote:

> On 08.09.15 19:59, Brett Cannon wrote:
> > The approaches to module deprecation I have seen are:
> > 1. Nothing changes to the deprecation process; you deprecate a module
> > and remove it in one to two releases
> > 2. Deprecate the module but with no plans for removal until Python 2.7
> > reaches its EOL (I have been calling this Python 4)
> > 3. Document the deprecation but no actual code deprecation
>
> Of course #2 LGTM. What if at the same time add Py3k warning in next 2.7
> bugfix release?
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150912/0e9cdc1d/attachment.html>

From guido at python.org  Sat Sep 12 17:29:10 2015
From: guido at python.org (Guido van Rossum)
Date: Sat, 12 Sep 2015 08:29:10 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAP1=2W6WZ94C_r28C5mNev53USFN3=RRz-f594Ucr8Nvv8b87A@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <CAP1=2W6WZ94C_r28C5mNev53USFN3=RRz-f594Ucr8Nvv8b87A@mail.gmail.com>
Message-ID: <CAP7+vJ+NH4r=ET8+SjhAqgKhQO=YeAjjsUShHXNjwNXq2b7AAA@mail.gmail.com>

I have only skimmed the first half but it looks really good.

On Sat, Sep 12, 2015 at 8:12 AM, Brett Cannon <brett at python.org> wrote:

> I have not had a chance to read Oleg's PEP, but the devguide has the
> reverse docs at https://docs.python.org/devguide/gitdevs.html so we have
> the VCS docs down pat. :)
>
> On Sat, Sep 12, 2015, 06:59 Oleg Broytman <phd at phdru.name> wrote:
>
>> PEP: XXX
>> Title: Collecting information about git
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Oleg Broytman <phd at phdru.name>
>> Status: Draft
>> Type: Informational
>> Content-Type: text/x-rst
>> Created: 01-Jun-2015
>> Post-History: 12-Sep-2015
>>
>> Abstract
>> ========
>>
>> This Informational PEP collects information about git. There is, of
>> course, a lot of documentation for git, so the PEP concentrates on
>> more complex (and more related to Python development) issues,
>> scenarios and examples.
>>
>> The plan is to extend the PEP in the future collecting information
>> about equivalence of Mercurial and git scenarios to help migrating
>> Python development from Mercurial to git.
>>
>> The author of the PEP doesn't currently plan to write a Process PEP on
>> migration Python development from Mercurial to git.
>>
>>
>> Documentation
>> =============
>>
>> Git is accompanied with a lot of documentation, both online and
>> offline.
>>
>>
>> Documentation for starters
>> --------------------------
>>
>> Git Tutorial: `part 1
>> <https://www.kernel.org/pub/software/scm/git/docs/gittutorial.html>`_,
>> `part 2
>> <https://www.kernel.org/pub/software/scm/git/docs/gittutorial-2.html>`_.
>>
>> `Git User's manual
>> <https://www.kernel.org/pub/software/scm/git/docs/user-manual.html>`_.
>> `Everyday GIT With 20 Commands Or So
>> <https://www.kernel.org/pub/software/scm/git/docs/everyday.html>`_.
>> `Git workflows
>> <https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html>`_.
>>
>>
>> Advanced documentation
>> ----------------------
>>
>> `Git Magic
>> <http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html>`_,
>> with a number of translations.
>>
>> `Pro Git <https://git-scm.com/book>`_. The Book about git. Buy it at
>> Amazon or download in PDF, mobi, or ePub form. It has translations to
>> many different languages. Download Russian translation from `GArik
>> <https://github.com/GArik/progit/wiki>`_.
>>
>> `Git Wiki <https://git.wiki.kernel.org/index.php/Main_Page>`_.
>>
>>
>> Offline documentation
>> ---------------------
>>
>> Git has builtin help: run ``git help $TOPIC``. For example, run
>> ``git help git`` or ``git help help``.
>>
>>
>> Quick start
>> ===========
>>
>> Download and installation
>> -------------------------
>>
>> Unix users: `download and install using your package manager
>> <https://git-scm.com/download/linux>`_.
>>
>> Microsoft Windows: download `git-for-windows
>> <https://github.com/git-for-windows/git/releases>`_ or `msysGit
>> <https://github.com/msysgit/msysgit/releases>`_.
>>
>> MacOS X: use git installed with `XCode
>> <https://developer.apple.com/xcode/downloads/>`_ or download from
>> `MacPorts <https://www.macports.org/ports.php?by=name&substr=git>`_ or
>> `git-osx-installer
>> <http://sourceforge.net/projects/git-osx-installer/files/>`_ or
>> install git with `Homebrew <http://brew.sh/>`_: ``brew install git``.
>>
>> `git-cola <https://git-cola.github.io/index.html>`_ is a Git GUI
>> written in Python and GPL licensed. Linux, Windows, MacOS X.
>>
>> `TortoiseGit <https://tortoisegit.org/>`_ is a Windows Shell Interface
>> to Git based on TortoiseSVN; open source.
>>
>>
>> Initial configuration
>> ---------------------
>>
>> This simple code is often appears in documentation, but it is
>> important so let repeat it here. Git stores author and committer
>> names/emails in every commit, so configure your real name and
>> preferred email::
>>
>>     $ git config --global user.name "User Name"
>>     $ git config --global user.email user.name at example.org
>>
>>
>> Examples in this PEP
>> ====================
>>
>> Examples of git commands in this PEP use the following approach. It is
>> supposed that you, the user, works with a local repository named
>> ``python`` that has an upstream remote repo named ``origin``. Your
>> local repo has two branches ``v1`` and ``master``. For most examples
>> the currently checked out branch is ``master``. That is, it's assumed
>> you have done something like that::
>>
>>     $ git clone https://git.python.org/python.git
>>     $ cd python
>>     $ git branch v1 origin/v1
>>
>> The first command clones remote repository into local directory
>> `python``, creates a new local branch master, sets
>> remotes/origin/master as its upstream remote-tracking branch and
>> checks it out into the working directory.
>>
>> The last command creates a new local branch v1 and sets
>> remotes/origin/v1 as its upstream remote-tracking branch.
>>
>> The same result can be achieved with commands::
>>
>>     $ git clone -b v1 https://git.python.org/python.git
>>     $ cd python
>>     $ git checkout --track origin/master
>>
>> The last command creates a new local branch master, sets
>> remotes/origin/master as its upstream remote-tracking branch and
>> checks it out into the working directory.
>>
>>
>> Branches and branches
>> =====================
>>
>> Git terminology can be a bit misleading. Take, for example, the term
>> "branch". In git it has two meanings. A branch is a directed line of
>> commits (possibly with merges). And a branch is a label or a pointer
>> assigned to a line of commits. It is important to distinguish when you
>> talk about commits and when about their labels. Lines of commits are
>> by itself unnamed and are usually only lengthening and merging.
>> Labels, on the other hand, can be created, moved, renamed and deleted
>> freely.
>>
>>
>> Remote repositories and remote branches
>> =======================================
>>
>> Remote-tracking branches are branches (pointers to commits) in your
>> local repository. They are there for git (and for you) to remember
>> what branches and commits have been pulled from and pushed to what
>> remote repos (you can pull from and push to many remotes).
>> Remote-tracking branches live under ``remotes/$REMOTE`` namespaces,
>> e.g. ``remotes/origin/master``.
>>
>> To see the status of remote-tracking branches run::
>>
>>     $ git branch -rv
>>
>> To see local and remote-tracking branches (and tags) pointing to
>> commits::
>>
>>     $ git log --decorate
>>
>> You never do your own development on remote-tracking branches. You
>> create a local branch that has a remote branch as upstream and do
>> development on that local branch. On push git pushes commits to the
>> remote repo and updates remote-tracking branches, on pull git fetches
>> commits from the remote repo, updates remote-tracking branches and
>> fast-forwards, merges or rebases local branches.
>>
>> When you do an initial clone like this::
>>
>>     $ git clone -b v1 https://git.python.org/python.git
>>
>> git clones remote repository ``https://git.python.org/python.git``
>> <https://git.python.org/python.git> to
>> directory ``python``, creates a remote named ``origin``, creates
>> remote-tracking branches, creates a local branch ``v1``, configure it
>> to track upstream remotes/origin/v1 branch and checks out ``v1`` into
>> the working directory.
>>
>>
>> Updating local and remote-tracking branches
>> -------------------------------------------
>>
>> There is a major difference between
>>
>> ::
>>
>>     $ git fetch $REMOTE $BRANCH
>>
>> and
>>
>> ::
>>
>>     $ git fetch $REMOTE $BRANCH:$BRANCH
>>
>> The first command fetches commits from the named $BRANCH in the
>> $REMOTE repository that are not in your repository, updates
>> remote-tracking branch and leaves the id (the hash) of the head commit
>> in file .git/FETCH_HEAD.
>>
>> The second command fetches commits from the named $BRANCH in the
>> $REMOTE repository that are not in your repository and updates both
>> the local branch $BRANCH and its upstream remote-tracking branch. But
>> it refuses to update branches in case of non-fast-forward. And it
>> refuses to update the current branch (currently checked out branch,
>> where HEAD is pointing to).
>>
>> The first command is used internally by ``git pull``.
>>
>> ::
>>
>>     $ git pull $REMOTE $BRANCH
>>
>> is equivalent to
>>
>> ::
>>
>>     $ git fetch $REMOTE $BRANCH
>>     $ git merge FETCH_HEAD
>>
>> Certainly, $BRANCH in that case should be your current branch. If you
>> want to merge a different branch into your current branch first update
>> that non-current branch and then merge::
>>
>>     $ git fetch origin v1:v1  # Update v1
>>     $ git pull --rebase origin master  # Update the current branch master
>>                                        # using rebase instead of merge
>>     $ git merge v1
>>
>> If you have not yet pushed commits on ``v1``, though, the scenario has
>> to become a bit more complex. Git refuses to update
>> non-fast-forwardable branch, and you don't want to do force-pull
>> because that would remove your non-pushed commits and you would need
>> to recover. So you want to rebase ``v1`` but you cannot rebase
>> non-current branch. Hence, checkout ``v1`` and rebase it before
>> merging::
>>
>>     $ git checkout v1
>>     $ git pull --rebase origin v1
>>     $ git checkout master
>>     $ git pull --rebase origin master
>>     $ git merge v1
>>
>> It is possible to configure git to make it fetch/pull a few branches
>> or all branches at once, so you can simply run
>>
>> ::
>>
>>     $ git pull origin
>>
>> or even
>>
>> ::
>>
>>     $ git pull
>>
>> Default remote repository for fetching/pulling is ``origin``. Default
>> set of references to fetch is calculated using matching algorithm: git
>> fetches all branches having the same name on both ends.
>>
>>
>> Push
>> ''''
>>
>> Pushing is a bit simpler. There is only one command ``push``. When you
>> run
>>
>> ::
>>
>>     $ git push origin v1 master
>>
>> git pushes local v1 to remote v1 and local master to remote master.
>> The same as::
>>
>>     $ git push origin v1:v1 master:master
>>
>> Git pushes commits to the remote repo and updates remote-tracking
>> branches. Git refuses to push commits that aren't fast-forwardable.
>> You can force-push anyway, but please remember - you can force-push to
>> your own repositories but don't force-push to public or shared repos.
>> If you find git refuses to push commits that aren't fast-forwardable,
>> better fetch and merge commits from the remote repo (or rebase your
>> commits on top of the fetched commits), then push. Only force-push if
>> you know what you do and why you do it. See the section `Commit
>> editing and caveats`_ below.
>>
>> It is possible to configure git to make it push a few branches or all
>> branches at once, so you can simply run
>>
>> ::
>>
>>     $ git push origin
>>
>> or even
>>
>> ::
>>
>>     $ git push
>>
>> Default remote repository for pushing is ``origin``. Default set of
>> references to push in git before 2.0 is calculated using matching
>> algorithm: git pushes all branches having the same name on both ends.
>> Default set of references to push in git 2.0+ is calculated using
>> simple algorithm: git pushes the current branch back to its
>> @{upstream}.
>>
>> To configure git before 2.0 to the new behaviour run::
>>
>> $ git config push.default simple
>>
>> To configure git 2.0+ to the old behaviour run::
>>
>> $ git config push.default matching
>>
>> Git doesn't allow to push a branch if it's the current branch in the
>> remote non-bare repository: git refuses to update remote working
>> directory. You really should push only to bare repositories. For
>> non-bare repositories git prefers pull-based workflow.
>>
>> When you want to deploy code on a remote host and can only use push
>> (because your workstation is behind a firewall and you cannot pull
>> from it) you do that in two steps using two repositories: you push
>> from the workstation to a bare repo on the remote host, ssh to the
>> remote host and pull from the bare repo to a non-bare deployment repo.
>>
>> That changed in git 2.3, but see `the blog post
>> <https://github.com/blog/1957-git-2-3-has-been-released#push-to-deploy>`_
>> for caveats; in 2.4 the push-to-deploy feature was `further improved
>> <
>> https://github.com/blog/1994-git-2-4-atomic-pushes-push-to-deploy-and-more#push-to-deploy-improvements
>> >`_.
>>
>>
>> Tags
>> ''''
>>
>> Git automatically fetches tags that point to commits being fetched
>> during fetch/pull. To fetch all tags (and commits they point to) run
>> ``git fetch --tags origin``. To fetch some specific tags fetch them
>> explicitly::
>>
>>     $ git fetch origin tag $TAG1 tag $TAG2...
>>
>> For example::
>>
>>     $ git fetch origin tag 1.4.2
>>     $ git fetch origin v1:v1 tag 2.1.7
>>
>> Git doesn't automatically pushes tags. That allows you to have private
>> tags. To push tags list them explicitly::
>>
>>     $ git push origin tag 1.4.2
>>     $ git push origin v1 master tag 2.1.7
>>
>> Or push all tags at once::
>>
>>     $ git push --tags origin
>>
>> Don't move tags with ``git tag -f`` or remove tags with ``git tag -d``
>> after they have been published.
>>
>>
>> Private information
>> '''''''''''''''''''
>>
>> When cloning/fetching/pulling/pushing git copies only database objects
>> (commits, trees, files and tags) and symbolic references (branches and
>> lightweight tags). Everything else is private to the repository and
>> never cloned, updated or pushed. It's your config, your hooks, your
>> private exclude file.
>>
>> If you want to distribute hooks, copy them to the working tree, add,
>> commit, push and instruct the team to update and install the hooks
>> manually.
>>
>>
>> Commit editing and caveats
>> ==========================
>>
>> A warning not to edit published (pushed) commits also appears in
>> documentation but it's repeated here anyway as it's very important.
>>
>> It is possible to recover from a forced push but it's PITA for the
>> entire team. Please avoid it.
>>
>> To see what commits have not been published yet compare the head of the
>> branch with its upstream remote-tracking branch::
>>
>>     $ git log origin/master..  # from origin/master to HEAD (of master)
>>     $ git log origin/v1..v1  # from origin/v1 to the head of v1
>>
>> For every branch that has an upstream remote-tracking branch git
>> maintains an alias @{upstream} (short version @{u}), so the commands
>> above can be given as::
>>
>>     $ git log @{u}..
>>     $ git log v1@{u}..v1
>>
>> To see the status of all branches::
>>
>>     $ git branch -avv
>>
>> To compare the status of local branches with a remote repo::
>>
>>     $ git remote show origin
>>
>> Read `how to recover from upstream rebase
>> <https://git-scm.com/docs/git-rebase#_recovering_from_upstream_rebase>`_.
>> It is in ``git help rebase``.
>>
>> On the other hand don't be too afraid about commit editing. You can
>> safely edit, reorder, remove, combine and split commits that haven't
>> been pushed yet. You can even push commits to your own (backup) repo,
>> edit them later and force-push edited commits to replace what have
>> already been pushed. Not a problem until commits are in a public
>> or shared repository.
>>
>>
>> Undo
>> ====
>>
>> Whatever you do, don't panic. Almost anything in git can be undone.
>>
>>
>> git checkout: restore file's content
>> ------------------------------------
>>
>> ``git checkout``, for example, can be used to restore the content of
>> file(s) to that one of a commit. Like this::
>>
>>     git checkout HEAD~ README
>>
>> The commands restores the contents of README file to the last but one
>> commit in the current branch. By default the commit ID is simply HEAD;
>> i.e. ``git checkout README`` restores README to the latest commit.
>>
>> (Do not use ``git checkout`` to view a content of a file in a commit,
>> use ``git cat-file -p``; e.g. ``git cat-file -p HEAD~:path/to/README``).
>>
>>
>> git reset: remove (non-pushed) commits
>> --------------------------------------
>>
>> ``git reset`` moves the head of the current branch. The head can be
>> moved to point to any commit but it's often used to remove a commit or
>> a few (preferably, non-pushed ones) from the top of the branch - that
>> is, to move the branch backward in order to undo a few (non-pushed)
>> commits.
>>
>> ``git reset`` has three modes of operation - soft, hard and mixed.
>> Default is mixed. ProGit `explains
>> <https://git-scm.com/book/en/Git-Tools-Reset-Demystified>`_ the
>> difference very clearly. Bare repositories don't have indices or
>> working trees so in a bare repo only soft reset is possible.
>>
>>
>> Unstaging
>> '''''''''
>>
>> Mixed mode reset with a path or paths can be used to unstage changes -
>> that is, to remove from index changes added with ``git add`` for
>> committing. See `The Book
>> <https://git-scm.com/book/en/Git-Basics-Undoing-Things>`_ for details
>> about unstaging and other undo tricks.
>>
>>
>> git reflog: reference log
>> -------------------------
>>
>> Removing commits with ``git reset`` or moving the head of a branch
>> sounds dangerous and it is. But there is a way to undo: another
>> reset back to the original commit. Git doesn't remove commits
>> immediately; unreferenced commits (in git terminology they are called
>> "dangling commits") stay in the database for some time (default is two
>> weeks) so you can reset back to it or create a new branch pointing to
>> the original commit.
>>
>> For every move of a branch's head - with ``git commit``, ``git
>> checkout``, ``git fetch``, ``git pull``, ``git rebase``, ``git reset``
>> and so on - git stores a reference log (reflog for short). For every
>> move git stores where the head was. Command ``git reflog`` can be used
>> to view (and manipulate) the log.
>>
>> In addition to the moves of the head of every branch git stores the
>> moves of the HEAD - a symbolic reference that (usually) names the
>> current branch. HEAD is changed with ``git checkout $BRANCH``.
>>
>> By default ``git reflog`` shows the moves of the HEAD, i.e. the
>> command is equivalent to ``git reflog HEAD``. To show the moves of the
>> head of a branch use the command ``git reflog $BRANCH``.
>>
>> So to undo a ``git reset`` lookup the original commit in ``git
>> reflog``, verify it with ``git show`` or ``git log`` and run ``git
>> reset $COMMIT_ID``. Git stores the move of the branch's head in
>> reflog, so you can undo that undo later again.
>>
>> In a more complex situation you'd want to move some commits along with
>> resetting the head of the branch. Cherry-pick them to the new branch.
>> For example, if you want to reset the branch ``master`` back to the
>> original commit but preserve two commits created in the current branch
>> do something like::
>>
>>     $ git branch save-master # create a new branch saving master
>>     $ git reflog # find the original place of master
>>     $ git reset $COMMIT_ID
>>     $ git cherry-pick save-master~ save-master
>>     $ git branch -D save-master # remove temporary branch
>>
>>
>> git revert: revert a commit
>> ---------------------------
>>
>> ``git revert`` reverts a commit or commits, that is, it creates a new
>> commit or commits that revert(s) the effects of the given commits.
>> It's the only way to undo published commits (``git commit --amend``,
>> ``git rebase`` and ``git reset`` change the branch in
>> non-fast-forwardable ways so they should only be used for non-pushed
>> commits.)
>>
>> There is a problem with reverting a merge commit. ``git revert`` can
>> undo the code created by the merge commit but it cannot undo the fact
>> of merge. See the discussion `How to revert a faulty merge
>> <
>> https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html
>> >`_.
>>
>>
>> One thing that cannot be undone
>> -------------------------------
>>
>> Whatever you undo, there is one thing that cannot be undone -
>> overwritten uncommitted changes. Uncommitted changes don't belong to
>> git so git cannot help preserving them.
>>
>> Most of the time git warns you when you're going to execute a command
>> that overwrites uncommitted changes. Git doesn't allow you to switch
>> branches with ``git checkout``. It stops you when you're going to
>> rebase with non-clean working tree. It refuses to pull new commits
>> over non-committed files.
>>
>> But there are commands that do exactly that - overwrite files in the
>> working tree. Commands like ``git checkout $PATHs`` or ``git reset
>> --hard`` silently overwrite files including your uncommitted changes.
>>
>> With that in mind you can understand the stance "commit early, commit
>> often". Commit as often as possible. Commit on every save in your
>> editor or IDE. You can edit your commits before pushing - edit commit
>> messages, change commits, reorder, combine, split, remove. But save
>> your changes in git database, either commit changes or at least stash
>> them with ``git stash``.
>>
>>
>> Merge or rebase?
>> ================
>>
>> Internet is full of heated discussions on the topic: "merge or
>> rebase?" Most of them are meaningless. When a DVCS is being used in a
>> big team with a big and complex project with many branches there is
>> simply no way to avoid merges. So the question's diminished to
>> "whether to use rebase, and if yes - when to use rebase?" Considering
>> that it is very much recommended not to rebase published commits the
>> question's diminished even further: "whether to use rebase on
>> non-pushed commits?"
>>
>> That small question is for the team to decide. The author of the PEP
>> recommends to use rebase when pulling, i.e. always do ``git pull
>> --rebase`` or even configure automatic setup of rebase for every new
>> branch::
>>
>>     $ git config branch.autosetuprebase always
>>
>> and configure rebase for existing branches::
>>
>>     $ git config branch.$NAME.rebase true
>>
>> For example::
>>
>>     $ git config branch.v1.rebase true
>>     $ git config branch.master.rebase true
>>
>> After that ``git pull origin master`` becomes equivalent to ``git pull
>> --rebase origin master``.
>>
>> It is recommended to create new commits in a separate feature or topic
>> branch while using rebase to update the mainline branch. When the
>> topic branch is ready merge it into mainline. To avoid a tedious task
>> of resolving large number of conflicts at once you can merge the topic
>> branch to the mainline from time to time and switch back to the topic
>> branch to continue working on it. The entire workflow would be
>> something like::
>>
>>     $ git checkout -b issue-42  # create a new issue branch and switch to
>> it
>>         ...edit/test/commit...
>>     $ git checkout master
>>     $ git pull --rebase origin master  # update master from the upstream
>>     $ git merge issue-42
>>     $ git branch -d issue-42  # delete the topic branch
>>     $ git push origin master
>>
>> When the topic branch is deleted only the label is removed, commits
>> are stayed in the database, they are now merged into master::
>>
>>     o--o--o--o--o--M--< master - the mainline branch
>>         \         /
>>          --*--*--*             - the topic branch, now unnamed
>>
>> The topic branch is deleted to avoid cluttering branch namespace with
>> small topic branches. Information on what issue was fixed or what
>> feature was implemented should be in the commit messages.
>>
>>
>> Null-merges
>> ===========
>>
>> Git has a builtin merge strategy for what Python core developers call
>> "null-merge"::
>>
>>     $ git merge -s ours v1  # null-merge v1 into master
>>
>>
>> Advanced configuration
>> ======================
>>
>> Line endings
>> ------------
>>
>> Git has builtin mechanisms to handle line endings between platforms
>> with different end-of-line styles. To allow git to do CRLF conversion
>> assign ``text`` attribute to files using `.gitattributes
>> <https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html>`_.
>> For files that have to have specific line endings assign ``eol``
>> attribute. For binary files the attribute is, naturally, ``binary``.
>>
>> For example::
>>
>>     $ cat .gitattributes
>>     *.py text
>>     *.txt text
>>     *.png binary
>>     /readme.txt eol=CRLF
>>
>> To check what attributes git uses for files use ``git check-attr``
>> command. For example::
>>
>> $ git check-attr -a -- \*.py
>>
>>
>> Advanced topics
>> ===============
>>
>> Staging area
>> ------------
>>
>> Staging area aka index aka cache is a distinguishing feature of git.
>> Staging area is where git collects patches before committing them.
>> Separation between collecting patches and commit phases provides a
>> very useful feature of git: you can review collected patches before
>> commit and even edit them - remove some hunks, add new hunks and
>> review again.
>>
>> To add files to the index use ``git add``. Collecting patches before
>> committing means you need to do that for every change, not only to add
>> new (untracked) files. To simplify committing in case you just want to
>> commit everything without reviewing run ``git commit --all`` (or just
>> ``-a``) - the command adds every changed tracked file to the index and
>> then commit. To commit a file or files regardless of patches collected
>> in the index run ``git commit [--only|-o] -- $FILE...``.
>>
>> To add hunks of patches to the index use ``git add --patch`` (or just
>> ``-p``). To remove collected files from the index use ``git reset HEAD
>> -- $FILE...`` To add/inspect/remove collected hunks use ``git add
>> --interactive`` (``-i``).
>>
>> To see the diff between the index and the last commit (i.e., collected
>> patches) use ``git diff --cached``. To see the diff between the
>> working tree and the index (i.e., uncollected patches) use just ``git
>> diff``. To see the diff between the working tree and the last commit
>> (i.e., both collected and uncollected patches) run ``git diff HEAD``.
>>
>> See `WhatIsTheIndex
>> <https://git.wiki.kernel.org/index.php/WhatIsTheIndex>`_ and
>> `IndexCommandQuickref
>> <https://git.wiki.kernel.org/index.php/IndexCommandQuickref>`_ in Git
>> Wiki.
>>
>>
>> ReReRe
>> ======
>>
>> Rerere is a mechanism that helps to resolve repeated merge conflicts.
>> The most frequent source of recurring merge conflicts are topic
>> branches that are merged into mainline and then the merge commits are
>> removed; that's often performed to test the topic branches and train
>> rerere; merge commits are removed to have clean linear history and
>> finish the topic branch with only one last merge commit.
>>
>> Rerere works by remembering the states of tree before and after a
>> successful commit. That way rerere can automatically resolve conflicts
>> if they appear in the same files.
>>
>> Rerere can be used manually with ``git rerere`` command but most often
>> it's used automatically. Enable rerere with these commands in a
>> working tree::
>>
>>     $ git config rerere.enabled true
>>     $ git config rerere.autoupdate true
>>
>> You don't need to turn rerere on globally - you don't want rerere in
>> bare repositories or single-branche repositories; you only need rerere
>> in repos where you often perform merges and resolve merge conflicts.
>>
>> See `Rerere <https://git-scm.com/book/en/Git-Tools-Rerere>`_ in The
>> Book.
>>
>>
>> Database maintenance
>> ====================
>>
>> Git object database and other files/directories under ``.git`` require
>> periodic maintenance and cleanup. For example, commit editing left
>> unreferenced objects (dangling objects, in git terminology) and these
>> objects should be pruned to avoid collecting cruft in the DB. The
>> command ``git gc`` is used for maintenance. Git automatically runs
>> ``git gc --auto`` as a part of some commands to do quick maintenance.
>> Users are recommended to run ``git gc --aggressive`` from time to
>> time; ``git help gc`` recommends to run it  every few hundred
>> changesets; for more intensive projects it should be something like
>> once a week and less frequently (biweekly or monthly) for lesser
>> active projects.
>>
>> ``git gc --aggressive`` not only removes dangling objects, it also
>> repacks object database into indexed and better optimized pack(s); it
>> also packs symbolic references (branches and tags). Another way to do
>> it is to run ``git repack``.
>>
>> There is a well-known `message
>> <https://gcc.gnu.org/ml/gcc/2007-12/msg00165.html>`_ from Linus
>> Torvalds regarding "stupidity" of ``git gc --aggressive``. The message
>> can safely be ignored now. It is old and outdated, ``git gc
>> --aggressive`` became much better since that time.
>>
>> For those who still prefer ``git repack`` over ``git gc --aggressive``
>> the recommended parameters are ``git repack -a -d -f --depth=20
>> --window=250``. See `this detailed experiment
>> <http://vcscompare.blogspot.ru/2008/06/git-repack-parameters.html>`_
>> for explanation of the effects of these parameters.
>>
>> From time to time run ``git fsck [--strict]`` to verify integrity of
>> the database. ``git fsck`` may produce a list of dangling objects;
>> that's not an error, just a reminder to perform regular maintenance.
>>
>>
>> Tips and tricks
>> ===============
>>
>> Command-line options and arguments
>> ----------------------------------
>>
>> `git help cli
>> <https://www.kernel.org/pub/software/scm/git/docs/gitcli.html>`_
>> recommends not to combine short options/flags. Most of the times
>> combining works: ``git commit -av`` works perfectly, but there are
>> situations when it doesn't. E.g., ``git log -p -5`` cannot be combined
>> as ``git log -p5``.
>>
>> Some options have arguments, some even have default arguments. In that
>> case the argument for such option must be spelled in a sticky way:
>> ``-Oarg``, never ``-O arg`` because for an option that has a default
>> argument the latter means "use default value for option ``-O`` and
>> pass ``arg`` further to the option parser". For example, ``git grep``
>> has an option ``-O`` that passes a list of names of the found files to
>> a program; default program for ``-O`` is a pager (usually ``less``),
>> but you can use your editor::
>>
>>     $ git grep -Ovim # but not -O vim
>>
>> BTW, if git is instructed to use ``less`` as the pager (i.e., if pager
>> is not configured in git at all it uses ``less`` by default, or if it
>> gets ``less`` from GIT_PAGER or PAGER environment variables, or if it
>> was configured with ``git config --global core.pager less``, or
>> ``less`` is used in the command ``git grep -Oless``) ``git grep``
>> passes ``+/$pattern`` option to ``less`` which is quite convenient.
>> Unfortunately, ``git grep`` doesn't pass the pattern if the pager is
>> not exactly ``less``, even if it's ``less`` with parameters (something
>> like ``git config --global core.pager less -FRSXgimq``); fortunately,
>> ``git grep -Oless`` always passes the pattern.
>>
>>
>> bash/zsh completion
>> -------------------
>>
>> It's a bit hard to type ``git rebase --interactive --preserve-merges
>> HEAD~5`` manually even for those who are happy to use command-line,
>> and this is where shell completion is of great help. Bash/zsh come
>> with programmable completion, often automatically installed and
>> enabled, so if you have bash/zsh and git installed, chances are you
>> are already done - just go and use it at the command-line.
>>
>> If you don't have necessary bits installed, install and enable
>> bash_completion package. If you want to upgrade your git completion to
>> the latest and greatest download necessary file from `git contrib
>> <https://git.kernel.org/cgit/git/git.git/tree/contrib/completion>`_.
>>
>> Git-for-windows comes with git-bash for which bash completion is
>> installed and enabled.
>>
>>
>> bash/zsh prompt
>> ---------------
>>
>> For command-line lovers shell prompt can carry a lot of useful
>> information. To include git information in the prompt use
>> `git-prompt.sh
>> <
>> https://git.kernel.org/cgit/git/git.git/tree/contrib/completion/git-prompt.sh
>> >`_.
>> Read the detailed instructions in the file.
>>
>> Search the Net for "git prompt" to find other prompt variants.
>>
>>
>> git on server
>> =============
>>
>> The simplest way to publish a repository or a group of repositories is
>> ``git daemon``. The daemon provides anonymous access, by default it is
>> read-only. The repositories are accessible by git protocol (git://
>> URLs). Write access can be enabled but the protocol lacks any
>> authentication means, so it should be enabled only within a trusted
>> LAN. See ``git help daemon`` for details.
>>
>> Git over ssh provides authentication and repo-level authorisation as
>> repositories can be made user- or group-writeable (see parameter
>> ``core.sharedRepository`` in ``git help config``). If that's too
>> permissive or too restrictive for some project's needs there is a
>> wrapper `gitolite <http://gitolite.com/gitolite/index.html>`_ that can
>> be configured to allow access with great granularity; gitolite is
>> written in Perl and has a lot of documentation.
>>
>> Web interface to browse repositories can be created using `gitweb
>> <https://git.kernel.org/cgit/git/git.git/tree/gitweb>`_ or `cgit
>> <http://git.zx2c4.com/cgit/about/>`_. Both are CGI scripts (written in
>> Perl and C). In addition to web interface both provide read-only dumb
>> http access for git (http(s):// URLs).
>>
>> There are also more advanced web-based development environments that
>> include ability to manage users, groups and projects; private,
>> group-accessible and public repositories; they often include issue
>> trackers, wiki pages, pull requests and other tools for development
>> and communication. Among these environments are `Kallithea
>> <https://kallithea-scm.org/>`_ and `pagure <https://pagure.io/>`_,
>> both are written in Python; pagure was written by Fedora developers
>> and is being used to develop some Fedora projects. `Gogs
>> <http://gogs.io/>`_ is written in Go; there is a fork `Gitea
>> <http://gitea.io/>`_.
>>
>> And last but not least, `Gitlab <https://about.gitlab.com/>`_. It's
>> perhaps the most advanced web-based development environment for git.
>> Written in Ruby, community edition is free and open source (MIT
>> license).
>>
>>
>> From Mercurial to git
>> =====================
>>
>> There are many tools to convert Mercurial repositories to git. The
>> most famous are, probably, `hg-git <https://hg-git.github.io/>`_ and
>> `fast-export <http://repo.or.cz/w/fast-export.git>`_ (many years ago
>> it was known under the name ``hg2git``).
>>
>> But a better tool, perhaps the best, is `git-remote-hg
>> <https://github.com/felipec/git-remote-hg>`_. It provides transparent
>> bidirectional (pull and push) access to Mercurial repositories from
>> git. Its author wrote a `comparison of alternatives
>> <
>> https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives
>> >`_
>> that seems to be mostly objective.
>>
>> To use git-remote-hg, install or clone it, add to your PATH (or copy
>> script ``git-remote-hg`` to a directory that's already in PATH) and
>> prepend ``hg::`` to Mercurial URLs. For example::
>>
>>     $ git clone https://github.com/felipec/git-remote-hg.git
>>     $ PATH=$PATH:"`pwd`"/git-remote-hg
>>     $ git clone hg::https://hg.python.org/peps/ PEPs
>>
>> To work with the repository just use regular git commands including
>> ``git fetch/pull/push``.
>>
>> To start converting your Mercurial habits to git see the page
>> `Mercurial for Git users
>> <https://mercurial.selenic.com/wiki/GitConcepts>`_ at Mercurial wiki.
>> At the second half of the page there is a table that lists
>> corresponding Mercurial and git commands. Should work perfectly in
>> both directions.
>>
>>
>> Copyright
>> =========
>>
>> This document has been placed in the public domain.
>>
>>
>>
>> ..
>>    Local Variables:
>>    mode: indented-text
>>    indent-tabs-mode: nil
>>    sentence-end-double-space: t
>>    fill-column: 70
>>    coding: utf-8
>>    End:
>>    vim: set fenc=us-ascii tw=70 :
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150912/19c9ba08/attachment-0001.html>

From phd at phdru.name  Sat Sep 12 18:28:03 2015
From: phd at phdru.name (Oleg Broytman)
Date: Sat, 12 Sep 2015 18:28:03 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAP1=2W6WZ94C_r28C5mNev53USFN3=RRz-f594Ucr8Nvv8b87A@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <CAP1=2W6WZ94C_r28C5mNev53USFN3=RRz-f594Ucr8Nvv8b87A@mail.gmail.com>
Message-ID: <20150912162803.GA17470@phdru.name>

Hi! I will add the URL with the following paragraph:

Python Developer's Guide also has a chapter `Mercurial for git
developers <https://docs.python.org/devguide/gitdevs.html>`_ that
documents a few differences between git and hg.

   Thanks!

On Sat, Sep 12, 2015 at 03:12:13PM +0000, Brett Cannon <brett at python.org> wrote:
> I have not had a chance to read Oleg's PEP, but the devguide has the
> reverse docs at https://docs.python.org/devguide/gitdevs.html so we have
> the VCS docs down pat. :)
> 
> On Sat, Sep 12, 2015, 06:59 Oleg Broytman <phd at phdru.name> wrote:
> > PEP: XXX
> > Title: Collecting information about git

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From phd at phdru.name  Sat Sep 12 18:28:53 2015
From: phd at phdru.name (Oleg Broytman)
Date: Sat, 12 Sep 2015 18:28:53 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAP7+vJ+NH4r=ET8+SjhAqgKhQO=YeAjjsUShHXNjwNXq2b7AAA@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <CAP1=2W6WZ94C_r28C5mNev53USFN3=RRz-f594Ucr8Nvv8b87A@mail.gmail.com>
 <CAP7+vJ+NH4r=ET8+SjhAqgKhQO=YeAjjsUShHXNjwNXq2b7AAA@mail.gmail.com>
Message-ID: <20150912162853.GB17470@phdru.name>

On Sat, Sep 12, 2015 at 08:29:10AM -0700, Guido van Rossum <guido at python.org> wrote:
> I have only skimmed the first half but it looks really good.

   Thank you!

> On Sat, Sep 12, 2015 at 8:12 AM, Brett Cannon <brett at python.org> wrote:
> 
> > I have not had a chance to read Oleg's PEP, but the devguide has the
> > reverse docs at https://docs.python.org/devguide/gitdevs.html so we have
> > the VCS docs down pat. :)
> >
> > On Sat, Sep 12, 2015, 06:59 Oleg Broytman <phd at phdru.name> wrote:
> >
> >> PEP: XXX
> >> Title: Collecting information about git

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From alexander.belopolsky at gmail.com  Sat Sep 12 19:04:05 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Sat, 12 Sep 2015 13:04:05 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <mt0cnj$b5$1@ger.gmane.org>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <mt0cnj$b5$1@ger.gmane.org>
Message-ID: <CAP7h-xbQjNGhh3q0+WZQg6nyONhz4uLHHZ98r9hNHcFW8-UQsQ@mail.gmail.com>

On Sat, Sep 12, 2015 at 1:20 AM, Terry Reedy <tjreedy at udel.edu> wrote:

>  A mathematician has no problem with 'a'+'b' != 'b'+'a'.


I doubt it.  A binary operation denoted + (and called addition) is almost
universally a commutative operation.  A non-commutative binary operation is
usually denoted * (and called multiplication).


>   After closure,


Do you refer to "set closure" operation [1] here?  I am not sure why it is
relevant nor why it is "basic."


> associativity is the most 'basic' operation, but non-associative
> operations are studied.
>

I think you have missed the words "property of" before "operation" above.
 "Closure", "commutativity", "associativity", etc. are properties of
operations, not operations.


>
> The equality relation, mapping pairs of members of a set to True or False
> is a different matter.  Being an equivalence relation is fundamental to
> both normal logic, algebraic proofs, and the definition of sets.


Agree, and we have a solution for PEP 495 which preserves == as and
equivalence (symmetric, reflexive and transitive) relationship.


>
> Datetime members, are rather unusual beasts. They are triples consisting
> of a member of a discrete sequence (with some odd gaps),


I assume you are using a word "member" to refer to class instances.  There
are no gaps in datetimes: there are instances that don't correspond to any
valid local time and (pre-PEP 495) there are local times that don't
correspond to any instances with a given tzinfo.  The unrepresentable times
can still be represented using a different tzinfo.   PEP 495 adds a way to
represent all times using instances with any tzinfo, but on the flip side
adds many more instances that are not "canonical" representations (e.g.
fold=1 instances for regular times.)


> a tz tag, and a 0/1 fold tag. The tz tags divide datetimes into
> equivalence classes.


That I don't understand.  Local t and u = t.astimezone(UTC) are equal (t ==
u evaluates to True), so u and t belong to the same equivalence class.


> The '-' operation is also unusual in being defined differently for pairs
> in the same or different equivalence classes.


I am not concerned about '-'.  My main concern is about order operations.
I am happy with the solution I have for ==, but I am still struggling with
the non-transitivity of <.

Comparison operations are special because they are used implicitly in other
operations.  The < operator is used implicitly in bisect.  If it does not
satisfy the (partial?) order properties, bisect may enter an infinite loop.

[1]: http://mathworld.wolfram.com/SetClosure.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150912/3755b82e/attachment.html>

From pje at telecommunity.com  Sat Sep 12 20:02:15 2015
From: pje at telecommunity.com (PJ Eby)
Date: Sat, 12 Sep 2015 14:02:15 -0400
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150912135451.GA13004@phdru.name>
References: <20150912135451.GA13004@phdru.name>
Message-ID: <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>

On Sat, Sep 12, 2015 at 9:54 AM, Oleg Broytman <phd at phdru.name> wrote:
> The plan is to extend the PEP in the future collecting information
> about equivalence of Mercurial and git scenarios to help migrating
> Python development from Mercurial to git.

I couldn't find any previous discussion about this, but I figure I
should mention:

If the motivation here is to get away from the often-awful bitbucket
to the friendlier and more-popular Github, then it might be useful to
know that hg-git works beautifully with Github.  I have over a dozen
open source projects on Github that I manage entirely using hg command
lines without having yet touched git at all.  Even the forks and pull
requests I've done of others' projects on Github worked just fine, so
long as I remember to use hg bookmarks instead of hg branches.

It's possible there are things you can't do with Mercurial on Github,
but I haven't encountered one thus far.

From phd at phdru.name  Sat Sep 12 20:42:31 2015
From: phd at phdru.name (Oleg Broytman)
Date: Sat, 12 Sep 2015 20:42:31 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
Message-ID: <20150912184231.GA21426@phdru.name>

On Sat, Sep 12, 2015 at 02:02:15PM -0400, PJ Eby <pje at telecommunity.com> wrote:
> On Sat, Sep 12, 2015 at 9:54 AM, Oleg Broytman <phd at phdru.name> wrote:
> > The plan is to extend the PEP in the future collecting information
> > about equivalence of Mercurial and git scenarios to help migrating
> > Python development from Mercurial to git.
> 
> I couldn't find any previous discussion about this, but I figure I
> should mention:
> 
> If the motivation here is to get away from the often-awful bitbucket
> to the friendlier and more-popular Github, then it might be useful to
> know that hg-git works beautifully with Github.  I have over a dozen
> open source projects on Github that I manage entirely using hg command
> lines without having yet touched git at all.  Even the forks and pull
> requests I've done of others' projects on Github worked just fine, so
> long as I remember to use hg bookmarks instead of hg branches.
> 
> It's possible there are things you can't do with Mercurial on Github,
> but I haven't encountered one thus far.

   My motivation is to help people switch from hg to git without caring
of any particular hosting. Actually I prefer Python development to use
self-hosting with Kalithea, pagure or gitlab at git.python.org (with
official, semi-official and unofficial mirrors all over the Net).

   There are too many things that I personally can do with git but can't
do with hg. Because of that I switched all my development from hg to git
and I am willing to help those who want to follow.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From travis at continuum.io  Sat Sep 12 23:51:51 2015
From: travis at continuum.io (Travis Oliphant)
Date: Sat, 12 Sep 2015 16:51:51 -0500
Subject: [Python-Dev] Looking for a developer who will work with me for at
 least 6 months to fix NumPy's dtype system.
Message-ID: <CAMcnTE7TuvRsoWw2wYfxvvSv-VzXJ0--bKNSAcpruHEvn2r_ZA@mail.gmail.com>

Hi all,

Apologies for cross-posting, but I need to get the word out and twitter
doesn't provide enough explanation.

I've been working on a second edition of my "Guide to NumPy" book.   It's
been a time-pressured activity, but it's helped me put more meat around my
ideas for how to fix NumPy's dtype system -- which I've been contemplating
off an on for 8 years.

I'm pretty sure I know exactly how to do it --- in a way that fits more
cleanly into Python.  It will take 3-6 months and will have residual
efforts needed that will last another 6 months --- making more types
available with NumPy, improving calculations etc.

This work will be done completely in public view and allow for public
comment.   It will not solve *all* of NumPy's problems, but it will put
NumPy's dtype system on the footing it in retrospect should have been put
on in the first place (if I had known then what I know now).

It won't be a grandiose rewrite.   It will be a pretty surgical fix to a
few key places in the code. However, it will break the ABI and require
recompilation of NumPy extensions (and so would need to be called NumPy
2.0).   This is unavoidable, but I don't see any problem with breaking the
ABI today given how easy it is to get distributions of Python these days
from a variety of sources (including using conda --- but not only using
conda).

For those that remember what happened in Python dev land, the changes will
be similar to when Guido changed Python 1.5.2 to Python 2.0.

I can mentor and work closely with someone who will work on this and we
will invite full participation and feedback from whomever in the community
also wants to participate --- but I can't do it myself full time (and it
needs someone full time+).   Fortunately, I can pay someone to do it if
they are willing to commit at least 6 months (it is not required to work at
Continuum for this, but you can have a job at Continuum if you want one).

I'm only looking for people who have enough experience with C or preferably
the Python C-API. You also have to *want* to work on this.   You need to be
willing to work with me on the project directly and work to have a
mind-meld with my ideas which will undoubtedly give rise to additional
perspectives and ideas for later work for you.

When I wrote NumPy 1.0, I put in 80+ hour weeks for about 6 months or more
and then 60+ weeks for another year.  I was pretty obsessed with it.   This
won't need quite that effort, but it will need something like it.     Being
able to move to Austin is a plus but not required.   I can sponsor a visa
for the right candidate as well (though it's not guaranteed you will get
one with the immigration policies what they are).

This is a labor of love for so many of us and my desire to help the dtype
situation in NumPy comes from the same space that my desire to work on
NumPy in the first place came.      I will be interviewing people to work
on this as not everyone who may want to will really be qualified to do it
--- especially with so many people writing Cython these days instead of
good-ole C-API code :-)

Feel free to spread the news to anyone you can.   I won't say more until
I've found someone to work with me on this --- because I won't have the
time to follow-up with any questions or comments.    Even if I can't find
someone I will publish the ideas --- but that also takes time and effort
that is in short supply for me right now.

If there is someone willing to fund this work, please let me know as well
-- that could free up more of my time.

Best,

-Travis


-- 

*Travis Oliphant*
*Co-founder and CEO*


@teoliphant
512-222-5440
http://www.continuum.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150912/ec387993/attachment.html>

From timothy.c.delaney at gmail.com  Sun Sep 13 01:14:58 2015
From: timothy.c.delaney at gmail.com (Tim Delaney)
Date: Sun, 13 Sep 2015 09:14:58 +1000
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150912184231.GA21426@phdru.name>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
Message-ID: <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>

On 13 September 2015 at 04:42, Oleg Broytman <phd at phdru.name> wrote:

>    There are too many things that I personally can do with git but can't
> do with hg. Because of that I switched all my development from hg to git
> and I am willing to help those who want to follow.
>

Slightly off-topic, but personally I'd love to know what those are. I've
yet to find anything in Git that I haven't been able to do at least as well
with Mercurial (or an extension), and there are things Mercurial
supports that I use extensively (in particular named branches and phases)
where the concept doesn't even exist in Git.

I switched all of my development to Mercurial, and use hg-git and
hgsubversion when I need to interact with those systems.

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150913/8372e5af/attachment.html>

From rymg19 at gmail.com  Sun Sep 13 01:26:13 2015
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Sat, 12 Sep 2015 18:26:13 -0500
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
Message-ID: <00E8132C-2621-4888-8B84-1ABBD98BC322@gmail.com>



On September 12, 2015 6:14:58 PM CDT, Tim Delaney <timothy.c.delaney at gmail.com> wrote:
>On 13 September 2015 at 04:42, Oleg Broytman <phd at phdru.name> wrote:
>
>>    There are too many things that I personally can do with git but
>can't
>> do with hg. Because of that I switched all my development from hg to
>git
>> and I am willing to help those who want to follow.
>>
>
>Slightly off-topic, but personally I'd love to know what those are.
>I've
>yet to find anything in Git that I haven't been able to do at least as
>well
>with Mercurial (or an extension), and there are things Mercurial
>supports that I use extensively (in particular named branches and
>phases)
>where the concept doesn't even exist in Git.
>
>I switched all of my development to Mercurial, and use hg-git and
>hgsubversion when I need to interact with those systems.

...speed??

Seriously; just try pulling the entire CPython repo. Then try again with the GitHub mirror.

I love Mercurial's CLI. But, every time I use it, I end up feeling like I'm waiting forever.

Git's CLI is really weird, but it's surprisingly powerful and flexible once you get the hang of it (which admittedly might take a while!).

>
>Tim Delaney
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Python-Dev mailing list
>Python-Dev at python.org
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

From travis at continuum.io  Sun Sep 13 00:35:52 2015
From: travis at continuum.io (Travis Oliphant)
Date: Sat, 12 Sep 2015 17:35:52 -0500
Subject: [Python-Dev] The changes I am planning to NumPy I'd like to make
 only available on Python 3
Message-ID: <CAMcnTE7MC+Ukk0pD5-30L3_hyxBkQv_F+sdT8VGqD++SCR3DfQ@mail.gmail.com>

If it helps anyone in their interest level.   My intention would be to make
these changes to NumPy only available on Python 3 as a way to help continue
adoption of Python 3.

-Travis


-- 

*Travis Oliphant*
*Co-founder and CEO*


@teoliphant
512-222-5440
http://www.continuum.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150912/a6818452/attachment-0001.html>

From tjreedy at udel.edu  Sun Sep 13 02:49:12 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Sep 2015 20:49:12 -0400
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <CAP7h-xbQjNGhh3q0+WZQg6nyONhz4uLHHZ98r9hNHcFW8-UQsQ@mail.gmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <mt0cnj$b5$1@ger.gmane.org>
 <CAP7h-xbQjNGhh3q0+WZQg6nyONhz4uLHHZ98r9hNHcFW8-UQsQ@mail.gmail.com>
Message-ID: <mt2h74$s7d$1@ger.gmane.org>

On 9/12/2015 1:04 PM, Alexander Belopolsky wrote:
>
>
> On Sat, Sep 12, 2015 at 1:20 AM, Terry Reedy <tjreedy at udel.edu
> <mailto:tjreedy at udel.edu>> wrote:
>
>       A mathematician has no problem with 'a'+'b' != 'b'+'a'.
>
> I doubt it.  A binary operation denoted + (and called addition) is
> almost universally a commutative operation.  A non-commutative binary
> operation is usually denoted * (and called multiplication).

I am aware of the single-operation group theory convention, but the 
context was sequence concatenation and scalar multiplication, where '*' 
is repeated '+'.  But these details are not directly relevant to DateTimes.

>        After closure,

I perhaps should have said 'completeness'.  In any case, I was referring 
to 'a op b' existing for all a and b in the set.

> Agree, and we have a solution for PEP 495 which preserves == as and
> equivalence (symmetric, reflexive and transitive) relationship.
>
>     Datetime members, are rather unusual beasts. They are triples
>     consisting of a member of a discrete sequence (with some odd gaps),

Your correction, summarized, is that there are no gaps, so the set is 
simpler than I thought. Skipping on to the heart of the matter.

> I am not concerned about '-'.  My main concern is about order
> operations.

Is not '<' defined, in the obvious way, in terms of '-' and the sign of 
the resul?

>  I am happy with the solution I have for ==, but I am still
> struggling with the non-transitivity of <.

I am guessing that the 'struggle' is at least partly this: "Is 
non-transitivity of < necessary given other constraints, including 
back-compatibility, or is there another solution possible that would 
also be <-transitive?"

> Comparison operations are special because they are used implicitly in
> other operations.  The < operator is used implicitly in bisect.  If it
> does not satisfy the (partial?) order properties, bisect may enter an
> infinite loop.

and, if we are stuck with <-intransitivity, what do we do? If 
back-compatibility allowed, I might suggest defining 'lt' or 'less' 
rather than '__lt__' so that sort and bisect don't work with DateTimes. 
Then document that the function is not transitive.

-- 
Terry Jan Reedy


From phd at phdru.name  Sun Sep 13 04:31:40 2015
From: phd at phdru.name (Oleg Broytman)
Date: Sun, 13 Sep 2015 04:31:40 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
Message-ID: <20150913023140.GA31544@phdru.name>

Hi!

On Sun, Sep 13, 2015 at 09:14:58AM +1000, Tim Delaney <timothy.c.delaney at gmail.com> wrote:
> On 13 September 2015 at 04:42, Oleg Broytman <phd at phdru.name> wrote:
> 
> >    There are too many things that I personally can do with git but can't
> > do with hg. Because of that I switched all my development from hg to git
> > and I am willing to help those who want to follow.
> 
> Slightly off-topic, but personally I'd love to know what those are. I've
> yet to find anything in Git that I haven't been able to do at least as well
> with Mercurial (or an extension), and there are things Mercurial
> supports that I use extensively (in particular named branches and phases)
> where the concept doesn't even exist in Git.

   I started to learn Mercurial at the end of 2008 and made the first
commit at January of 2009. Global named branches was one of the
(mis)features that I disliked from the very beginning. One top-level
.hgignore file instead of proper per-directory ignore files. Two-commits
tagging -- the tag is committed in a different commit from the commit it
tags. Repositories to pull from and push to must be related -- they must
be (in)direct clones of one root repo. There were also things that I
wanted but didn't really understand what I wanted -- I switched to
Mercurial from CVS and SVN and didn't fully understand the real power of
distributed VCS.
   I was the only developer of the project, the project was not very
big:
   $ du -sh third-party .hg .
   2.4M  third-party
   2.2M  .hg
   6.2M  .
and didn't require intensive development so instead of named branches
I decided to go with two separate clones, old and new, and use ``hg
transplant`` to copy occasional commits from the old clone to the new
one.

   Somewhere at the end of 2011 my management moved me to a different
project. They use git for development so I started to learn git (i.e.,
Mercurial had 3 years start). I am a slow thinker so it took me about a
year to master git, another year to appreciate it and at the third year
I fell in love with it. The project is much bigger:
   $ du -sh libs/third-party third-party .git .
   24M   libs/third-party
   46M   third-party
   48M   .git
   20M   .
and development is much more intensive -- there are many developers,
many clones, many subprojects, many submodules, third-party libraries
and programs, many branches with merges.
   Git fixed all the problems I had with hg. Its branching model suits
my understanding of branches much better. With git we can have
per-directory .gitignore and .gitattributes. Lightweight and annotated
tags point exactly to the commits they tag. Ability to pull and push
between unrelated repos.
   I learned commit editing and found that it was the thing I wanted so
badly in hg. When I started Mercurial was at version 1.7 and there was
no commit editing at all; there was ``hg rollback`` but it only could
undo one transaction. Later Mercurial learned commit editing,
unwillingly perhaps, but git is still better at it: ``git add -p``
allows me to review and edit patches before commit while ``hg record``
commits immediately.
   Git is powerful. Even now, at version 3.1 ``hg help log`` lists about
a dozen of options; ``git help log`` gives me about 60 pages of
documentation. I do not use all of them but I very much like ``git log
--decorate``, ``--graph``, ``--grep=`` (and all related search options,
especially ``-G``), ``--pretty``, ``--oneline``, ``--encoding=`` (I
often use koi8-r instead of utf-8), ``--color`` and ``--word-diff``. I
like ``git grep``, especially in the form ``git grep -Ovim``. I don't
know what are the equivalent commands for ``git commit -c HEAD~`` or
``git diff --name-only``.
   Git has a lot of good documentation.

   A few months ago I converted those two clones from hg to git using
git-remote-hg, merged them into one repository as branches, did a
null-merge and from that point I have been using proper branches and
merges for development. I stopped using Mercurial and I think I will not
come back.

   As I stopped using Mercurial I do not understand what phases are.
they are phases of commit according to what? To the origin (let me
borrow the word from git terminology)?

   Mercurial, for sure, has some advantages. It is written in Python.
That's important. That's important for ideological reasons. That's also
important because hg runs natively under Windows, it even has code for
working with case-insensitive filesystems.
   There are Mercurial Queues.
   There are also small advantages like better polished command-line
interface and ability to shorten command names and options to a unique
prefix.

> Tim Delaney

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From fijall at gmail.com  Sun Sep 13 09:49:23 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 13 Sep 2015 09:49:23 +0200
Subject: [Python-Dev] semantics of subclassing things from itertools
In-Reply-To: <E4833933-12FE-4ADC-9604-134FE953E9A8@gmail.com>
References: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
 <E4833933-12FE-4ADC-9604-134FE953E9A8@gmail.com>
Message-ID: <CAK5idxRnsdQ=p_S32R1BoX9OLiRiyhP3xR81nr6Utoma1gGpww@mail.gmail.com>

On Fri, Sep 11, 2015 at 1:48 AM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
>> On Sep 10, 2015, at 3:23 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>
>> I would like to know what are the semantics if you subclass something
>> from itertools (e.g. islice).
>>
>> Right now it's allowed and people do it, which is why the
>> documentation is incorrect. It states "equivalent to: a function-or a
>> generator", but you can't subclass whatever it is equivalent to, which
>> is why in PyPy we're unable to make it work in pure python.
>>
>> I would like some clarification on that.
>
> The docs should say "roughly equivalent to" not "exactly equivalent to".
> The intended purpose of the examples in the itertools docs is to use
> pure python code to help people better understand each tool.  It is not
> is intended to dictate that tool x is a generator or is a function.
>
> The intended semantics are that the itertools are classes (not functions
> and not generators).  They are intended to be sub-classable (that is
> why they have Py_TPFLAGS_BASETYPE defined).

Ok, so what's completely missing from the documentation is what *are*
the semantics of subclasses of those classes? Can you override any
magic methods? Can you override next (which is or isn't a magic method
depending how you look)? Etc.

The documentation on this is completely missing and it's left guessing
with "whatever cpython happens to be doing".

From lac at openend.se  Sun Sep 13 11:03:37 2015
From: lac at openend.se (Laura Creighton)
Date: Sun, 13 Sep 2015 11:03:37 +0200
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
	is ready for pronouncement
In-Reply-To: <mt2h74$s7d$1@ger.gmane.org>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <mt0cnj$b5$1@ger.gmane.org>
 <CAP7h-xbQjNGhh3q0+WZQg6nyONhz4uLHHZ98r9hNHcFW8-UQsQ@mail.gmail.com>
 <mt2h74$s7d$1@ger.gmane.org>
Message-ID: <201509130903.t8D93bGc019600@fido.openend.se>

In a message of Sat, 12 Sep 2015 20:49:12 -0400, Terry Reedy writes:
>and, if we are stuck with <-intransitivity, what do we do? If 
>back-compatibility allowed, I might suggest defining 'lt' or 'less' 
>rather than '__lt__' so that sort and bisect don't work with DateTimes. 
>Then document that the function is not transitive.

I think it would be better to document what you are supposed to
do if you have a list of DateTimes and want to sort them, as a
way to get a list of times sorted from the earliest to the latest.

Laura


From tds333 at gmail.com  Sun Sep 13 15:58:32 2015
From: tds333 at gmail.com (tds333 at gmail.com)
Date: Sun, 13 Sep 2015 15:58:32 +0200
Subject: [Python-Dev] Windows x86-64 embeddable zip file, Feedback
Message-ID: <55F58108.5010503@gmail.com>

Hi,

had some time to test the new distributed stuff for Windows
especially the embeddable zip.

Thanks for this special distribution, it is very useful to generate
standalone Python distributions and software based on Python.
Very good work.

I detected two minor issues only affecting size, opened tickets for them:

http://bugs.python.org/issue25085
Windows x86-64 embeddable zip file contains test directorys


http://bugs.python.org/issue25086
Windows x86-64 embeddable zip file, lot of big EXE files in distuils


Think this can be an improvement in size, targeting for Python 3.5.1.


Regards,

Wolfgang

From larry at hastings.org  Sun Sep 13 16:28:34 2015
From: larry at hastings.org (Larry Hastings)
Date: Sun, 13 Sep 2015 15:28:34 +0100
Subject: [Python-Dev] [RELEASED] Python 3.5.0 is now available
Message-ID: <55F58812.1030001@hastings.org>



On behalf of the Python development community and the Python 3.5 release 
team, I'm proud to announce the availability of Python 3.5.0.  Python 
3.5.0 is the newest version of the Python language, and it contains many 
exciting new features and optimizations.


You can read all about what's new in Python 3.5.0 here:

    https://docs.python.org/3.5/whatsnew/3.5.html


And you can download Python 3.5.0 here:

    https://www.python.org/downloads/release/python-350/

Windows and Mac users: please read the important platform-specific 
"Notes on this release" section near the end of that page.


We hope you enjoy Python 3.5.0!


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150913/c07351b2/attachment.html>

From rosuav at gmail.com  Sun Sep 13 17:05:47 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Mon, 14 Sep 2015 01:05:47 +1000
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <201509130903.t8D93bGc019600@fido.openend.se>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <mt0cnj$b5$1@ger.gmane.org>
 <CAP7h-xbQjNGhh3q0+WZQg6nyONhz4uLHHZ98r9hNHcFW8-UQsQ@mail.gmail.com>
 <mt2h74$s7d$1@ger.gmane.org>
 <201509130903.t8D93bGc019600@fido.openend.se>
Message-ID: <CAPTjJmqQ8=j8Z+7m1LoMv1G4mtvKi7hAo1YtC9ouVzno9WKRxA@mail.gmail.com>

On Sun, Sep 13, 2015 at 7:03 PM, Laura Creighton <lac at openend.se> wrote:
> In a message of Sat, 12 Sep 2015 20:49:12 -0400, Terry Reedy writes:
>>and, if we are stuck with <-intransitivity, what do we do? If
>>back-compatibility allowed, I might suggest defining 'lt' or 'less'
>>rather than '__lt__' so that sort and bisect don't work with DateTimes.
>>Then document that the function is not transitive.
>
> I think it would be better to document what you are supposed to
> do if you have a list of DateTimes and want to sort them, as a
> way to get a list of times sorted from the earliest to the latest.

What I'd like to hear (but maybe this won't be possible) would be
"less-than is transitive if and only if <X>", where <X> might be
something like "all of the datetimes are in the same timezone" or
"none of the datetimes fall within a fold" or something. That would at
least make sorting possible, but maybe with a first-pass check to
ensure transitivity.

Vain hope or plausible restriction?

ChrisA

From tim.peters at gmail.com  Sun Sep 13 17:44:13 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Sun, 13 Sep 2015 10:44:13 -0500
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <CAPTjJmqQ8=j8Z+7m1LoMv1G4mtvKi7hAo1YtC9ouVzno9WKRxA@mail.gmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <mt0cnj$b5$1@ger.gmane.org>
 <CAP7h-xbQjNGhh3q0+WZQg6nyONhz4uLHHZ98r9hNHcFW8-UQsQ@mail.gmail.com>
 <mt2h74$s7d$1@ger.gmane.org> <201509130903.t8D93bGc019600@fido.openend.se>
 <CAPTjJmqQ8=j8Z+7m1LoMv1G4mtvKi7hAo1YtC9ouVzno9WKRxA@mail.gmail.com>
Message-ID: <CAExdVNm_qnRPkNSu8Z1FyTcqTC-kQwrNzjvuWfTm-On9BYWEXQ@mail.gmail.com>

[Chris Angelico <rosuav at gmail.com>]
> What I'd like to hear (but maybe this won't be possible) would be
> "less-than is transitive if and only if <X>", where <X> might be
> something like "all of the datetimes are in the same timezone" or
> "none of the datetimes fall within a fold" or something. That would at
> least make sorting possible, but maybe with a first-pass check to
> ensure transitivity.
>
> Vain hope or plausible restriction?

Pragmatically, if someone needs to care about sorting aware datetimes
that may include times in folds, the obvious way is to convert them to
UTC first (which can be done with sort's `key=` argument).  Times in
UTC are totally ordered (essentially the same as working with
integers).

That's a sane & easy sufficient condition.  It's a waste of time to
worry about minimal necessary conditions.  "Convert to UTC' is the
obvious way to do darned near everything.  Converting to any other
fixed-offset zone would do just as well, but _that_ observation is
also a waste of time, since "convert to UTC" is just as easy ;-)

From raymond.hettinger at gmail.com  Sun Sep 13 17:46:31 2015
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sun, 13 Sep 2015 11:46:31 -0400
Subject: [Python-Dev] semantics of subclassing things from itertools
In-Reply-To: <CAK5idxRnsdQ=p_S32R1BoX9OLiRiyhP3xR81nr6Utoma1gGpww@mail.gmail.com>
References: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
 <E4833933-12FE-4ADC-9604-134FE953E9A8@gmail.com>
 <CAK5idxRnsdQ=p_S32R1BoX9OLiRiyhP3xR81nr6Utoma1gGpww@mail.gmail.com>
Message-ID: <1F7C02D0-68E2-4B89-A6FC-CC65C17A44C4@gmail.com>


> On Sep 13, 2015, at 3:49 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> 
>> The intended semantics are that the itertools are classes (not functions
>> and not generators).  They are intended to be sub-classable (that is
>> why they have Py_TPFLAGS_BASETYPE defined).
> 
> Ok, so what's completely missing from the documentation is what *are*
> the semantics of subclasses of those classes? Can you override any
> magic methods? Can you override next (which is or isn't a magic method
> depending how you look)? Etc.
> 
> The documentation on this is completely missing and it's left guessing
> with "whatever cpython happens to be doing".

The reason it is underspecified is that this avenue of development was
never explored (not thought about, planned, used, tested, or documented).
IIRC, the entire decision process for having Py_TPFLAGS_BASETYPE
boiled down to a single question:  Was there any reason to close this
door and make the itertools not subclassable?  

For something like NoneType, there was a reason to be unsubclassable;
otherwise, the default choice was to give users maximum flexibility
(the itertools were intended to be a generic set of building blocks,
forming what Guido termed an "iterator algebra"). 

As an implementor of another version of Python, you are reasonably
asking the question, what is the specification for subclassing semantics?
The answer is somewhat unsatisfying -- I don't know because I've 
never thought about it.  As far as I can tell, this question has never
come up in the 13 years of itertools existence and you may be the
first person to have ever cared about this.


Raymond

From rosuav at gmail.com  Sun Sep 13 17:47:08 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Mon, 14 Sep 2015 01:47:08 +1000
Subject: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation
 is ready for pronouncement
In-Reply-To: <CAExdVNm_qnRPkNSu8Z1FyTcqTC-kQwrNzjvuWfTm-On9BYWEXQ@mail.gmail.com>
References: <CAP7h-xZfLnq08JxaCXh7My8Q0pEcnvHGGezaOgg+v-SPY3HWfg@mail.gmail.com>
 <msvlj4$423$1@ger.gmane.org>
 <CAP7h-xavckF6tbpRGuxogKzutA2CASj=ZpjM-t1YzVb8KerK2A@mail.gmail.com>
 <mt0cnj$b5$1@ger.gmane.org>
 <CAP7h-xbQjNGhh3q0+WZQg6nyONhz4uLHHZ98r9hNHcFW8-UQsQ@mail.gmail.com>
 <mt2h74$s7d$1@ger.gmane.org>
 <201509130903.t8D93bGc019600@fido.openend.se>
 <CAPTjJmqQ8=j8Z+7m1LoMv1G4mtvKi7hAo1YtC9ouVzno9WKRxA@mail.gmail.com>
 <CAExdVNm_qnRPkNSu8Z1FyTcqTC-kQwrNzjvuWfTm-On9BYWEXQ@mail.gmail.com>
Message-ID: <CAPTjJmoMt8TTcKzfWNmAo5CaxXR4wVfSi98oNa=ZQxkMTMBN1Q@mail.gmail.com>

On Mon, Sep 14, 2015 at 1:44 AM, Tim Peters <tim.peters at gmail.com> wrote:
> That's a sane & easy sufficient condition.  It's a waste of time to
> worry about minimal necessary conditions.  "Convert to UTC' is the
> obvious way to do darned near everything.  Converting to any other
> fixed-offset zone would do just as well, but _that_ observation is
> also a waste of time, since "convert to UTC" is just as easy ;-)

So it isn't sufficient for them all to be in, say,
Australia/Melbourne, which observes DST. Fair enough. And yeah,
converting to UTC is straightforward enough.

ChrisA

From barry at python.org  Sun Sep 13 20:10:42 2015
From: barry at python.org (Barry Warsaw)
Date: Sun, 13 Sep 2015 14:10:42 -0400
Subject: [Python-Dev] PEP: Collecting information about git
References: <20150912135451.GA13004@phdru.name>
Message-ID: <20150913141042.78f2e03d@anarchist.wooz.org>

On Sep 12, 2015, at 03:54 PM, Oleg Broytman wrote:

>This Informational PEP collects information about git. There is, of course, a
>lot of documentation for git, so the PEP concentrates on more complex (and
>more related to Python development) issues, scenarios and examples.

Thanks for this Oleg.  git is popular and powerful, but with that power comes
a lot of options, command line switches, complexity, and verbose manpages.
Boiled down, you don't have to learn all of that to be effective, and you can
augment your knowledge as you go, although it's sometimes difficult to find
the exact bit of advice you're looking for.  A sprinkling of git aliases has
definitely made my life easier. :)

One of the things I think is missing from most git documentation, is an
effective workflow for handling multiple branches.  Think about the Python
case where we have the default branch for what is now going to be Python 3.6,
plus stable release branches for several older Python 3 versions, and even
Python 2.7.

Now imagine a bug fix which must be applied to many of these active branches.
There are lots of different ways to do this, but really no best practices for
how it should be done.  Do you apply the fix to the highest version branch and
then cherry pick to the older version branches?  What about if you need to
skip one of those branches?

Visually, it would be something like this:

master -> A -> B ------------->-> F -> G
                \                /
   issue1 -----> -> C -> D -> E /

releaseX.Y -> H -> I

At this point you'd like to take the commits C->E, rebase them onto I and then
commit them to the releaseX.Y branch, e.g.

releaseX.Y -> H -> I -----------------> J
                    \                  /
   issue1-X.Y -=--> -> C' -> D' -> E' /

I do this with several of my projects and personally find git cherry-pick to
be useful, but also often non-intuitive, and sometimes it just doesn't do what
I want it to do.  I haven't found a lot of really good workflow documentation
for git, so most of what I do is based on experimentation, with a healthy dose
of frustration when my expectations aren't met.

Our devguide has some good documentation on how to do this with hg, and even
though I so rarely do it (CPython being one of the only projects I use
Mercurial on), I can usually get the job done without a lot of cursing. :)

So, for this very interesting informational PEP, I'd like to see detailed
documentation on best practices for applying patches to multiple active
branches using git, in the context of CPython development.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150913/62cf901b/attachment.sig>

From phd at phdru.name  Sun Sep 13 20:58:10 2015
From: phd at phdru.name (Oleg Broytman)
Date: Sun, 13 Sep 2015 20:58:10 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150913141042.78f2e03d@anarchist.wooz.org>
References: <20150912135451.GA13004@phdru.name>
 <20150913141042.78f2e03d@anarchist.wooz.org>
Message-ID: <20150913185810.GA4908@phdru.name>

Hello!

On Sun, Sep 13, 2015 at 02:10:42PM -0400, Barry Warsaw <barry at python.org> wrote:
> One of the things I think is missing from most git documentation, is an
> effective workflow for handling multiple branches.

   Thank you for the good question! I doubt there One True Way, so the
core team will choose one of the existing ways or develop their own.

   I can recommend three sources of information. First, gitworkflows
(``git help workflows``):
https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
   The chapter "MANAGING BRANCHES" describes how the very git developers
do that and what they recommend as the best practice.

   Second, the corresponding chapters in ProGit:
https://git-scm.com/book/en/Git-Branching-Branching-Workflows
https://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project

   Both gitworkflows and The Book are linked from the PEP and I don't
think there is a need to copy texts from the docs to the PEP.

   The third source of information is not mentioned in the PEP, though.
I have to think where to put it. It is well-known git-flow article:
http://nvie.com/posts/a-successful-git-branching-model/
   It has very detaild rules on creating and managing mainline branches,
topic branches and bugfix branches. To support the flow at the software
level the author implemented ``git flow`` extension:
https://github.com/nvie/gitflow
   See an example at
http://alblue.bandlem.com/2011/11/git-tip-of-week-git-flow.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From fijall at gmail.com  Sun Sep 13 21:09:56 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 13 Sep 2015 21:09:56 +0200
Subject: [Python-Dev] semantics of subclassing things from itertools
In-Reply-To: <1F7C02D0-68E2-4B89-A6FC-CC65C17A44C4@gmail.com>
References: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
 <E4833933-12FE-4ADC-9604-134FE953E9A8@gmail.com>
 <CAK5idxRnsdQ=p_S32R1BoX9OLiRiyhP3xR81nr6Utoma1gGpww@mail.gmail.com>
 <1F7C02D0-68E2-4B89-A6FC-CC65C17A44C4@gmail.com>
Message-ID: <CAK5idxQ=tSSU6pOESK48XLFKpFAXYQqnBC5_QnEtYsMUCsEkhQ@mail.gmail.com>

On Sun, Sep 13, 2015 at 5:46 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
>> On Sep 13, 2015, at 3:49 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>
>>> The intended semantics are that the itertools are classes (not functions
>>> and not generators).  They are intended to be sub-classable (that is
>>> why they have Py_TPFLAGS_BASETYPE defined).
>>
>> Ok, so what's completely missing from the documentation is what *are*
>> the semantics of subclasses of those classes? Can you override any
>> magic methods? Can you override next (which is or isn't a magic method
>> depending how you look)? Etc.
>>
>> The documentation on this is completely missing and it's left guessing
>> with "whatever cpython happens to be doing".
>
> The reason it is underspecified is that this avenue of development was
> never explored (not thought about, planned, used, tested, or documented).
> IIRC, the entire decision process for having Py_TPFLAGS_BASETYPE
> boiled down to a single question:  Was there any reason to close this
> door and make the itertools not subclassable?
>
> For something like NoneType, there was a reason to be unsubclassable;
> otherwise, the default choice was to give users maximum flexibility
> (the itertools were intended to be a generic set of building blocks,
> forming what Guido termed an "iterator algebra").
>
> As an implementor of another version of Python, you are reasonably
> asking the question, what is the specification for subclassing semantics?
> The answer is somewhat unsatisfying -- I don't know because I've
> never thought about it.  As far as I can tell, this question has never
> come up in the 13 years of itertools existence and you may be the
> first person to have ever cared about this.
>
>
> Raymond

Well, fair enough, but the semantics of "whatever happens to happen
because we decided subclassing is a cool idea" is possibly the worst
answer to those questions. Ideally, make it non-subclassable. If you
want to have it subclassable, then please have defined semantics as
opposed to undefined.

From steve.dower at python.org  Sun Sep 13 22:23:41 2015
From: steve.dower at python.org (Steve Dower)
Date: Sun, 13 Sep 2015 13:23:41 -0700
Subject: [Python-Dev] Windows x86-64 embeddable zip file, Feedback
In-Reply-To: <55F58108.5010503@gmail.com>
References: <55F58108.5010503@gmail.com>
Message-ID: <E1ZbDoe-0006D9-Bi@se2-syd.hostedmail.net.au>

Thanks for the kind words, glad you're finding the distribution useful.

Feel free to assign me (steve.dower) to the issues. I assume they're referring to the contents of the library.zip file? In which case, you're correct, those are unnecessary. I'll take a closer look when I'm at my PC.

Cheers,
Steve

Top-posted from my Windows Phone

-----Original Message-----
From: "tds333 at gmail.com" <tds333 at gmail.com>
Sent: ?9/?13/?2015 6:59
To: "Python-Dev" <python-dev at python.org>
Subject: [Python-Dev] Windows x86-64 embeddable zip file, Feedback

Hi,

had some time to test the new distributed stuff for Windows
especially the embeddable zip.

Thanks for this special distribution, it is very useful to generate
standalone Python distributions and software based on Python.
Very good work.

I detected two minor issues only affecting size, opened tickets for them:

http://bugs.python.org/issue25085
Windows x86-64 embeddable zip file contains test directorys


http://bugs.python.org/issue25086
Windows x86-64 embeddable zip file, lot of big EXE files in distuils


Think this can be an improvement in size, targeting for Python 3.5.1.


Regards,

Wolfgang
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150913/4424d678/attachment-0001.html>

From lac at openend.se  Sun Sep 13 22:41:55 2015
From: lac at openend.se (Laura Creighton)
Date: Sun, 13 Sep 2015 22:41:55 +0200
Subject: [Python-Dev] congrats on 3.5!  Alas,
	windows 7 users are having problems installing it
Message-ID: <201509132041.t8DKftII030747@fido.openend.se>

webmaster has already heard from 4 people who cannot install it.
I sent them to the bug tracker or to python-list but they seem
not to have gone either place.  Is there some guide I should be
sending them to, 'how to debug installation problems'?

Laura


From tjreedy at udel.edu  Mon Sep 14 00:05:17 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 13 Sep 2015 18:05:17 -0400
Subject: [Python-Dev] When is 3.4.4 scheduled?
Message-ID: <mt4rvr$s9a$1@ger.gmane.org>

I could not fine '3.4.4' either in
https://www.python.org/dev/peps/pep-0429/ 3.4 schedule
or elsewhere on the site.

-- 
Terry Jan Reedy


From raymond.hettinger at gmail.com  Mon Sep 14 00:17:32 2015
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sun, 13 Sep 2015 18:17:32 -0400
Subject: [Python-Dev] semantics of subclassing things from itertools
In-Reply-To: <CAK5idxQ=tSSU6pOESK48XLFKpFAXYQqnBC5_QnEtYsMUCsEkhQ@mail.gmail.com>
References: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
 <E4833933-12FE-4ADC-9604-134FE953E9A8@gmail.com>
 <CAK5idxRnsdQ=p_S32R1BoX9OLiRiyhP3xR81nr6Utoma1gGpww@mail.gmail.com>
 <1F7C02D0-68E2-4B89-A6FC-CC65C17A44C4@gmail.com>
 <CAK5idxQ=tSSU6pOESK48XLFKpFAXYQqnBC5_QnEtYsMUCsEkhQ@mail.gmail.com>
Message-ID: <D7E9F183-1379-4902-99CA-56D0BCB4718D@gmail.com>


> On Sep 13, 2015, at 3:09 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> 
> Well, fair enough, but the semantics of "whatever happens to happen
> because we decided subclassing is a cool idea" is possibly the worst
> answer to those questions.

It's hard to read this in any way that isn't insulting.

It was subclassable because a) it was a class, 2) type/class unification was
pushing us in the direction of making builtin types more like regular classes
(which are subclassable), and 3) because it seemed potentially useful
to users (and apparently it has been because users are subclassing it).

FWIW, the code was modeled on what was done for enumerate() and
reversed() where I got a lot of coaching and review from Tim Peters,
Alex Martelli, Fredrik Lundh, and other python luminaries of the day.


> Ideally, make it non-subclassable. If you
> want to have it subclassable, then please have defined semantics as
> opposed to undefined.

No, I'm not going to change a 13 year-old API and break existing user code
just because you've gotten worked-up about it.

FWIW, the semantics wouldn't even be defined in the itertools docs.
It is properly in some section that describes what happens to any C type
that defines sets the Py_TPFLAGS_BASETYPE flag.   In general, all of
the exposed dunder methods are overridable or extendable by subclassers.


Raymond


P.S.  Threads like this are why I've developed an aversion to python-dev.
I've answered your questions with respect and candor. I've been sympathetic
to your unique needs as someone building an implementation of a language
that doesn't have a spec.  I was apologetic that the docs which have been
helpful to users weren't precise enough for your needs.   

In return, you've suggested that my first contributions to Python were 
irresponsible and based on doing whatever seemed cool.

In fact, the opposite is the case.  I spent a full summer researching how similar
tools were used in other languages and fitting them into Python in a way that
supported known use cases.  I raised the standard of the Python docs by
including rough python equivalent code, showing sample inputs and outputs, 
building a quick navigation and summary section as the top of the docs,
adding a recipes section, making thorough unittests, and getting input from Alex,
Tim, and Fredrik (Guido also gave high level advice on the module design).

I'm not inclined to go on with this thread. Your questions have been answered
to the extent that I remember the answers.  If you have a doc patch you want
to submit, please assign it to me on the tracker.  I would be happy to review it.





 






From travis at continuum.io  Mon Sep 14 00:51:12 2015
From: travis at continuum.io (Travis Oliphant)
Date: Sun, 13 Sep 2015 17:51:12 -0500
Subject: [Python-Dev] The process I intend to follow for any proposed
	changes to NumPy
Message-ID: <CAMcnTE5V-ivCMkjSyaGAg-JUOqtfmBbxStvSoEt-L1zb2MPoqg@mail.gmail.com>

Hey all,

I just wanted to clarify, that I am very excited about a few ideas I have
--- but I don't have time myself to engage in the community process to get
these changes into NumPy.     However, those are real processes --- I've
been coaching a few people in those processes for the past several years
already.

So, rather than do nothing, what I'm looking to do is to work with a few
people who I can share my ideas with, get excited about the ideas, and then
who will work with the community to get them implemented.   That's what I
was announcing and talking about yesterday --- looking for interested
people who want to work on NumPy *with* the NumPy community.

In my enthusiasm, I realize that some may have mis-understood my
intention.  There is no 'imminent' fork, nor am I planning on doing some
crazy amount of work that I then try to force on other developers of NumPy.


What I'm planning to do is find people to train on NumPy code base (people
to increase the diversity of the developers would be ideal -- but hard to
accomplish).  I plan to train them on NumPy based on my experience, and on
what I think should be done --- and then have *them* work through the
community process and engage with others to get consensus (hopefully not
losing too much in translation in the process --- but instead getting even
better).

During that process I will engage as a member of the community and help
write NEPs and other documents and help clarify where it makes sense as I
can.   I will be filtering for people that actually want to see NumPy get
better.    Until I identify the people and work with them, it will be hard
to tell how this will best work.   So, stay tuned.

If all goes well, what you should see in a few weeks time are specific
proposals, a branch or two, and the beginnings of some pull requests.    If
you don't see that, then I will not have found the right people to help me,
and we will all continue to go back to searching.

While I'm expecting the best, in the worst case, we get additional people
who know the NumPy code base and can help squash bugs as well as implement
changes that are desired.    Three things are needed if you want to
participate in this:  1) A willingness to work with the open source
community, 2) a deep knowledge of C and in-particular CPython's brand of C,
and 3) a willingness to engage with me, do a mind-meld and dump around the
NumPy code base, and then improve on what is in my head with the rest of
the community.

Thanks,

-Travis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150913/45190461/attachment.html>

From larry at hastings.org  Mon Sep 14 06:18:41 2015
From: larry at hastings.org (Larry Hastings)
Date: Mon, 14 Sep 2015 05:18:41 +0100
Subject: [Python-Dev] When is 3.4.4 scheduled?
In-Reply-To: <mt4rvr$s9a$1@ger.gmane.org>
References: <mt4rvr$s9a$1@ger.gmane.org>
Message-ID: <55F64AA1.90805@hastings.org>



It's not.  My thinking was, do it in about a month.  How's that sound?

3.4.4 should be the last bugfix release of 3.4, after that it'll move 
into security-fixes-only.


//arry/

On 09/13/2015 11:05 PM, Terry Reedy wrote:
> I could not fine '3.4.4' either in
> https://www.python.org/dev/peps/pep-0429/ 3.4 schedule
> or elsewhere on the site.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150914/878750b6/attachment.html>

From fijall at gmail.com  Mon Sep 14 08:41:45 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 14 Sep 2015 08:41:45 +0200
Subject: [Python-Dev] semantics of subclassing things from itertools
In-Reply-To: <D7E9F183-1379-4902-99CA-56D0BCB4718D@gmail.com>
References: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
 <E4833933-12FE-4ADC-9604-134FE953E9A8@gmail.com>
 <CAK5idxRnsdQ=p_S32R1BoX9OLiRiyhP3xR81nr6Utoma1gGpww@mail.gmail.com>
 <1F7C02D0-68E2-4B89-A6FC-CC65C17A44C4@gmail.com>
 <CAK5idxQ=tSSU6pOESK48XLFKpFAXYQqnBC5_QnEtYsMUCsEkhQ@mail.gmail.com>
 <D7E9F183-1379-4902-99CA-56D0BCB4718D@gmail.com>
Message-ID: <CAK5idxSN4LqahbiwORYu8FFPewSrF=u1YrCxLb+D+NNhgQ05pw@mail.gmail.com>

Hey Raymond

I'm sorry you got insulted, that was not my intention. I suppose
something like "itertools objects are implemented as classes
internally, which means they're subclassable like other builtin types"
is an improvement to documentation.

On Mon, Sep 14, 2015 at 12:17 AM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
>> On Sep 13, 2015, at 3:09 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>
>> Well, fair enough, but the semantics of "whatever happens to happen
>> because we decided subclassing is a cool idea" is possibly the worst
>> answer to those questions.
>
> It's hard to read this in any way that isn't insulting.
>
> It was subclassable because a) it was a class, 2) type/class unification was
> pushing us in the direction of making builtin types more like regular classes
> (which are subclassable), and 3) because it seemed potentially useful
> to users (and apparently it has been because users are subclassing it).
>
> FWIW, the code was modeled on what was done for enumerate() and
> reversed() where I got a lot of coaching and review from Tim Peters,
> Alex Martelli, Fredrik Lundh, and other python luminaries of the day.
>
>
>> Ideally, make it non-subclassable. If you
>> want to have it subclassable, then please have defined semantics as
>> opposed to undefined.
>
> No, I'm not going to change a 13 year-old API and break existing user code
> just because you've gotten worked-up about it.
>
> FWIW, the semantics wouldn't even be defined in the itertools docs.
> It is properly in some section that describes what happens to any C type
> that defines sets the Py_TPFLAGS_BASETYPE flag.   In general, all of
> the exposed dunder methods are overridable or extendable by subclassers.
>
>
> Raymond
>
>
> P.S.  Threads like this are why I've developed an aversion to python-dev.
> I've answered your questions with respect and candor. I've been sympathetic
> to your unique needs as someone building an implementation of a language
> that doesn't have a spec.  I was apologetic that the docs which have been
> helpful to users weren't precise enough for your needs.
>
> In return, you've suggested that my first contributions to Python were
> irresponsible and based on doing whatever seemed cool.
>
> In fact, the opposite is the case.  I spent a full summer researching how similar
> tools were used in other languages and fitting them into Python in a way that
> supported known use cases.  I raised the standard of the Python docs by
> including rough python equivalent code, showing sample inputs and outputs,
> building a quick navigation and summary section as the top of the docs,
> adding a recipes section, making thorough unittests, and getting input from Alex,
> Tim, and Fredrik (Guido also gave high level advice on the module design).
>
> I'm not inclined to go on with this thread. Your questions have been answered
> to the extent that I remember the answers.  If you have a doc patch you want
> to submit, please assign it to me on the tracker.  I would be happy to review it.
>
>
>
>
>
>
>
>
>
>
>

From alecsandru.patrascu at intel.com  Mon Sep 14 09:32:28 2015
From: alecsandru.patrascu at intel.com (Patrascu, Alecsandru)
Date: Mon, 14 Sep 2015 07:32:28 +0000
Subject: [Python-Dev] Hash computation enhancement for {buffer, string,
	unicode}object
Message-ID: <3CF256F4F774BD48A1691D131AA04319141C8A34@IRSMSX102.ger.corp.intel.com>

Hi All,

This is Alecsandru from Server Scripting Languages Optimization team at Intel Corporation.

I would like to submit a patch that improves the performance of the hash computation code on stringobject, bufferobject and unicodeobject. As can be seen from the attached sample performance results from the Grand Unified Python Benchmark, speedups up to 40% were observed. Furthermore, we see a 5-7% performance on OpenStack/Swift, where most of the code is in Python 2.7.

Attached is the patch that modifies Object/stringobject.c, Object/bufferobject.c and Object/unicodeobject.c files. We built and tested this patch for Python 2.7 on our Linux machines (CentOS 7/Ubuntu Server 14.04, Intel Xeon Haswell/Broadwell with 18/8 cores). 

I've also opened an issue on the bug tracker: http://bugs.python.org/issue25106

Steps to apply the patch:
1.  hg clone https://hg.python.org/cpython cpython 
2.  cd cpython 
3.  hg update 2.7
4.  Copy hash8.patch to the current directory 
5.  hg import --no-commit hash8.patch
6.  ./configure 
7.  make



In the following, please find our sample performance results measured on a XEON Haswell machine.  

Hardware (HW):      Intel XEON (Haswell) 18 Cores

BIOS settings:      Intel Turbo Boost Technology: false
                    Hyper-Threading: false

Operating System:   Ubuntu 14.04.3 LTS trusty

OS configuration:   CPU freq set at fixed: 2.0GHz by
                        echo 2000000 > /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
                        echo 2000000 > /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
                    Address Space Layout Randomization (ASLR) disabled (to reduce run to run variation) by
                        echo 0 > /proc/sys/kernel/randomize_va_space
                
GCC version:        gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)

Benchmark:          Grand Unified Python Benchmark (GUPB)
                    GUPB Source: https://hg.python.org/benchmarks/                    

Python2.7 results:
    Python source: hg clone https://hg.python.org/cpython cpython
    Python Source: hg update 2.7

        Benchmarks          Speedup(%)
        unpack_sequence     40.32733766
        chaos               24.84002537
        chameleon           23.01392651
        silent_logging      22.27202911
        django              20.83842317
        etree_process       20.46968294
        nqueens             20.34234985
        pathlib             19.63445919
        pidigits            19.34722148
        etree_generate      19.25836634
        pybench             19.06895825
        django_v2           18.06073108
        etree_iterparse     17.3797149
        fannkuch            17.08120879
        pickle_list         16.60363602
        raytrace            16.0316265
        slowpickle          15.86611184
        pickle_dict         15.30447114
        call_simple         14.42909032
        richards            14.2949594
        simple_logging      13.6522626
        etree_parse         13.38113097
        json_dump_v2        12.26588885
        float               11.88164311
        mako                11.20606516
        spectral_norm       11.04356684
        hg_startup          10.57686164
        mako_v2             10.37912648
        slowunpickle        10.24030714
        go                  10.03567319
        meteor_contest      9.956231435
        normal_startup      9.607401586
        formatted_logging   9.601244811
        html5lib            9.082603748
        2to3                8.741557816
        html5lib_warmup     8.268150981
        nbody               7.507012306
        regex_compile       7.153922724
        bzr_startup         7.140244739
        telco               6.869411927
        slowspitfire        5.746323922
        tornado_http        5.24360121
        rietveld            3.865704876
        regex_v8            3.777622219
        hexiom2             3.586305282
        json_dump           3.477551682
        spambayes           3.183991854
        fastunpickle        2.971645347
        fastpickle          0.673086656
        regex_effbot        0.127946837
        json_load           0.023727176

Thank you,
Alecsandru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hash8-v01.patch
Type: application/octet-stream
Size: 6065 bytes
Desc: hash8-v01.patch
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150914/ffe6a843/attachment.obj>

From storchaka at gmail.com  Mon Sep 14 10:19:51 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Mon, 14 Sep 2015 11:19:51 +0300
Subject: [Python-Dev] semantics of subclassing things from itertools
In-Reply-To: <CAK5idxRvNcJKXSer-40rZF-wtt_=qssgBWof1Jw+Qrj7w1CWJg@mail.gmail.com>
References: <CAK5idxRoDAk-Q2GRS0QAuuengX+TU5cGDhuxqkNTB=Yr1BfV4A@mail.gmail.com>
 <msrer1$pp$1@ger.gmane.org>
 <CAK5idxRvNcJKXSer-40rZF-wtt_=qssgBWof1Jw+Qrj7w1CWJg@mail.gmail.com>
Message-ID: <mt5vv8$hti$1@ger.gmane.org>

On 10.09.15 15:50, Maciej Fijalkowski wrote:
> On Thu, Sep 10, 2015 at 10:26 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> There is another reason why itertools iterators can't be implemented as
>> simple generator functions. All iterators are pickleable in 3.x.
>
> maybe the documentation should reflect that? (note that generators are
> pickleable on pypy anyway)

This pickling is not compatible with CPython. So even if itertools 
classes would not subclassable, you would need to implement itertools 
iterators as classes.


From victor.stinner at gmail.com  Mon Sep 14 10:29:43 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 14 Sep 2015 10:29:43 +0200
Subject: [Python-Dev] What happens of the Python 3.4 branch?
Message-ID: <CAMpsgwaPbmdtVY4=6OkVw2k1iyx1hvv0YWabg4TeSCUMCKcQcA@mail.gmail.com>

Hi,

Python 3.5.0 was released. What happens to the 3.4 branch in
Mercurial? Does it still accept bugfixes, or is it only for security
fixes now?

Victor

From larry at hastings.org  Mon Sep 14 11:49:24 2015
From: larry at hastings.org (Larry Hastings)
Date: Mon, 14 Sep 2015 10:49:24 +0100
Subject: [Python-Dev] What happens of the Python 3.4 branch?
In-Reply-To: <CAMpsgwaPbmdtVY4=6OkVw2k1iyx1hvv0YWabg4TeSCUMCKcQcA@mail.gmail.com>
References: <CAMpsgwaPbmdtVY4=6OkVw2k1iyx1hvv0YWabg4TeSCUMCKcQcA@mail.gmail.com>
Message-ID: <55F69824.4010203@hastings.org>



On 09/14/2015 09:29 AM, Victor Stinner wrote:
> Python 3.5.0 was released. What happens to the 3.4 branch in
> Mercurial? Does it still accept bugfixes, or is it only for security
> fixes now?

Nothing has been announced or decided.  As release manager I suppose I 
get some say.  Here, I'll propose something:

    Python 3.4.4 rc1 should be released on Sunday October 4th.
    Python 3.4.4 final should be released on Sunday October 13th.
    After the tag of 3.4.4, Python 3.4 should enter security-fixes-only
    mode, and any future releases (3.4.5+) will be source code only.

How's that?


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150914/1b092833/attachment.html>

From breamoreboy at yahoo.co.uk  Mon Sep 14 12:37:38 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Mon, 14 Sep 2015 11:37:38 +0100
Subject: [Python-Dev] What happens of the Python 3.4 branch?
In-Reply-To: <55F69824.4010203@hastings.org>
References: <CAMpsgwaPbmdtVY4=6OkVw2k1iyx1hvv0YWabg4TeSCUMCKcQcA@mail.gmail.com>
 <55F69824.4010203@hastings.org>
Message-ID: <mt681q$ked$1@ger.gmane.org>

On 14/09/2015 10:49, Larry Hastings wrote:
>
>
> On 09/14/2015 09:29 AM, Victor Stinner wrote:
>> Python 3.5.0 was released. What happens to the 3.4 branch in
>> Mercurial? Does it still accept bugfixes, or is it only for security
>> fixes now?
>
> Nothing has been announced or decided.  As release manager I suppose I
> get some say.  Here, I'll propose something:
>
>     Python 3.4.4 rc1 should be released on Sunday October 4th.
>     Python 3.4.4 final should be released on Sunday October 13th.
>     After the tag of 3.4.4, Python 3.4 should enter security-fixes-only
>     mode, and any future releases (3.4.5+) will be source code only.
>
> How's that?
>
> //arry/

Sorry but Sunday October 13th doesn't suit me, how about Sunday October 
11th or Sunday October 18th?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From larry at hastings.org  Mon Sep 14 12:55:14 2015
From: larry at hastings.org (Larry Hastings)
Date: Mon, 14 Sep 2015 11:55:14 +0100
Subject: [Python-Dev] What happens of the Python 3.4 branch?
In-Reply-To: <mt681q$ked$1@ger.gmane.org>
References: <CAMpsgwaPbmdtVY4=6OkVw2k1iyx1hvv0YWabg4TeSCUMCKcQcA@mail.gmail.com>
 <55F69824.4010203@hastings.org> <mt681q$ked$1@ger.gmane.org>
Message-ID: <55F6A792.8010609@hastings.org>



On 09/14/2015 11:37 AM, Mark Lawrence wrote:
> Sorry but Sunday October 13th doesn't suit me, how about Sunday 
> October 11th or Sunday October 18th?
>

Fair enough.  Sunday October 11th, 2015.

On second thought it's probably best to not wait until 2019,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150914/641249a8/attachment.html>

From bcannon at gmail.com  Mon Sep 14 18:49:15 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Mon, 14 Sep 2015 16:49:15 +0000
Subject: [Python-Dev] [Python-checkins] cpython: In-line the append
	operations inside deque_inplace_repeat().
In-Reply-To: <20150912150038.15706.90493@psf.io>
References: <20150912150038.15706.90493@psf.io>
Message-ID: <CAP1=2W5=WcZ7fMTRHeVLc=iPUKCpYF_f5KVBrAn57LBAQ_Zggw@mail.gmail.com>

Would it be worth adding a comment that the block of code is an inlined
copy of deque_append()? Or maybe even turn the append() function into a
macro so you minimize code duplication?

On Sat, 12 Sep 2015 at 08:00 raymond.hettinger <python-checkins at python.org>
wrote:

> https://hg.python.org/cpython/rev/cb96ffe6ff10
> changeset:   97943:cb96ffe6ff10
> parent:      97941:b8f3a01937be
> user:        Raymond Hettinger <python at rcn.com>
> date:        Sat Sep 12 11:00:20 2015 -0400
> summary:
>   In-line the append operations inside deque_inplace_repeat().
>
> files:
>   Modules/_collectionsmodule.c |  22 ++++++++++++++++++----
>   1 files changed, 18 insertions(+), 4 deletions(-)
>
>
> diff --git a/Modules/_collectionsmodule.c b/Modules/_collectionsmodule.c
> --- a/Modules/_collectionsmodule.c
> +++ b/Modules/_collectionsmodule.c
> @@ -567,12 +567,26 @@
>          if (n > MAX_DEQUE_LEN)
>              return PyErr_NoMemory();
>
> +        deque->state++;
>          for (i = 0 ; i < n-1 ; i++) {
> -            rv = deque_append(deque, item);
> -            if (rv == NULL)
> -                return NULL;
> -            Py_DECREF(rv);
> +            if (deque->rightindex == BLOCKLEN - 1) {
> +                block *b = newblock(Py_SIZE(deque) + i);
> +                if (b == NULL) {
> +                    Py_SIZE(deque) += i;
> +                    return NULL;
> +                }
> +                b->leftlink = deque->rightblock;
> +                CHECK_END(deque->rightblock->rightlink);
> +                deque->rightblock->rightlink = b;
> +                deque->rightblock = b;
> +                MARK_END(b->rightlink);
> +                deque->rightindex = -1;
> +            }
> +            deque->rightindex++;
> +            Py_INCREF(item);
> +            deque->rightblock->data[deque->rightindex] = item;
>          }
> +        Py_SIZE(deque) += i;
>          Py_INCREF(deque);
>          return (PyObject *)deque;
>      }
>
> --
> Repository URL: https://hg.python.org/cpython
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> https://mail.python.org/mailman/listinfo/python-checkins
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150914/04ae156a/attachment.html>

From chris.barker at noaa.gov  Mon Sep 14 19:46:51 2015
From: chris.barker at noaa.gov (Chris Barker)
Date: Mon, 14 Sep 2015 10:46:51 -0700
Subject: [Python-Dev] [Numpy-discussion] The process I intend to follow
 for any proposed changes to NumPy
In-Reply-To: <CAMcnTE5V-ivCMkjSyaGAg-JUOqtfmBbxStvSoEt-L1zb2MPoqg@mail.gmail.com>
References: <CAMcnTE5V-ivCMkjSyaGAg-JUOqtfmBbxStvSoEt-L1zb2MPoqg@mail.gmail.com>
Message-ID: <CALGmxELEBjTH1MO2o02g-HF5Ur7M-MahrWRkEnRpz=fH-NwK5A@mail.gmail.com>

Travis,

I'm sure you appreciate that this might all look a bit scary, given the
recent discussion about numpy governance.

But it's an open-source project, and I, at least, fully understand that
going through a big process is NOT the way to get a new idea tried out and
implemented. So I think think this is a great development -- I know I want
to see something like this dtype work done.

So, as someone who has been around this community for a long time, and
dependent on Numeric, numarray, and numpy over the years, this looks like a
great development.

And, in fact, with the new governance effort -- I think less scary --
people can go off and work on a branch or fork, do good stuff, and we, as a
community, can be assured that API (or even ABI) changes won't be thrust
upon us unawares :-)

As for the technical details -- I get a bit lost, not fully understanding
the current dtype system either, but do your ideas take us in the direction
of having dtypes independent of the container and ufunc machinery -- and
thus easier to create new dtypes (even in Python?) 'cause that would be
great.

I hope you find the partner you're looking for -- that's a challenge!

-Chris




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150914/34c7696c/attachment.html>

From raymond.hettinger at gmail.com  Tue Sep 15 00:37:15 2015
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 14 Sep 2015 18:37:15 -0400
Subject: [Python-Dev] [Python-checkins] cpython: In-line the append
	operations inside deque_inplace_repeat().
In-Reply-To: <CAP1=2W5=WcZ7fMTRHeVLc=iPUKCpYF_f5KVBrAn57LBAQ_Zggw@mail.gmail.com>
References: <20150912150038.15706.90493@psf.io>
 <CAP1=2W5=WcZ7fMTRHeVLc=iPUKCpYF_f5KVBrAn57LBAQ_Zggw@mail.gmail.com>
Message-ID: <7097FAA2-5F18-4FAE-9876-606414AEFF8F@gmail.com>


> On Sep 14, 2015, at 12:49 PM, Brett Cannon <bcannon at gmail.com> wrote:
> 
> Would it be worth adding a comment that the block of code is an inlined copy of deque_append()?
> Or maybe even turn the append() function into a macro so you minimize code duplication?

I don't think either would be helpful.  The point of the inlining was to let the code evolve independently from deque_append().   

Once separated from the mother ship, the code in deque_inline_repeat() could now shed the unnecessary work.  The state variable is updated once.  The updates within a single block are now in the own inner loop. The deque size is updated outside of that loop, etc.   In other words, they are no longer the same code.

The original append-in-a-loop version was already being in-lined by the compiler but was doing way too much work.  For each item written in the original, there were 7 memory reads, 5 writes, 6 predictable compare-and-branches, and 5 add/sub operations.  In the current form, there are 0 reads, 1 writes, 2 predictable compare-and-branches, and 3 add/sub operations.

FWIW, my work flow is that periodically I expand the code with new features (the upcoming work is to add slicing support http://bugs.python.org/issue17394), then once it is correct and tested, I make a series optimization passes (such as the work I just described above).  After that, I come along and factor-out common code, usually with clean, in-lineable functions rather than macros (such as the recent check-in replacing redundant code in deque_repeat with a call to the common code in deque_inplace_repeat).

My schedule lately hasn't given me any big blocks of time to work with, so I do the steps piecemeal as I get snippets of development time.


Raymond


P.S. For those who are interested, here is the before and after:

---- before ---------------------------------
L1152:
    movq    __Py_NoneStruct at GOTPCREL(%rip), %rdi
    cmpq    $0, (%rdi)                                   <
    je  L1257
L1159:
    addq    $1, %r13
    cmpq    %r14, %r13
    je  L1141
    movq    16(%rbx), %rsi                               <
L1142:
    movq    48(%rbx), %rdx                               <
    addq    $1, 56(%rbx)                                 <>
    cmpq    $63, %rdx
    je  L1143
    movq    32(%rbx), %rax                               <
    addq    $1, %rdx
L1144:
    addq    $1, 0(%rbp)                                  <>
    leaq    1(%rsi), %rcx
    movq    %rdx, 48(%rbx)                                >
    movq    %rcx, 16(%rbx)                                >
    movq    %rbp, 8(%rax,%rdx,8)                          >
    movq    64(%rbx), %rax                               <
    cmpq    %rax, %rcx
    jle L1152
    cmpq    $-1, %rax
    je  L1152


---- after ------------------------------------
L777:
    cmpq    $63, %rdx
    je  L816
L779:
    addq    $1, %rdx
    movq    %rbp, 16(%rsi,%rbx,8)                <
    addq    $1, %rbx
    leaq    (%rdx,%r9), %rcx
    subq    %r8, %rcx
    cmpq    %r12, %rbx
    jl  L777

    # outside the inner-loop
    movq    %rdx, 48(%r13)                  
    movq    %rcx, 0(%rbp)
    cmpq    %r12, %rbx
    jl  L780

From bcannon at gmail.com  Tue Sep 15 01:36:09 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Mon, 14 Sep 2015 23:36:09 +0000
Subject: [Python-Dev] [Python-checkins] cpython: In-line the append
 operations inside deque_inplace_repeat().
In-Reply-To: <7097FAA2-5F18-4FAE-9876-606414AEFF8F@gmail.com>
References: <20150912150038.15706.90493@psf.io>
 <CAP1=2W5=WcZ7fMTRHeVLc=iPUKCpYF_f5KVBrAn57LBAQ_Zggw@mail.gmail.com>
 <7097FAA2-5F18-4FAE-9876-606414AEFF8F@gmail.com>
Message-ID: <CAP1=2W4t-dpp43LhH3-7qik6iBdDbL4jhbzLCxrPfdo7fqtrzQ@mail.gmail.com>

On Mon, 14 Sep 2015 at 15:37 Raymond Hettinger <raymond.hettinger at gmail.com>
wrote:

>
> > On Sep 14, 2015, at 12:49 PM, Brett Cannon <bcannon at gmail.com> wrote:
> >
> > Would it be worth adding a comment that the block of code is an inlined
> copy of deque_append()?
> > Or maybe even turn the append() function into a macro so you minimize
> code duplication?
>
> I don't think either would be helpful.  The point of the inlining was to
> let the code evolve independently from deque_append().
>

OK, commit message just didn't point that out as the reason for the
inlining (I guess in the future call it a fork of the code to know it is
meant to evolve independently?).

-Brett


>
> Once separated from the mother ship, the code in deque_inline_repeat()
> could now shed the unnecessary work.  The state variable is updated once.
> The updates within a single block are now in the own inner loop. The deque
> size is updated outside of that loop, etc.   In other words, they are no
> longer the same code.
>
> The original append-in-a-loop version was already being in-lined by the
> compiler but was doing way too much work.  For each item written in the
> original, there were 7 memory reads, 5 writes, 6 predictable
> compare-and-branches, and 5 add/sub operations.  In the current form, there
> are 0 reads, 1 writes, 2 predictable compare-and-branches, and 3 add/sub
> operations.
>
> FWIW, my work flow is that periodically I expand the code with new
> features (the upcoming work is to add slicing support
> http://bugs.python.org/issue17394), then once it is correct and tested, I
> make a series optimization passes (such as the work I just described
> above).  After that, I come along and factor-out common code, usually with
> clean, in-lineable functions rather than macros (such as the recent
> check-in replacing redundant code in deque_repeat with a call to the common
> code in deque_inplace_repeat).
>
> My schedule lately hasn't given me any big blocks of time to work with, so
> I do the steps piecemeal as I get snippets of development time.
>
>
> Raymond
>
>
> P.S. For those who are interested, here is the before and after:
>
> ---- before ---------------------------------
> L1152:
>     movq    __Py_NoneStruct at GOTPCREL(%rip), %rdi
>     cmpq    $0, (%rdi)                                   <
>     je  L1257
> L1159:
>     addq    $1, %r13
>     cmpq    %r14, %r13
>     je  L1141
>     movq    16(%rbx), %rsi                               <
> L1142:
>     movq    48(%rbx), %rdx                               <
>     addq    $1, 56(%rbx)                                 <>
>     cmpq    $63, %rdx
>     je  L1143
>     movq    32(%rbx), %rax                               <
>     addq    $1, %rdx
> L1144:
>     addq    $1, 0(%rbp)                                  <>
>     leaq    1(%rsi), %rcx
>     movq    %rdx, 48(%rbx)                                >
>     movq    %rcx, 16(%rbx)                                >
>     movq    %rbp, 8(%rax,%rdx,8)                          >
>     movq    64(%rbx), %rax                               <
>     cmpq    %rax, %rcx
>     jle L1152
>     cmpq    $-1, %rax
>     je  L1152
>
>
> ---- after ------------------------------------
> L777:
>     cmpq    $63, %rdx
>     je  L816
> L779:
>     addq    $1, %rdx
>     movq    %rbp, 16(%rsi,%rbx,8)                <
>     addq    $1, %rbx
>     leaq    (%rdx,%r9), %rcx
>     subq    %r8, %rcx
>     cmpq    %r12, %rbx
>     jl  L777
>
>     # outside the inner-loop
>     movq    %rdx, 48(%r13)
>     movq    %rcx, 0(%rbp)
>     cmpq    %r12, %rbx
>     jl  L780
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150914/be056253/attachment.html>

From storchaka at gmail.com  Tue Sep 15 11:17:00 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 15 Sep 2015 12:17:00 +0300
Subject: [Python-Dev] peps: Move 13 -> 103
In-Reply-To: <20150915012142.27709.21417@psf.io>
References: <20150915012142.27709.21417@psf.io>
Message-ID: <mt8nmc$6rp$1@ger.gmane.org>

On 15.09.15 04:21, barry.warsaw wrote:
> https://hg.python.org/peps/rev/e275c4cd4b44
> changeset:   6059:e275c4cd4b44
> user:        Barry Warsaw <barry at python.org>
> date:        Mon Sep 14 21:21:40 2015 -0400
> summary:
>    Move 13 -> 103
>
> files:
>    pep-0103.rst |  2 +-
>    1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/pep-0013.rst b/pep-0103.rst
> rename from pep-0013.rst
> rename to pep-0103.rst

Is it due to superstition?



From phd at phdru.name  Tue Sep 15 12:50:12 2015
From: phd at phdru.name (Oleg Broytman)
Date: Tue, 15 Sep 2015 12:50:12 +0200
Subject: [Python-Dev] peps: Move 13 -> 103
In-Reply-To: <mt8nmc$6rp$1@ger.gmane.org>
References: <20150915012142.27709.21417@psf.io>
 <mt8nmc$6rp$1@ger.gmane.org>
Message-ID: <20150915105012.GA11345@phdru.name>

On Tue, Sep 15, 2015 at 12:17:00PM +0300, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 15.09.15 04:21, barry.warsaw wrote:
> >https://hg.python.org/peps/rev/e275c4cd4b44
> >changeset:   6059:e275c4cd4b44
> >user:        Barry Warsaw <barry at python.org>
> >date:        Mon Sep 14 21:21:40 2015 -0400
> >summary:
> >   Move 13 -> 103
> >
> >files:
> >   pep-0103.rst |  2 +-
> >   1 files changed, 1 insertions(+), 1 deletions(-)
> >
> >
> >diff --git a/pep-0013.rst b/pep-0103.rst
> >rename from pep-0013.rst
> >rename to pep-0103.rst
> 
> Is it due to superstition?

   It's because I suggested the PEP doesn't deserve to be listed among
the top Process PEPs. Mine PEP is just Informational, so a number like
103 seems to suits it better. Barry agreed.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From phd at phdru.name  Tue Sep 15 17:11:51 2015
From: phd at phdru.name (Oleg Broytman)
Date: Tue, 15 Sep 2015 17:11:51 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150912135451.GA13004@phdru.name>
References: <20150912135451.GA13004@phdru.name>
Message-ID: <20150915151151.GA19938@phdru.name>

Hello!

On Sat, Sep 12, 2015 at 03:54:51PM +0200, Oleg Broytman <phd at phdru.name> wrote:
> Title: Collecting information about git

   The PEP is assigned number 103:
https://www.python.org/dev/peps/pep-0103/

   I added a section "Branching models".

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From benjamin at python.org  Tue Sep 15 18:46:55 2015
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 15 Sep 2015 09:46:55 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150912135641.GB13004@phdru.name>
References: <20150912135451.GA13004@phdru.name>
 <20150912135641.GB13004@phdru.name>
Message-ID: <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>

This looks like good information, but why is it a PEP? If anything, the
devguide was probably be more appropriate. But even that's strange
considering we don't use git at the moment.

On Sat, Sep 12, 2015, at 06:56, Oleg Broytman wrote:
> On Sat, Sep 12, 2015 at 03:54:51PM +0200, Oleg Broytman <phd at phdru.name>
> wrote:
> > PEP: XXX
> > Title: Collecting information about git
> 
>    HTMLized version: http://phdru.name/Software/Python/PEPs/pep-git.html
>    git repo: http://git.phdru.name/?p=pep-git.git;a=summary
> 
> Oleg.
> -- 
>      Oleg Broytman            http://phdru.name/           
>      phd at phdru.name
>            Programmers don't die, they just GOSUB without RETURN.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/benjamin%40python.org

From phd at phdru.name  Tue Sep 15 20:02:59 2015
From: phd at phdru.name (Oleg Broytman)
Date: Tue, 15 Sep 2015 20:02:59 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>
References: <20150912135451.GA13004@phdru.name>
 <20150912135641.GB13004@phdru.name>
 <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>
Message-ID: <20150915180259.GA24744@phdru.name>

On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson <benjamin at python.org> wrote:
> This looks like good information, but why is it a PEP? If anything, the
> devguide was probably be more appropriate. But even that's strange
> considering we don't use git at the moment.

   Exactly because the core team doesn't use git the information doesn't
belong to the current revision of Developer's Guide.

> On Sat, Sep 12, 2015, at 06:56, Oleg Broytman wrote:
> > On Sat, Sep 12, 2015 at 03:54:51PM +0200, Oleg Broytman <phd at phdru.name>
> > wrote:
> > > PEP: 103
> > > Title: Collecting information about git

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From benjamin at python.org  Tue Sep 15 20:14:36 2015
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 15 Sep 2015 11:14:36 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150915180259.GA24744@phdru.name>
References: <20150912135451.GA13004@phdru.name>
 <20150912135641.GB13004@phdru.name>
 <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>
 <20150915180259.GA24744@phdru.name>
Message-ID: <1442340876.1319419.384468041.2E81A733@webmail.messagingengine.com>



On Tue, Sep 15, 2015, at 11:02, Oleg Broytman wrote:
> On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson
> <benjamin at python.org> wrote:
> > This looks like good information, but why is it a PEP? If anything, the
> > devguide was probably be more appropriate. But even that's strange
> > considering we don't use git at the moment.
> 
>    Exactly because the core team doesn't use git the information doesn't
> belong to the current revision of Developer's Guide.

Unless it's actually going to argue that we should move to git, I don't
see why it should be a PEP either.

From barry at barrys-emacs.org  Tue Sep 15 19:39:31 2015
From: barry at barrys-emacs.org (Barry Scott)
Date: Tue, 15 Sep 2015 18:39:31 +0100
Subject: [Python-Dev] python windows installation inconsistent use of
	registry keys
Message-ID: <FAF389F0-07C6-4AB7-84A7-CD42E1BAB520@barrys-emacs.org>

I am used to looking in HKLM:\SOFTWARE\Python\PythonCore\%(py_maj)d.%(py_min)d\InstallPath
to find out where python is installed so that my installation kit can add itself to site-packages.

I just found that the registry key used for 32 bit python 3.5 on windows changed to be '3.5-32',
which I can change my installer to cope with.

However the key for the 64bit install is ?3.5? but not '3.5-64'.

Why was this changed and why not consistently between 32 and 64 bit versions?

Barry
PyCXX, PySVN maintainer


From g.brandl at gmx.net  Tue Sep 15 20:19:37 2015
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 15 Sep 2015 20:19:37 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150915180259.GA24744@phdru.name>
References: <20150912135451.GA13004@phdru.name>
 <20150912135641.GB13004@phdru.name>
 <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>
 <20150915180259.GA24744@phdru.name>
Message-ID: <mt9nfp$1u9$1@ger.gmane.org>

On 09/15/2015 08:02 PM, Oleg Broytman wrote:
> On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson <benjamin at python.org> wrote:
>> This looks like good information, but why is it a PEP? If anything, the
>> devguide was probably be more appropriate. But even that's strange
>> considering we don't use git at the moment.
> 
>    Exactly because the core team doesn't use git the information doesn't
> belong to the current revision of Developer's Guide.

And if it doesn't propose to make the core team use git, why is it a PEP?

Georg


From guido at python.org  Tue Sep 15 20:22:30 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 Sep 2015 11:22:30 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <mt9nfp$1u9$1@ger.gmane.org>
References: <20150912135451.GA13004@phdru.name>
 <20150912135641.GB13004@phdru.name>
 <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>
 <20150915180259.GA24744@phdru.name> <mt9nfp$1u9$1@ger.gmane.org>
Message-ID: <CAP7+vJJ68uYc7hsVSkGtKN2LzdjnWQc0HYrmSRNTzwjstzrJBw@mail.gmail.com>

For one, because *I* have been a (moderate) advocate for switching to git
and GitHub.

On Tue, Sep 15, 2015 at 11:19 AM, Georg Brandl <g.brandl at gmx.net> wrote:

> On 09/15/2015 08:02 PM, Oleg Broytman wrote:
> > On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson <
> benjamin at python.org> wrote:
> >> This looks like good information, but why is it a PEP? If anything, the
> >> devguide was probably be more appropriate. But even that's strange
> >> considering we don't use git at the moment.
> >
> >    Exactly because the core team doesn't use git the information doesn't
> > belong to the current revision of Developer's Guide.
>
> And if it doesn't propose to make the core team use git, why is it a PEP?
>
> Georg
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150915/fd9837ed/attachment.html>

From g.brandl at gmx.net  Tue Sep 15 20:32:33 2015
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 15 Sep 2015 20:32:33 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAP7+vJJ68uYc7hsVSkGtKN2LzdjnWQc0HYrmSRNTzwjstzrJBw@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <20150912135641.GB13004@phdru.name>
 <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>
 <20150915180259.GA24744@phdru.name> <mt9nfp$1u9$1@ger.gmane.org>
 <CAP7+vJJ68uYc7hsVSkGtKN2LzdjnWQc0HYrmSRNTzwjstzrJBw@mail.gmail.com>
Message-ID: <mt9o81$dmv$1@ger.gmane.org>

Fair enough. Still strange to read this PEP with the explicit caveat of
"The author of the PEP doesn't currently plan to write a Process PEP on
migration Python development from Mercurial to git."

Georg

On 09/15/2015 08:22 PM, Guido van Rossum wrote:
> For one, because *I* have been a (moderate) advocate for switching to git and
> GitHub.
> 
> On Tue, Sep 15, 2015 at 11:19 AM, Georg Brandl <g.brandl at gmx.net
> <mailto:g.brandl at gmx.net>> wrote:
> 
>     On 09/15/2015 08:02 PM, Oleg Broytman wrote:
>     > On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson <benjamin at python.org <mailto:benjamin at python.org>> wrote:
>     >> This looks like good information, but why is it a PEP? If anything, the
>     >> devguide was probably be more appropriate. But even that's strange
>     >> considering we don't use git at the moment.
>     >
>     >    Exactly because the core team doesn't use git the information doesn't
>     > belong to the current revision of Developer's Guide.
> 
>     And if it doesn't propose to make the core team use git, why is it a PEP?




From phd at phdru.name  Tue Sep 15 20:44:39 2015
From: phd at phdru.name (Oleg Broytman)
Date: Tue, 15 Sep 2015 20:44:39 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <mt9o81$dmv$1@ger.gmane.org>
References: <20150912135451.GA13004@phdru.name>
 <20150912135641.GB13004@phdru.name>
 <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>
 <20150915180259.GA24744@phdru.name> <mt9nfp$1u9$1@ger.gmane.org>
 <CAP7+vJJ68uYc7hsVSkGtKN2LzdjnWQc0HYrmSRNTzwjstzrJBw@mail.gmail.com>
 <mt9o81$dmv$1@ger.gmane.org>
Message-ID: <20150915184439.GA26346@phdru.name>

On Tue, Sep 15, 2015 at 08:32:33PM +0200, Georg Brandl <g.brandl at gmx.net> wrote:
> Fair enough. Still strange to read this PEP with the explicit caveat of
> "The author of the PEP doesn't currently plan to write a Process PEP on
> migration Python development from Mercurial to git."

   I am not a member of the core team, I certainly cannot write such a
Process PEP. But I very much hope to see one and help if I can.

> Georg
> 
> On 09/15/2015 08:22 PM, Guido van Rossum wrote:
> > For one, because *I* have been a (moderate) advocate for switching to git and
> > GitHub.
> > 
> > On Tue, Sep 15, 2015 at 11:19 AM, Georg Brandl <g.brandl at gmx.net
> > <mailto:g.brandl at gmx.net>> wrote:
> > 
> >     On 09/15/2015 08:02 PM, Oleg Broytman wrote:
> >     > On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson <benjamin at python.org <mailto:benjamin at python.org>> wrote:
> >     >> This looks like good information, but why is it a PEP? If anything, the
> >     >> devguide was probably be more appropriate. But even that's strange
> >     >> considering we don't use git at the moment.
> >     >
> >     >    Exactly because the core team doesn't use git the information doesn't
> >     > belong to the current revision of Developer's Guide.
> > 
> >     And if it doesn't propose to make the core team use git, why is it a PEP?

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From rdmurray at bitdance.com  Tue Sep 15 20:47:44 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 15 Sep 2015 14:47:44 -0400
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <mt9o81$dmv$1@ger.gmane.org>
References: <20150912135451.GA13004@phdru.name>
 <20150912135641.GB13004@phdru.name>
 <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>
 <20150915180259.GA24744@phdru.name> <mt9nfp$1u9$1@ger.gmane.org>
 <CAP7+vJJ68uYc7hsVSkGtKN2LzdjnWQc0HYrmSRNTzwjstzrJBw@mail.gmail.com>
 <mt9o81$dmv$1@ger.gmane.org>
Message-ID: <20150915184744.94E09B200B4@webabinitio.net>

On Tue, 15 Sep 2015 20:32:33 +0200, Georg Brandl <g.brandl at gmx.net> wrote:
> On 09/15/2015 08:22 PM, Guido van Rossum wrote:
> > For one, because *I* have been a (moderate) advocate for switching to git and
> > GitHub.
>
> Fair enough. Still strange to read this PEP with the explicit caveat of
> "The author of the PEP doesn't currently plan to write a Process PEP on
> migration Python development from Mercurial to git."

I understood this to mean he's providing the info that would be needed
for writing a process PEP, but as an informational PEP because there's
no other place it fits better and Guido would like to have it on record,
but isn't himself planning to propose a switch *at the moment*, thus
cutting off panic from the community that there was an immanent proposal
to switch.

--David

From raf at durin42.com  Tue Sep 15 21:44:28 2015
From: raf at durin42.com (Augie Fackler)
Date: Tue, 15 Sep 2015 19:44:28 +0000 (UTC)
Subject: [Python-Dev] PEP: Collecting information about git
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
Message-ID: <loom.20150915T210932-903@post.gmane.org>

Oleg Broytman <phd <at> phdru.name> writes:


>
> Hi!

Hi! I work on Mercurial. I?ve got some inline responses, but I want to
summarize and put this in context for those without much energy for the topic.

There are a lot of reasons to prefer one tool over another. Common ones are
familiarity, simplicity, and power. Version control debates often touch all
three of those points, and there?s often a _lot_ of misinformation thrown
around during the debate. It?s very clear to me based on this thread that
Oleg is not familiar with Mercurial -- everything listed as impossible is
not only doable in Mercurial, but not infrequently the command or flag is
*identically named*. I?m sending this mail not in an attempt to combat what
may be a healthy move for the your development community, but instead to
ensure that the right capability tradeoffs are seen during this process.

If the Python community wants to move to Git (or, as is more often the case
with such migrations, GitHub specifically - the choice of Git is often
totally unrelated to the popularity of the one particular host), it should
do so for good, clear reasons. That might be everyone thinking Git is a
better tool (to my own personal dismay, I?ll admit), or it might be that the
perceived network effects of being hosted on GitHub outweigh the switching
costs or difficulty of using a more complex tool.

>
> On Sun, Sep 13, 2015 at 09:14:58AM +1000, Tim Delaney <timothy.c.delaney
<at> gmail.com> wrote:
> > On 13 September 2015 at 04:42, Oleg Broytman <phd <at> phdru.name> wrote:
> >
> > >    There are too many things that I personally can do with git but can't
> > > do with hg. Because of that I switched all my development from hg to git
> > > and I am willing to help those who want to follow.
> >
> > Slightly off-topic, but personally I'd love to know what those are. I've
> > yet to find anything in Git that I haven't been able to do at least as well
> > with Mercurial (or an extension), and there are things Mercurial
> > supports that I use extensively (in particular named branches and phases)
> > where the concept doesn't even exist in Git.
>

[elided much that is strictly personal preference, plus some personal history]

>    Git fixed all the problems I had with hg. Its branching model suits
> my understanding of branches much better.

So use bookmarks. They're almost identical.

> With git we can have
> per-directory .gitignore and .gitattributes. Lightweight and annotated
> tags point exactly to the commits they tag.

I'm chalking these up to personal taste, but know that the tagging behavior
of git vs hg is a very complicated tradeoff. Mercurial chose a path that
makes tags audit-able in the future, whereas in Git a tag could disappear
and it'd be hard to prove.


> Ability to pull and push between unrelated repos.

In my opinion, this is honestly a misfeature, but Mercurial absolutely can
do it:  `hg pull --force` will do what you want.

>    I learned commit editing and found that it was the thing I wanted so
> badly in hg. When I started Mercurial was at version 1.7 and there was
> no commit editing at all; there was ``hg rollback`` but it only could
> undo one transaction.

Please forget rollback exists. It's dangerous, and we're hiding it from new
users for a reason. :)
> Later Mercurial learned commit editing,
> unwillingly perhaps,

Not at all unwillingly, we're just trying to be deliberate about it. We
wanted to make sure that we *both* enabled editing by default, *and* make it
impossible for a user to lose data. Getting that right took time, but we
think the wait has been worth it. If you want a preview of where we?re
headed, take a look at
https://mercurial.selenic.com/wiki/ChangesetEvolution. Parts of it have
shipped, and the whole concept is making steady progress.

> but git is still better at it: ``git add -p``
> allows me to review and edit patches before commit while ``hg record``
> commits immediately.

FWIW, I totally *get* wanting a staging area. That said, other than the
staging area, record (aka commit --interactive) and git add -p are identical
functionality-wise. We also now ship (at least as of 3.5) a curses UI for
record, which is quite nice.

>    Git is powerful. Even now, at version 3.1 ``hg help log`` lists about
> a dozen of options; ``git help log`` gives me about 60 pages of
> documentation.

Counting number of command line flags is a horrible way to compare power of
the tool. It reflects complexity, not power.

Mercurial has two major concepts--revsets and templates--that repeat over
and over, and which eliminate the need for many command-line flags that Git
has to include. I?ll give some examples below, but I?d also like to point
out that if you'd read recent Mercurial (3.5 is current - you looked at a
version that?s over a year old by now) output for 'hg help log', you'd find
many options are quite powerful. See below.

> I do not use all of them but I very much like
> ``git log --decorate``

This can be done with our templating system - I even have it in my hgrc. We
should include some better templates with hg, so I'll take an action item
here on this, but it's possible.

> ``--graph``

Had this for years and it?s even the same option!

> ``--grep=`` (and all related search options,
> especially ``-G``)

Remember how I mentioned revsets replace a lot of Git command line flags?
This is an example. hg help -r 'grep(foo)'. See also `hg help revsets`,
which are a very rich query system for revision history usable throughout
mercurial rather than only in log.

> ``--pretty``, ``--oneline``,

These are again just templates. `hg help templating`, and see above about us
maybe wanting some more built-in styles.

> ``--encoding=`` (I
> often use koi8-r instead of utf-8),

I believe we normoally infer encoding from your locale. Is that the wrong
thing for you for some reason?

That said, ?hg help -v | grep encoding? would have helped you find our
`--encoding` flag.

> ``--color``

[extensions]
color=

(shipped with hg for years, off by default because it breaks poorly written
scripts)

> and ``--word-diff``. I
> like ``git grep``, especially in the form ``git grep -Ovim``.

I'll admit, git-grep is a decent feature, but I find grep(1) or ack to be
just fine.

> I don't
> know what are the equivalent commands for ``git commit -c HEAD~``

hg commit --amend, or use hg histedit (which is like rebase -i)

> or
> ``git diff --name-only``.

hg status --no-status

>    Git has a lot of good documentation.

Honestly so does Mercurial.

[elided anecdote]

>
>    As I stopped using Mercurial I do not understand what phases are.
> they are phases of commit according to what? To the origin (let me
> borrow the word from git terminology)?

Commits seen in the main public repository are marked as public, and
Mercurial refuses to edit them. Most history rewriting woes happen when
people rewrite widely shared history and force push the new version.
Disallowing non-fast-forward push on the server prevents the rewriting from
propagating unintentionally. Phases proactively prevent users from shooting
themselves in the foot.

More details here https://www.logilab.org/blogentry/88203


>
>    Mercurial, for sure, has some advantages. It is written in Python.
> That's important. That's important for ideological reasons. That's also
> important because hg runs natively under Windows, it even has code for
> working with case-insensitive filesystems.
>    There are Mercurial Queues.
>    There are also small advantages like better polished command-line
> interface and ability to shorten command names and options to a unique
> prefix.

I'd actually go so far as saying that a better polished CLI is a *huge* win,
and the fact Mercurial's Windows support is more mature is also a pretty big
win for something cross-platform.

You?re talking about a tool that you use every day. Having a good UI
out-of-the-box is a huge benefit in that situation. Honestly, having a good
UI is part of why Python itself became so popular.

Sometimes, you have to give up power to get an easier user interface, but I
hope I?ve shown in this email that Mercurial gives you both a better UI, and
more power. There is no sacrifice other than familiarity--and because
Mercurial indeed has as simpler UI, closing the familiarity gap from Git to
Mercurial is much easier than the other way around.

If Python crew wants to go to Git, then it should go to Git, but it should
want to go for legitimate reasons--not a misguided belief that Git can do
things Mercurial cannot.

>
> > Tim Delaney
>
> Oleg.




From larry at hastings.org  Tue Sep 15 23:41:54 2015
From: larry at hastings.org (Larry Hastings)
Date: Tue, 15 Sep 2015 22:41:54 +0100
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAP7+vJJ68uYc7hsVSkGtKN2LzdjnWQc0HYrmSRNTzwjstzrJBw@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <20150912135641.GB13004@phdru.name>
 <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>
 <20150915180259.GA24744@phdru.name> <mt9nfp$1u9$1@ger.gmane.org>
 <CAP7+vJJ68uYc7hsVSkGtKN2LzdjnWQc0HYrmSRNTzwjstzrJBw@mail.gmail.com>
Message-ID: <55F890A2.7080604@hastings.org>


I don't follow.  Because you're an advocate of Python switching to git 
and GitHub, we should have a git tutorial committed as a Python 
Enhancement Proposal?

I'm not attempting to stir up a conversation about git vs hg.  I only 
question the idea that a git tutorial should be a PEP, when it has 
literally nothing to do with enhancing Python.  There are countless 
other venues through which Oleg could publish this information--a blog, 
a wiki, or even a series of postings to this newsgroup. I would 
encourage him to withdraw the PEP and publish through one of those.


//arry/

On 09/15/2015 07:22 PM, Guido van Rossum wrote:
> For one, because *I* have been a (moderate) advocate for switching to 
> git and GitHub.
>
> On Tue, Sep 15, 2015 at 11:19 AM, Georg Brandl <g.brandl at gmx.net 
> <mailto:g.brandl at gmx.net>> wrote:
>
>     On 09/15/2015 08:02 PM, Oleg Broytman wrote:
>     > On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson
>     <benjamin at python.org <mailto:benjamin at python.org>> wrote:
>     >> This looks like good information, but why is it a PEP? If
>     anything, the
>     >> devguide was probably be more appropriate. But even that's strange
>     >> considering we don't use git at the moment.
>     >
>     >    Exactly because the core team doesn't use git the information
>     doesn't
>     > belong to the current revision of Developer's Guide.
>
>     And if it doesn't propose to make the core team use git, why is it
>     a PEP?
>
>     Georg
>
>     _______________________________________________
>     Python-Dev mailing list
>     Python-Dev at python.org <mailto:Python-Dev at python.org>
>     https://mail.python.org/mailman/listinfo/python-dev
>     Unsubscribe:
>     https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
>
>
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/larry%40hastings.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150915/a0b12c3a/attachment.html>

From phd at phdru.name  Wed Sep 16 00:09:04 2015
From: phd at phdru.name (Oleg Broytman)
Date: Wed, 16 Sep 2015 00:09:04 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <55F890A2.7080604@hastings.org>
References: <20150912135451.GA13004@phdru.name>
 <20150912135641.GB13004@phdru.name>
 <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>
 <20150915180259.GA24744@phdru.name> <mt9nfp$1u9$1@ger.gmane.org>
 <CAP7+vJJ68uYc7hsVSkGtKN2LzdjnWQc0HYrmSRNTzwjstzrJBw@mail.gmail.com>
 <55F890A2.7080604@hastings.org>
Message-ID: <20150915220904.GA754@phdru.name>

On Tue, Sep 15, 2015 at 10:41:54PM +0100, Larry Hastings <larry at hastings.org> wrote:
> 
> I don't follow.  Because you're an advocate of Python switching to
> git and GitHub, we should have a git tutorial committed as a Python
> Enhancement Proposal?
> 
> I'm not attempting to stir up a conversation about git vs hg.  I
> only question the idea that a git tutorial should be a PEP, when it
> has literally nothing to do with enhancing Python.  There are

   There are PEPs that enhance development process but not Python
itself. I consider the PEP one of those.

> countless other venues through which Oleg could publish this
> information--a blog, a wiki, or even a series of postings to this
> newsgroup. I would encourage him to withdraw the PEP and publish
> through one of those.
> 
> 
> //arry/
> 
> On 09/15/2015 07:22 PM, Guido van Rossum wrote:
> >For one, because *I* have been a (moderate) advocate for switching
> >to git and GitHub.
> >
> >On Tue, Sep 15, 2015 at 11:19 AM, Georg Brandl <g.brandl at gmx.net
> ><mailto:g.brandl at gmx.net>> wrote:
> >
> >    On 09/15/2015 08:02 PM, Oleg Broytman wrote:
> >    > On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson
> >    <benjamin at python.org <mailto:benjamin at python.org>> wrote:
> >    >> This looks like good information, but why is it a PEP? If
> >    anything, the
> >    >> devguide was probably be more appropriate. But even that's strange
> >    >> considering we don't use git at the moment.
> >    >
> >    >    Exactly because the core team doesn't use git the information
> >    doesn't
> >    > belong to the current revision of Developer's Guide.
> >
> >    And if it doesn't propose to make the core team use git, why is it
> >    a PEP?
> >
> >    Georg
> >-- 
> >--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From rosuav at gmail.com  Wed Sep 16 02:20:53 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 16 Sep 2015 10:20:53 +1000
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <loom.20150915T210932-903@post.gmane.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
Message-ID: <CAPTjJmpss7jjJWAUg0mbLDE9+PoXZg12Put7fqrxpiOomfBkOQ@mail.gmail.com>

On Wed, Sep 16, 2015 at 5:44 AM, Augie Fackler <raf at durin42.com> wrote:
>> but git is still better at it: ``git add -p``
>> allows me to review and edit patches before commit while ``hg record``
>> commits immediately.
>
> FWIW, I totally *get* wanting a staging area. That said, other than the
> staging area, record (aka commit --interactive) and git add -p are identical
> functionality-wise. We also now ship (at least as of 3.5) a curses UI for
> record, which is quite nice.

Looks like it's time I spun up my own hg, rather than using the 3.1.2
that ships with Debian. A better UI for interactive (partial) commits
would go a long way toward filling the hole left by not having a
staging area; though I'll still miss it, some, in the most complicated
cases (where I use 'git gui' to stage and unstage bits, then check in
'gitk' that it looks right, continue until happy). Fortunately the
complicated cases are rare, but when my non-technical mother or my
technical-but-decades-out-of-date father needs help fixing up a
repository problem, I make good use of git's staging power.

Mentioning in the PEP that some of these things are available as of
version X might help bridge the gap between one author's knowledge and
a core dev's skills.

ChrisA

From ncoghlan at gmail.com  Wed Sep 16 02:29:30 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Sep 2015 10:29:30 +1000
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <55F890A2.7080604@hastings.org>
References: <20150912135451.GA13004@phdru.name>
 <20150912135641.GB13004@phdru.name>
 <1442335615.640445.384388065.65D13602@webmail.messagingengine.com>
 <20150915180259.GA24744@phdru.name> <mt9nfp$1u9$1@ger.gmane.org>
 <CAP7+vJJ68uYc7hsVSkGtKN2LzdjnWQc0HYrmSRNTzwjstzrJBw@mail.gmail.com>
 <55F890A2.7080604@hastings.org>
Message-ID: <CADiSq7cC5OFM+VF1Sq1H+Qeux+CRKshUweZ0jfnJwn06O+TZ-Q@mail.gmail.com>

On 16 Sep 2015 7:43 am, "Larry Hastings" <larry at hastings.org> wrote:
>
>
> I don't follow.  Because you're an advocate of Python switching to git
and GitHub, we should have a git tutorial committed as a Python Enhancement
Proposal?
>
> I'm not attempting to stir up a conversation about git vs hg.  I only
question the idea that a git tutorial should be a PEP, when it has
literally nothing to do with enhancing Python.  There are countless other
venues through which Oleg could publish this information--a blog, a wiki,
or even a series of postings to this newsgroup. I would encourage him to
withdraw the PEP and publish through one of those.

PEP 481 proposes moving the core workflow to a GitHub backed Phabricator
instance, so I see some utility in having an informational PEP that
collects details on the practical benefits folks see in git over hg. For
cases where the perception is incorrect, we can note that too, and improve
the dev guide accordingly (the Mercurial folks may also find out useful in
improving their tutorials and default settings)

For example, your 3.5.0 release process experiment highlighted some of the
problems with BitBucket's Mercurial pull requests being incorrectly
implemented atop named branches rather than bookmarks:
https://bitbucket.org/site/master/issues/6705/cant-create-pull-request-from-hg-bookmark

This means if folks are following Atlassian's lead and using branches in
Mercurial when bookmarks would be more appropriate, they're going to
encounter problems.

Cheers,
Nick.

>
>
> /arry
>
>
> On 09/15/2015 07:22 PM, Guido van Rossum wrote:
>>
>> For one, because *I* have been a (moderate) advocate for switching to
git and GitHub.
>>
>> On Tue, Sep 15, 2015 at 11:19 AM, Georg Brandl <g.brandl at gmx.net> wrote:
>>>
>>> On 09/15/2015 08:02 PM, Oleg Broytman wrote:
>>> > On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson <
benjamin at python.org> wrote:
>>> >> This looks like good information, but why is it a PEP? If anything,
the
>>> >> devguide was probably be more appropriate. But even that's strange
>>> >> considering we don't use git at the moment.
>>> >
>>> >    Exactly because the core team doesn't use git the information
doesn't
>>> > belong to the current revision of Developer's Guide.
>>>
>>> And if it doesn't propose to make the core team use git, why is it a
PEP?
>>>
>>> Georg
>>>
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/larry%40hastings.org
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150916/d5c5e3d4/attachment.html>

From raf at durin42.com  Wed Sep 16 04:14:55 2015
From: raf at durin42.com (Augie Fackler)
Date: Wed, 16 Sep 2015 02:14:55 +0000 (UTC)
Subject: [Python-Dev] PEP: Collecting information about git
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <CAPTjJmpss7jjJWAUg0mbLDE9+PoXZg12Put7fqrxpiOomfBkOQ@mail.gmail.com>
Message-ID: <loom.20150916T041314-300@post.gmane.org>

Chris Angelico <rosuav <at> gmail.com> writes:

> 
> On Wed, Sep 16, 2015 at 5:44 AM, Augie Fackler <raf <at> durin42.com> wrote:
> >> but git is still better at it: ``git add -p``
> >> allows me to review and edit patches before commit while ``hg record``
> >> commits immediately.
> >
> > FWIW, I totally *get* wanting a staging area. That said, other than the
> > staging area, record (aka commit --interactive) and git add -p are identical
> > functionality-wise. We also now ship (at least as of 3.5) a curses UI for
> > record, which is quite nice.
> 
> Looks like it's time I spun up my own hg, rather than using the 3.1.2
> that ships with Debian.

Clone https://selenic.com/hg and run `make deb` - it's not quite done
(doesn't include system configs for using the ca-certificates files for ssl
trust), but it should give you usable debs on your system. Please let me
know if it doesn't work for you!

(Note that I'm not subbed to python-devel, so you'll get faster service by
leaving me cc'ed on the thread.)

> A better UI for interactive (partial) commits
> would go a long way toward filling the hole left by not having a
> staging area; though I'll still miss it, some, in the most complicated
> cases (where I use 'git gui' to stage and unstage bits, then check in
> 'gitk' that it looks right, continue until happy). Fortunately the
> complicated cases are rare, but when my non-technical mother or my
> technical-but-decades-out-of-date father needs help fixing up a
> repository problem, I make good use of git's staging power.
> 
> Mentioning in the PEP that some of these things are available as of
> version X might help bridge the gap between one author's knowledge and
> a core dev's skills.
> 
> ChrisA
> 





From Nikolaus at rath.org  Wed Sep 16 04:37:19 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Tue, 15 Sep 2015 19:37:19 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAPTjJmpss7jjJWAUg0mbLDE9+PoXZg12Put7fqrxpiOomfBkOQ@mail.gmail.com>
 (Chris Angelico's message of "Wed, 16 Sep 2015 10:20:53 +1000")
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <CAPTjJmpss7jjJWAUg0mbLDE9+PoXZg12Put7fqrxpiOomfBkOQ@mail.gmail.com>
Message-ID: <87a8sndr8g.fsf@vostro.rath.org>

On Sep 16 2015, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Sep 16, 2015 at 5:44 AM, Augie Fackler <raf at durin42.com> wrote:
>>> but git is still better at it: ``git add -p``
>>> allows me to review and edit patches before commit while ``hg record``
>>> commits immediately.
>>
>> FWIW, I totally *get* wanting a staging area. That said, other than the
>> staging area, record (aka commit --interactive) and git add -p are identical
>> functionality-wise. We also now ship (at least as of 3.5) a curses UI for
>> record, which is quite nice.
>
> Looks like it's time I spun up my own hg, rather than using the 3.1.2
> that ships with Debian. A better UI for interactive (partial) commits
> would go a long way toward filling the hole left by not having a
> staging area;

You don't need to update Mercurial, it sufficient to install the
Tortoisehg frontend (unless you really want a curses interface,
Tortoisehg is X11). Give it a shot!

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From python-ideas at mgmiller.net  Wed Sep 16 05:03:27 2015
From: python-ideas at mgmiller.net (Mike Miller)
Date: Tue, 15 Sep 2015 20:03:27 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAPTjJmpss7jjJWAUg0mbLDE9+PoXZg12Put7fqrxpiOomfBkOQ@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <CAPTjJmpss7jjJWAUg0mbLDE9+PoXZg12Put7fqrxpiOomfBkOQ@mail.gmail.com>
Message-ID: <55F8DBFF.8040708@mgmiller.net>

Mercurial is easier to use (for cases outside linux kernel development).  It's 
too bad the gravity of GitHub tends to override that.

-Mike


On 09/15/2015 05:20 PM, Chris Angelico wrote:
> Looks like it's time I spun up my own hg, rather than using the 3.1.2
> that ships with Debian.

? sudo pip install -U mercurial

   Downloading mercurial-3.5.1.tar.gz (4.4MB): 4.4MB downloaded
   Running setup.py (path:/tmp/pip_build_root/mercurial/setup.py) egg_info for 
package mercurial...


From stephen at xemacs.org  Wed Sep 16 07:10:07 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 16 Sep 2015 14:10:07 +0900
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <loom.20150915T210932-903@post.gmane.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
Message-ID: <87k2rrx840.fsf@uwakimon.sk.tsukuba.ac.jp>

Augie Fackler writes:

 > There is no sacrifice [for git users moving to Mercurial] other
 > than familiarity--and because Mercurial indeed has as simpler UI,
 > closing the familiarity gap from Git to Mercurial is much easier
 > than the other way around.

AFAIK it is still much easier to do the kinds of things that "git
filter-branch" does in git than in hg.  (Haven't looked closely at hg's
capabilities since 3.2, though -- hg has been just fine for everyday
work on hg-using projects for years IMO.)  OTOH, I don't think that's
relevant to Python development, and probably the majority of VCS users
consider it an abomination.

 > If Python crew wants to go to Git, then it should go to Git, but it
 > should want to go for legitimate reasons--not a misguided belief
 > that Git can do things Mercurial cannot.

+1  I've always liked git (I was the git proponent for PEP 374), but
even at that time, the kinds of things that the vast majority of
Python developers do the vast majority of the time were equally
possible in git and hg.  The only thing that hg really lost badly on
IMO was "named branches", and that's been fixed with bookmarks.


From p.f.moore at gmail.com  Wed Sep 16 10:46:57 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 16 Sep 2015 09:46:57 +0100
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <87k2rrx840.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <87k2rrx840.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CACac1F_wintJUh5YfhE=KDy5tTjx=Yry_NUO1zZXcf_aaqqETw@mail.gmail.com>

On 16 September 2015 at 06:10, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>   The only thing that hg really lost badly on
> IMO was "named branches", and that's been fixed with bookmarks.

FWIW, I still find bookmarks confusing to use compared to git
branches. I don't know whether that's because bitbucket doesn't
support them well, or whether I don't know all the details of
bookmarks, but they just seem to get me in a muddle.

For example, my usual workflow is

(in a local clone of my fork on github)

git checkout -b featureX
... hack ...
git commit
git push -u origin featureX # Push the local branch to github and set
as remote tracking

# later, on a  different PC
git pull
git checkout featureX # Sets up a remote tracking branch
... hack ...
git commit
git push

# Finally, make a PR via the github UI

# Once the PR is accepted
git branch -d featureX # Remove my local branch, deleting all of the
no longer required changesets

I don't know of an equivalent of remote tracking branches in
Mercurial. Maybe bookmarks work that way by default? I seem to
remember that when I tried out bookmarks, bitbucket either didn't
support them, or did so pretty badly.

Also, my workflow involves 2 separate PCs, and I use my personal
github forks to share work in progress between them. Mercurial makes
it very difficult to edit "published" history, and I can't tell it
that my bitbucket repo doesn't count as "published" (as far as I
know). Git lets me do what I want (with some "are you sure?" prompts
when I force-push a rebased/edited branch, for example).

On the other hand, I *love* Mercurial queues. I'd happily use them for
work-in-progress editing as a replacement for some of my uses of git
branches. But they are essentially local-only, and it's basically not
practical to share them between my 2 PCs via bitbucket, as far as I
can tell. (I know you can version the patch queue, and share patch
queues on bitbucket, but it's under-documented and clumsy, whereas git
branches work exactly the same as they do locally...)

Having said all of this, the main reason I switched from Mercurial to
Git, like many others, was for github. Once I did, I learned how to do
a lot of things in git that I hadn't been able to do in Mercurial (it
was some time back, and they may not even have been possible, like
history editing) and now I find that even if Mercurial does have the
feature these days, the cost of learning how it works puts me off. So
my Mercurial use remains at the very basic "just enough to use it when
I have to" level.

Paul

From phd at phdru.name  Wed Sep 16 11:20:25 2015
From: phd at phdru.name (Oleg Broytman)
Date: Wed, 16 Sep 2015 11:20:25 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <loom.20150915T210932-903@post.gmane.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
Message-ID: <20150916092025.GA15714@phdru.name>

Hi!

On Tue, Sep 15, 2015 at 07:44:28PM +0000, Augie Fackler <raf at durin42.com> wrote:
> Hi! I work on Mercurial. I???ve got some inline responses, but I want to
> summarize and put this in context for those without much energy for the topic.

   Thank you!

> There are a lot of reasons to prefer one tool over another. Common ones are
> familiarity, simplicity, and power.

   Add here documentation, speed, availability of extensions and
3rd-party tools, hosting options (both locally installable and web
services).

> Oleg Broytman <phd <at> phdru.name> writes:
> > With git we can have
> > per-directory .gitignore and .gitattributes.

   No per-directory .hgignore? Never? Quite useful in a big project
where subproject live in subdirectories and are developed by separate
teams.

> > tags point exactly to the commits they tag.
> 
> I'm chalking these up to personal taste, but know that the tagging behavior
> of git vs hg is a very complicated tradeoff. Mercurial chose a path that
> makes tags audit-able in the future, whereas in Git a tag could disappear
> and it'd be hard to prove.

   I think signed tags can help.

> >    I learned commit editing and found that it was the thing I wanted so
> > badly in hg. When I started Mercurial was at version 1.7 and there was
> > no commit editing at all; there was ``hg rollback`` but it only could
> > undo one transaction.
> 
> Please forget rollback exists. It's dangerous, and we're hiding it from new
> users for a reason. :)

   Sure, I forgot them many years ago. ;-)

> > ``git add -p``
> > allows me to review and edit patches before commit while ``hg record``
> > commits immediately.
> 
> FWIW, I totally *get* wanting a staging area. That said, other than the
> staging area, record (aka commit --interactive) and git add -p are identical
> functionality-wise.

   Functionality-wise - yes, but staging area still makes the process
much more convenient.

> > ``git log --grep=`` (and all related search options,
> > especially ``-G``)
> 
> Remember how I mentioned revsets replace a lot of Git command line flags?
> This is an example. hg help -r 'grep(foo)'.

$ hg help -r 'grep(foo)'
hg help: option -r not recognized
hg help [-ec] [TOPIC]

> See also `hg help revsets`,
> which are a very rich query system for revision history usable throughout
> mercurial rather than only in log.

   What is the flag for case-insensitive grep()? For git log -Gregex?

> > I don't
> > know what are the equivalent commands for ``git commit -c HEAD~``
> 
> hg commit --amend, or use hg histedit (which is like rebase -i)

   No, they are not the same. AFAIK there are no equivalent options for
``git commit -Cc``.

> >    Git has a lot of good documentation.
> 
> Honestly so does Mercurial.

   It is harder to find. Mine installation has bash completion that
doesn't know "revsets" and "templates" though the help pages are there.
Actually it doesn't know much at all:

$ hg help [TAB][TAB]
add         cat         graft       log         record      summary
addremove   clone       grep        manifest    recover     tag
annotate    commit      heads       merge       remove      tags
archive     config      help        outgoing    rename      tip
backout     copy        identify    parents     resolve     transplant
bisect      diff        import      paths       revert      unbundle
bookmarks   export      incoming    phase       rollback    update
branch      fetch       init        pull        root        verify
branches    forget      l5          push        serve       version
bundle      glog        locate      qrecord     status

$ git help [TAB][TAB]
Display all 180 possibilities? (y or n)

   Another sign of git complexity. Sigh. :-(

> >    As I stopped using Mercurial I do not understand what phases are.
> > they are phases of commit according to what? To the origin (let me
> > borrow the word from git terminology)?
> 
> Commits seen in the main public repository are marked as public, and
> Mercurial refuses to edit them. Most history rewriting woes happen when
> people rewrite widely shared history and force push the new version.
> Disallowing non-fast-forward push on the server prevents the rewriting from
> propagating unintentionally. Phases proactively prevent users from shooting
> themselves in the foot.
> 
> More details here https://www.logilab.org/blogentry/88203

   Thanks. I think upstream remote-tracking branches in git are rather
similar. If one's afraid of rewriting published history she should never
rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
good enough.
   The biggest difference here is that git doesn't stop one to rebase
beyond @{upstream}.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From g.rodola at gmail.com  Wed Sep 16 11:26:50 2015
From: g.rodola at gmail.com (Giampaolo Rodola')
Date: Wed, 16 Sep 2015 11:26:50 +0200
Subject: [Python-Dev] congrats on 3.5! Alas,
 windows 7 users are having problems installing it
In-Reply-To: <201509132041.t8DKftII030747@fido.openend.se>
References: <201509132041.t8DKftII030747@fido.openend.se>
Message-ID: <CAFYqXL-8LOO89VVeECa9YjM6sJKG0QgYdUF33r08eU-gahKBuw@mail.gmail.com>

Same here. I get a "0x80240017 error" during installation.

On Sun, Sep 13, 2015 at 10:41 PM, Laura Creighton <lac at openend.se> wrote:

> webmaster has already heard from 4 people who cannot install it.
> I sent them to the bug tracker or to python-list but they seem
> not to have gone either place.  Is there some guide I should be
> sending them to, 'how to debug installation problems'?
>
> Laura
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
>



-- 
Giampaolo - http://grodola.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150916/a2f212af/attachment.html>

From rosuav at gmail.com  Wed Sep 16 11:27:12 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 16 Sep 2015 19:27:12 +1000
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150916092025.GA15714@phdru.name>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
Message-ID: <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>

On Wed, Sep 16, 2015 at 7:20 PM, Oleg Broytman <phd at phdru.name> wrote:
>    Thanks. I think upstream remote-tracking branches in git are rather
> similar. If one's afraid of rewriting published history she should never
> rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
> good enough.
>    The biggest difference here is that git doesn't stop one to rebase
> beyond @{upstream}.

Incidentally, "git rebase -i" with no argument defaults to rebasing
everything unpushed, which is exactly what you're talking about. But
yes, it's perfectly possible to rebase more than that, which I've done
extremely rarely but sufficiently often to appreciate it. Yes, there
are consequences. All magic comes with a price. But sometimes those
consequences are worth accepting.

With git, there are infinite workflows possible - you aren't forced to
have a concept of "central server" and "clients" the way you would
with SVN. Mercurial's called a DVCS too, so presumably it's possible
to operate on a pure-peering model with no central server at all; how
does that tie in with the inability to alter some commits?

ChrisA

From phd at phdru.name  Wed Sep 16 11:46:58 2015
From: phd at phdru.name (Oleg Broytman)
Date: Wed, 16 Sep 2015 11:46:58 +0200
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
Message-ID: <20150916094658.GA16932@phdru.name>

On Wed, Sep 16, 2015 at 07:27:12PM +1000, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Sep 16, 2015 at 7:20 PM, Oleg Broytman <phd at phdru.name> wrote:
> >    Thanks. I think upstream remote-tracking branches in git are rather
> > similar. If one's afraid of rewriting published history she should never
> > rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
> > good enough.
> >    The biggest difference here is that git doesn't stop one to rebase
> > beyond @{upstream}.
> 
> Incidentally, "git rebase -i" with no argument defaults to rebasing
> everything unpushed, which is exactly what you're talking about. But
> yes, it's perfectly possible to rebase more than that, which I've done
> extremely rarely but sufficiently often to appreciate it. Yes, there
> are consequences. All magic comes with a price. But sometimes those
> consequences are worth accepting.

   PEP 103 talks about consequences and price a lot, perhaps too much. :-)

> With git, there are infinite workflows possible - you aren't forced to
> have a concept of "central server" and "clients" the way you would
> with SVN. Mercurial's called a DVCS too, so presumably it's possible
> to operate on a pure-peering model with no central server at all; how
> does that tie in with the inability to alter some commits?

   Good question! In git, when you assign an upstream remote-tracking
branch (manually or automatically when cloning an existing repo) you're
essentially declare that remote the public repository on a per-branch
basis.

   But certainly there are distributed development scenarios where there
are no upstream remote-tracking branches at all. For example, I develop
SQLObject using two private clones (clean backup repo and dirty working
repo) and three public clones at Gitlab, GutHub and SourceForge. They
are all equal, none of them is the upstream. I don't even have
``origin`` remote - the origin was in Subversion.

> ChrisA

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From ncoghlan at gmail.com  Wed Sep 16 11:50:45 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Sep 2015 19:50:45 +1000
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CADiSq7cckfJjhT7Nj2Tuiq+LSW_BR2ZafzW7igNybZ4EoXCgkA@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <87k2rrx840.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CACac1F_wintJUh5YfhE=KDy5tTjx=Yry_NUO1zZXcf_aaqqETw@mail.gmail.com>
 <CADiSq7cckfJjhT7Nj2Tuiq+LSW_BR2ZafzW7igNybZ4EoXCgkA@mail.gmail.com>
Message-ID: <CADiSq7fDZESPbJsCCSYuhODmqtBkrdrk6rcMJc73ESWhy9goeQ@mail.gmail.com>

On 16 Sep 2015 18:48, "Paul Moore" <p.f.moore at gmail.com> wrote:
>
> On 16 September 2015 at 06:10, Stephen J. Turnbull <stephen at xemacs.org>
wrote:
> >   The only thing that hg really lost badly on
> > IMO was "named branches", and that's been fixed with bookmarks.
>
> FWIW, I still find bookmarks confusing to use compared to git
> branches. I don't know whether that's because bitbucket doesn't
> support them well,

It's BitBucket - their PR system for Mercurial primarily relies on named
branches rather than bookmarks. Gory details:
https://bitbucket.org/site/master/issues/6705/cant-create-pull-request-from-hg-bookmark

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150916/347471f3/attachment.html>

From rosuav at gmail.com  Wed Sep 16 11:59:28 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 16 Sep 2015 19:59:28 +1000
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150916094658.GA16932@phdru.name>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <20150916094658.GA16932@phdru.name>
Message-ID: <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>

On Wed, Sep 16, 2015 at 7:46 PM, Oleg Broytman <phd at phdru.name> wrote:
> For example, I develop
> SQLObject using two private clones (clean backup repo and dirty working
> repo) and three public clones at Gitlab, GutHub and SourceForge. They
> are all equal, none of them is the upstream. I don't even have
> ``origin`` remote - the origin was in Subversion.

Right. And even when you do have an 'origin' remote, you can pull from
anywhere else. (Internet connection's down? Pull from one computer
straight to another over the LAN. Want to quickly compare two messy
branches, without letting anyone else see them yet? Pull one of them
onto the other computer and poke around with fred/master and master.
Etcetera.) Deployment on Heroku can be done by setting up a remote and
then "git push heroku master". Does that make those commits
uneditable, or does "git push origin master" do that? I like the way
git lets you shoot yourself in the foot if you want to, while warning
you "your gun is currently pointing near your foot, please use --force
or --force-with-lease to pull the trigger".

But this is a bit off-topic for python-dev.

ChrisA

From rdmurray at bitdance.com  Wed Sep 16 15:34:29 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 16 Sep 2015 09:34:29 -0400
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <20150916094658.GA16932@phdru.name>
 <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>
Message-ID: <20150916133429.F193525100C@webabinitio.net>

On Wed, 16 Sep 2015 19:59:28 +1000, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Sep 16, 2015 at 7:46 PM, Oleg Broytman <phd at phdru.name> wrote:
> > For example, I develop
> > SQLObject using two private clones (clean backup repo and dirty working
> > repo) and three public clones at Gitlab, GutHub and SourceForge. They
> > are all equal, none of them is the upstream. I don't even have
> > ``origin`` remote - the origin was in Subversion.
> 
> Right. And even when you do have an 'origin' remote, you can pull from
> anywhere else. (Internet connection's down? Pull from one computer
> straight to another over the LAN. Want to quickly compare two messy
> branches, without letting anyone else see them yet? Pull one of them
> onto the other computer and poke around with fred/master and master.
> Etcetera.) Deployment on Heroku can be done by setting up a remote and
> then "git push heroku master". Does that make those commits
> uneditable, or does "git push origin master" do that? I like the way
> git lets you shoot yourself in the foot if you want to, while warning
> you "your gun is currently pointing near your foot, please use --force
> or --force-with-lease to pull the trigger".
> 
> But this is a bit off-topic for python-dev.

Yes is it, and no it isn't, if we are even thinking of moving to git.

My experience with DVCS started with bazaar, moved on to hg for the
CPython project, and finally git.  Through all of that I did not
understand the DAG, and had trouble wrapping my mind around what was
going on, despite being able to get things done.  I read a bunch of
documentation about all three systems, but it wasn't until I watched
another instructor teach the git DAG at a Software Carpentry workshop
that it all clicked.  Partially, I had been continually confused by the
concept of a "branch", since git uses that term differently than CVS,
svn, hg, or bazaar.  But once I understood it, suddenly everything
became clear.

The DAG plus git branches-as-labels *fits in my head* in a way that the
DAG plus named-branches-and-other-things does not.

I think that's really the key thing.  Sure, you can do the equivalent in
hg, but hg is not *oriented* toward that simple model.  git has a simple
model that my mind can wrap around and I can *reason about* easily.
Figuring out how feature branches and throwaway branches and remote
branches and pushes and pulls and workflows and whatever is all all just a
matter of reasoning about this simple model[*].

*That* I think is the key to git's success, *despite* its command line
API woes.  Not github, though github has magnified the effect.

The other key concept is what Chris talks about above, Mercurial's
"prevent me from shooting myself in the foot" stance versus git's "shoot
if you really want to" stance.

I think Mercurial is a great product, and has lots of really great
features, and I suspect that phases is a power tool that will enable
certain workflows that git won't support as well if at all.

But, I think Mercurial matches what we might call the "corporate"
mindset (prevent me from shooting myself in the foot) better than the
Python mindset.

Python strives to have a simple mental model you can reason about, and
it is a consenting adults language.  IMO, git matches the Python mindset
better than Mercurial does.

Now, does that mean that *the CPython project* should adopt git?  Not
necessarily.  CPython may be more like a big corporate project, where
centralized tracking of the main lines of development and not shooting
ourselves in the foot are the most important things :)

--David

[*] And then getting confused about how to *do* it in the CLI, but hey,
Google is my friend.

From barry at python.org  Wed Sep 16 16:13:44 2015
From: barry at python.org (Barry Warsaw)
Date: Wed, 16 Sep 2015 10:13:44 -0400
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150916133429.F193525100C@webabinitio.net>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <20150916094658.GA16932@phdru.name>
 <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>
 <20150916133429.F193525100C@webabinitio.net>
Message-ID: <20150916101344.12d333d7@limelight.wooz.org>

On Sep 16, 2015, at 09:34 AM, R. David Murray wrote:

>My experience with DVCS started with bazaar, moved on to hg for the
>CPython project, and finally git.  Through all of that I did not
>understand the DAG, and had trouble wrapping my mind around what was
>going on, despite being able to get things done.  I read a bunch of
>documentation about all three systems, but it wasn't until I watched
>another instructor teach the git DAG at a Software Carpentry workshop
>that it all clicked.  Partially, I had been continually confused by the
>concept of a "branch", since git uses that term differently than CVS,
>svn, hg, or bazaar.  But once I understood it, suddenly everything
>became clear.

The O'Reilly book on Git by Loeliger & McCullough really crystallized the git
model for me.  I have the 2nd edition from 2012.  I struggled quite a bit with
the dvcs model when I first started using bzr *many* years ago now, and even
though I was comfortable with it by the time I mostly switched to git, it
wasn't an entirely smooth transition.  This book had some of the best
descriptions and diagrams about what was going on, and I still find that it's
a great first-stop when trying to do something out of the ordinary with git.
Call me old skool but looking up something in the index can be faster than
using da googles. :)

Cheers,
-Barry

From raf at durin42.com  Wed Sep 16 16:24:30 2015
From: raf at durin42.com (Augie Fackler)
Date: Wed, 16 Sep 2015 14:24:30 +0000 (UTC)
Subject: [Python-Dev] PEP: Collecting information about git
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
Message-ID: <loom.20150916T161145-208@post.gmane.org>

Oleg Broytman <phd <at> phdru.name> writes:

> 
> Hi!
> 
> On Tue, Sep 15, 2015 at 07:44:28PM +0000, Augie Fackler <raf <at>
durin42.com> wrote:
> > Hi! I work on Mercurial. I???ve got some inline responses, but I want to
> > summarize and put this in context for those without much energy for the
topic.
> 
>    Thank you!
> 
> > There are a lot of reasons to prefer one tool over another. Common ones are
> > familiarity, simplicity, and power.
> 
>    Add here documentation, speed, availability of extensions and
> 3rd-party tools, hosting options (both locally installable and web
> services).
> 
> > Oleg Broytman <phd <at> phdru.name> writes:
> > > With git we can have
> > > per-directory .gitignore and .gitattributes.
> 
>    No per-directory .hgignore? Never? Quite useful in a big project
> where subproject live in subdirectories and are developed by separate
> teams.

I've honestly never found this a problem. Heck, I don't even know *how* I'd
go about configuring additional ignores in Google's enormous repository[0]
and it's never been a pain point to my knowledge. YMMV.

0: https://youtu.be/W71BTkUbdqE?t=193 for hard numbers that just got released.

> 
> > > tags point exactly to the commits they tag.
> > 
> > I'm chalking these up to personal taste, but know that the tagging behavior
> > of git vs hg is a very complicated tradeoff. Mercurial chose a path that
> > makes tags audit-able in the future, whereas in Git a tag could disappear
> > and it'd be hard to prove.
> 
>    I think signed tags can help.

No, actually, they don't. Signed tags let you have a slightly stronger
assertion that the currently-tagged thing is what should be tagged, but it
does *not* provide any way of validating that the thing tagged 1.2 last week
is still the thing tagged 1.2. In Mercurial, you'd have the audit log of
.hgtags being edited in history, or else some hashes changing. In git, a ref
moves (even in the signed tag case!) and that's all. I think tags even move
automatically on fetch, so if you don't notice when you fetch you just lost
the evidence of tampering.

(This is admittedly quite paranoid, but keep in mind that for some projects
"motivated nation-state" is their attacker model, so detecting tampering on
this level might be of value.)

> 
> > > ``git add -p``
> > > allows me to review and edit patches before commit while ``hg record``
> > > commits immediately.
> > 
> > FWIW, I totally *get* wanting a staging area. That said, other than the
> > staging area, record (aka commit --interactive) and git add -p are identical
> > functionality-wise.
> 
>    Functionality-wise - yes, but staging area still makes the process
> much more convenient.

For you. I find the staging area to merely get in my way. It's really a
matter of taste.

> 
> > > ``git log --grep=`` (and all related search options,
> > > especially ``-G``)
> > 
> > Remember how I mentioned revsets replace a lot of Git command line flags?
> > This is an example. hg help -r 'grep(foo)'.
> 
> $ hg help -r 'grep(foo)'
> hg help: option -r not recognized
> hg help [-ec] [TOPIC]

$ hg help -k grep
Topics:
          
 filesets Specifying File Sets
 revsets  Specifying Revision Sets

Commands:

 diff  diff repository (or selected files)
 files list tracked files
 grep  search for a pattern in specified files and revisions

You want revsets. help -k is your friend.

> 
> > See also `hg help revsets`,
> > which are a very rich query system for revision history usable throughout
> > mercurial rather than only in log.
> 
>    What is the flag for case-insensitive grep()? For git log -Gregex?
> 
> > > I don't
> > > know what are the equivalent commands for ``git commit -c HEAD~``
> > 
> > hg commit --amend, or use hg histedit (which is like rebase -i)
> 
>    No, they are not the same. AFAIK there are no equivalent options for
> ``git commit -Cc``.
> 
> > >    Git has a lot of good documentation.
> > 
> > Honestly so does Mercurial.
> 
>    It is harder to find. Mine installation has bash completion that
> doesn't know "revsets" and "templates" though the help pages are there.

Good point. http://bz.selenic.com/show_bug.cgi?id=4828 filed.

> Actually it doesn't know much at all:
> 
> $ hg help [TAB][TAB]
> add         cat         graft       log         record      summary
> addremove   clone       grep        manifest    recover     tag
> annotate    commit      heads       merge       remove      tags
> archive     config      help        outgoing    rename      tip
> backout     copy        identify    parents     resolve     transplant
> bisect      diff        import      paths       revert      unbundle
> bookmarks   export      incoming    phase       rollback    update
> branch      fetch       init        pull        root        verify
> branches    forget      l5          push        serve       version
> bundle      glog        locate      qrecord     status
> 
> $ git help [TAB][TAB]
> Display all 180 possibilities? (y or n)
> 
>    Another sign of git complexity. Sigh. 
> 
> > >    As I stopped using Mercurial I do not understand what phases are.
> > > they are phases of commit according to what? To the origin (let me
> > > borrow the word from git terminology)?
> > 
> > Commits seen in the main public repository are marked as public, and
> > Mercurial refuses to edit them. Most history rewriting woes happen when
> > people rewrite widely shared history and force push the new version.
> > Disallowing non-fast-forward push on the server prevents the rewriting from
> > propagating unintentionally. Phases proactively prevent users from shooting
> > themselves in the foot.
> > 
> > More details here https://www.logilab.org/blogentry/88203
> 
>    Thanks. I think upstream remote-tracking branches in git are rather
> similar. If one's afraid of rewriting published history she should never
> rebase before  <at> {u}. Just always using ``git rebase -i  <at> {u}``
should be
> good enough.

But you've now added another set of concepts that must be understood in
order to always use the tool safely - rather than opting in to danger with
Git, you have to opt in to safety. Mercurial tries to bias for defaulting
safe for the normal user, and making power available with a config knob for
those that want it.

>    The biggest difference here is that git doesn't stop one to rebase
> beyond  <at> {upstream}.

It's possible to rewrite this kind of history in Mercurial, but Mercurial
prevents you from performing an operation which will hurt collaboration with
others. This is an ideological difference.

> 
> Oleg.

BTW, if you can, I'd appreciate remaining on the CC list so I can respond
from my MUA instead of using gmane - I don't subscribe to python-devel, so I
only see responses in the web interface if I'm not cc'ed.





From Nikolaus at rath.org  Wed Sep 16 18:10:49 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Wed, 16 Sep 2015 09:10:49 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CACac1F_wintJUh5YfhE=KDy5tTjx=Yry_NUO1zZXcf_aaqqETw@mail.gmail.com>
 (Paul Moore's message of "Wed, 16 Sep 2015 09:46:57 +0100")
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <87k2rrx840.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CACac1F_wintJUh5YfhE=KDy5tTjx=Yry_NUO1zZXcf_aaqqETw@mail.gmail.com>
Message-ID: <87twqu4a5y.fsf@thinkpad.rath.org>

On Sep 16 2015, Paul Moore <p.f.moore at gmail.com> wrote:
> On 16 September 2015 at 06:10, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>>   The only thing that hg really lost badly on
>> IMO was "named branches", and that's been fixed with bookmarks.
>
> FWIW, I still find bookmarks confusing to use compared to git
> branches. I don't know whether that's because bitbucket doesn't
> support them well, or whether I don't know all the details of
> bookmarks, but they just seem to get me in a muddle.
>
> For example, my usual workflow is
>
> (in a local clone of my fork on github)
>
> git checkout -b featureX
> ... hack ...
> git commit
> git push -u origin featureX # Push the local branch to github and set
> as remote tracking
>
> # later, on a  different PC
> git pull
> git checkout featureX # Sets up a remote tracking branch
> ... hack ...
> git commit
> git push
>
> # Finally, make a PR via the github UI
>
> # Once the PR is accepted
> git branch -d featureX # Remove my local branch, deleting all of the
> no longer required changesets
>
> I don't know of an equivalent of remote tracking branches in
> Mercurial. Maybe bookmarks work that way by default?

Where exactly did you run into problems? I think you should have gotten
the same result with the following hg commands (if your remote is
non-ancient):

.. hack ..
hg commit
hg bookmark featureX
hg push -B featureX origin

# later
hg pull -B featureX origin
... hack ..
hg commit
hg push


The "remote tracking branch" in Mercurial always exists, but it doesn't
have a special name. In hg, branches do not need to have names, they are
identified by their commit id. Assigning names is pure convenience, this
is why they're called "bookmarks".

> Also, my workflow involves 2 separate PCs, and I use my personal
> github forks to share work in progress between them. Mercurial makes
> it very difficult to edit "published" history, and I can't tell it
> that my bitbucket repo doesn't count as "published" (as far as I
> know).

In general you can do that by configuring the repository with

      [phases]
      publish = False

However, I believe BitBucket doesn't allow you to do that. But that's
not hg's fault.

> Git lets me do what I want (with some "are you sure?" prompts
> when I force-push a rebased/edited branch, for example).

Same with hg. "hg phase -d -f <rev>" forces the status of "rev" to
'draft'.


Best,
-Nikolaus


-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From Nikolaus at rath.org  Wed Sep 16 18:14:38 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Wed, 16 Sep 2015 09:14:38 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 (Chris Angelico's message of "Wed, 16 Sep 2015 19:27:12 +1000")
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
Message-ID: <87oah249zl.fsf@thinkpad.rath.org>

On Sep 16 2015, Chris Angelico <rosuav at gmail.com> wrote:
> With git, there are infinite workflows possible - you aren't forced to
> have a concept of "central server" and "clients" the way you would
> with SVN. Mercurial's called a DVCS too, so presumably it's possible
> to operate on a pure-peering model with no central server at all; how
> does that tie in with the inability to alter some commits?

There is no inability to do so in hg either, you just need some --force
flags ("hg phase -f -d <rev>" should be enough in almost all cases).


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From Nikolaus at rath.org  Wed Sep 16 18:17:38 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Wed, 16 Sep 2015 09:17:38 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150916133429.F193525100C@webabinitio.net> (R. David Murray's
 message of "Wed, 16 Sep 2015 09:34:29 -0400")
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <20150916094658.GA16932@phdru.name>
 <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>
 <20150916133429.F193525100C@webabinitio.net>
Message-ID: <87lhc649ul.fsf@thinkpad.rath.org>

On Sep 16 2015, "R. David Murray" <rdmurray at bitdance.com> wrote:
> The DAG plus git branches-as-labels *fits in my head* in a way that the
> DAG plus named-branches-and-other-things does not.

Hmm, that's odd. As far as I know, the difference between the hg and git
DAG model can be summarized like this:

 * In git, leaves of the DAG must be assigned a name. If they don't have
   a name, they will be garbage collected. If they have a name, they are
   called a branch.

 * In hg, leaves of the DAG persist. If you want to remove them, you
   have to do so explicitly (hg strip), if you want them to have a name,
   you must do so explicitly (hg bookmark). A node of the DAG with a
   name is called a bookmark.

 * hg named branches have no equivalent in git. 

Does that help?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From brett at python.org  Wed Sep 16 18:56:54 2015
From: brett at python.org (Brett Cannon)
Date: Wed, 16 Sep 2015 16:56:54 +0000
Subject: [Python-Dev] congrats on 3.5! Alas,
 windows 7 users are having problems installing it
In-Reply-To: <CAFYqXL-8LOO89VVeECa9YjM6sJKG0QgYdUF33r08eU-gahKBuw@mail.gmail.com>
References: <201509132041.t8DKftII030747@fido.openend.se>
 <CAFYqXL-8LOO89VVeECa9YjM6sJKG0QgYdUF33r08eU-gahKBuw@mail.gmail.com>
Message-ID: <CAP1=2W4cfq0NP26+soos1WBVqaTX7_gLgPHrSHa6EsYnBge2aw@mail.gmail.com>

I don't see any issue opened about Windows 7 installation issues, so if
someone who has had the issue can thus can help Steve diagnose the problem
that would be great (Steve is also currently on vacation so having this all
in a bug that he can read when he gets back would also help).

On Wed, 16 Sep 2015 at 02:27 Giampaolo Rodola' <g.rodola at gmail.com> wrote:

> Same here. I get a "0x80240017 error" during installation.
>
> On Sun, Sep 13, 2015 at 10:41 PM, Laura Creighton <lac at openend.se> wrote:
>
>> webmaster has already heard from 4 people who cannot install it.
>> I sent them to the bug tracker or to python-list but they seem
>> not to have gone either place.  Is there some guide I should be
>> sending them to, 'how to debug installation problems'?
>>
>> Laura
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>>
> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
>>
>
>
>
> --
> Giampaolo - http://grodola.blogspot.com
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150916/7b688e45/attachment.html>

From rdmurray at bitdance.com  Wed Sep 16 19:34:35 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 16 Sep 2015 13:34:35 -0400
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <87lhc649ul.fsf@thinkpad.rath.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <20150916094658.GA16932@phdru.name>
 <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>
 <20150916133429.F193525100C@webabinitio.net>
 <87lhc649ul.fsf@thinkpad.rath.org>
Message-ID: <20150916173440.91C5325101E@webabinitio.net>

On Wed, 16 Sep 2015 09:17:38 -0700, Nikolaus Rath <Nikolaus at rath.org> wrote:
> On Sep 16 2015, "R. David Murray" <rdmurray at bitdance.com> wrote:
> > The DAG plus git branches-as-labels *fits in my head* in a way that the
> > DAG plus named-branches-and-other-things does not.
> 
> Hmm, that's odd. As far as I know, the difference between the hg and git
> DAG model can be summarized like this:
> 
>  * In git, leaves of the DAG must be assigned a name. If they don't have
>    a name, they will be garbage collected. If they have a name, they are
>    called a branch.
> 
>  * In hg, leaves of the DAG persist. If you want to remove them, you
>    have to do so explicitly (hg strip), if you want them to have a name,
>    you must do so explicitly (hg bookmark). A node of the DAG with a
>    name is called a bookmark.
> 
>  * hg named branches have no equivalent in git. 
> 
> Does that help?

Well, that last bullet kind of complicates the model, doesn't it?  :)
Especially when you add the fact that (IIUC) which named branch a commit
is on is recorded in the commit or something, which means the DAG is
more complicated than just being a DAG of commits.  The fact that I have
to worry about (remember to delete) branches I no longer want is also an
additional mental load, especially since (again, IIUC) I'd have to
figure out which commit I wanted to strip *from* in order to get rid of
an abandoned branch.

This is what I mean by hg not being *oriented* toward the simple model:
if I end up with extra heads in my cpython repo I treat this as a bug
that needs to be fixed.  In git, it's just a branch I'm working with and
later do something with...or delete, and git takes care of cleaning up
the orphaned commits for me.  I'm leery (wrongly, I suspect) of creating
branches in hg because they don't fit into my mental model of how I'm
working with the cpython repository and its named branches.  Now, is
that just a consequence of having learned mercurial in the context of how
CPython uses it?  I don't know.

As another example of this orientation issue, rebase was a big no-no in
hg when we started with it, and so I would only deal with patch sets (hg
diff to save a work in progress, reapply it later...a pattern I still
follow with cpython/hg) so that I didn't screw up my history.  In git,
it is the most natural thing in the world to take a branch you've been
working on and rebase it on to the point in the tree where you want to
commit it.  Even now I have to read carefully and think hard every time
I use the hg rebase command...I'm not sure why it is, but again it
doesn't fit in my head the way the git rebase does[*].

None of these things that mercurial does is *wrong*, and in fact they
are very useful in the right context.

The point is that the git model is *simple*.  Like I said, it fits
in my head.  I guess I have a small head :)

But, now the thread is again drifting away from how mercurial and git
relate to cpython development into simply how mercurial and git differ.

--David

[*] Note also that the hg help lacks the DAG examples that the current
git help has, and that it talks about "repeated merging" when what I
want to do is *move* the commits, I don't want to merge.  I think it
means exactly the same thing, but again it doesn't fit into my simple
git mental model of moving a branch of the DAG from here to there.

From stephen at xemacs.org  Wed Sep 16 19:36:50 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 17 Sep 2015 02:36:50 +0900
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <87lhc649ul.fsf@thinkpad.rath.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <20150916094658.GA16932@phdru.name>
 <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>
 <20150916133429.F193525100C@webabinitio.net>
 <87lhc649ul.fsf@thinkpad.rath.org>
Message-ID: <87zj0mw9jh.fsf@uwakimon.sk.tsukuba.ac.jp>

Nikolaus Rath writes:

 > Hmm, that's odd. As far as I know, the difference between the hg and git
 > DAG model can be summarized like this:
 > 
 >  * In git, leaves of the DAG must be assigned a name. If they don't have
 >    a name, they will be garbage collected.

You can turn off automatic garbage collection.  I usually do: it's
very unusual that I create millions of objects, or even megabytes
worth of objects, that I'm creating.

 >    If they have a name, they are called a branch.

Tags are also refs, the difference being that committing child of the
tip of the current branch advances the branch pointer, while that
won't happen with a tag.

 >  * In hg, leaves of the DAG persist. If you want to remove them, you
 >    have to do so explicitly (hg strip), if you want them to have a name,
 >    you must do so explicitly (hg bookmark). A node of the DAG with a
 >    name is called a bookmark.
 > 
 >  * hg named branches have no equivalent in git. 

And that's a very good thing.


From p.f.moore at gmail.com  Wed Sep 16 19:45:54 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 16 Sep 2015 18:45:54 +0100
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <87twqu4a5y.fsf@thinkpad.rath.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <87k2rrx840.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CACac1F_wintJUh5YfhE=KDy5tTjx=Yry_NUO1zZXcf_aaqqETw@mail.gmail.com>
 <87twqu4a5y.fsf@thinkpad.rath.org>
Message-ID: <CACac1F_fu=ugigzfNqJo8N55dA=rh=5gwrKcgyvFSZM+B08=VQ@mail.gmail.com>

On 16 September 2015 at 17:10, Nikolaus Rath <Nikolaus at rath.org> wrote:
>> I don't know of an equivalent of remote tracking branches in
>> Mercurial. Maybe bookmarks work that way by default?
>
> Where exactly did you run into problems? I think you should have gotten
> the same result with the following hg commands (if your remote is
> non-ancient):

I can't really recall. As I said, it was quite some time ago. And
probably long enough that bitbucket didn't support bookmarks, so your
"if your remote is non-ancient" may well be relevant.

One thing that I think I've got into trouble with:

I'm on revision X, which is at tip (master in git, the default branch
in Mercurial). I do git checkout -b foo (or hg bookmark foo). Now I
check in some changes. In git, I'm on branch foo and I can go back to
master with git checkout master. In Mercurial, I am at bookmark foo,
but where's the place I started from? The main line of development
(the default branch) doesn't have a bookmark, so I have to go hunting
for the revision I first switched to the bookmark at.

Similarly, if I'm at revision X, hg bookmark foo; hg bookmark bar
creates 2 bookmarks. If I then check in a change, I guess *both*
bookmarks move. In git, if I do git checkout -b foo; git checkout -b
bar, I have created two branches, and checkins now only go on bar. The
difference comes from the fact that in git, branches are "real
things", but in hg, bookmarks are names for points on the DAG - and in
this case, the DAG is completely linear so there's no way of capturing
the idea that a bookmark is starting a new branch in the DAG, unless
you actually create two commits based on the branch point.

See what I mean when I say I get confused? ;-)

> The "remote tracking branch" in Mercurial always exists, but it doesn't
> have a special name. In hg, branches do not need to have names, they are
> identified by their commit id. Assigning names is pure convenience, this
> is why they're called "bookmarks".

And yet branches are *not* simply names in git - a branch with no
commits on it is still distinct from its parent branch.

So conceptually, the idea that hg bookmarks and git branches are the
same thing, isn't actually true...

>> Also, my workflow involves 2 separate PCs, and I use my personal
>> github forks to share work in progress between them. Mercurial makes
>> it very difficult to edit "published" history, and I can't tell it
>> that my bitbucket repo doesn't count as "published" (as far as I
>> know).
>
> In general you can do that by configuring the repository with
>
>       [phases]
>       publish = False
>
> However, I believe BitBucket doesn't allow you to do that. But that's
> not hg's fault.

Well, yes and no. The fact that you have to edit the remote repository
before it will allow you to violate its "history is immutable"
principle is a feature of hg. I agree bitbucket limitations are also
relevant here (as I said, github's feature set was a major driver in
my switch, and that's not "the fault" of either tool). But hg is
(deliberately) opinionated on the right way to do things, and I do
find that those opinions get in the way of my preferred ways of
working at times.

>> Git lets me do what I want (with some "are you sure?" prompts
>> when I force-push a rebased/edited branch, for example).
>
> Same with hg. "hg phase -d -f <rev>" forces the status of "rev" to
> 'draft'.

My hg knowledge is out of date. I know phases make history editing
more flexible, but I've never learned it.

Paul

From raf at durin42.com  Wed Sep 16 21:22:51 2015
From: raf at durin42.com (Augie Fackler)
Date: Wed, 16 Sep 2015 19:22:51 +0000 (UTC)
Subject: [Python-Dev] PEP: Collecting information about git
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <87oah249zl.fsf@thinkpad.rath.org>
Message-ID: <loom.20150916T211921-648@post.gmane.org>

Nikolaus Rath <Nikolaus <at> rath.org> writes:

> 
> On Sep 16 2015, Chris Angelico <rosuav <at> gmail.com> wrote:
> > With git, there are infinite workflows possible - you aren't forced to
> > have a concept of "central server" and "clients" the way you would
> > with SVN. Mercurial's called a DVCS too, so presumably it's possible
> > to operate on a pure-peering model with no central server at all; how
> > does that tie in with the inability to alter some commits?
> 
> There is no inability to do so in hg either, you just need some --force
> flags ("hg phase -f -d <rev>" should be enough in almost all cases).

Actually, part of the value of phases is that it makes a truly decentralized
workflow easier to manage without errors. In Mercurial pre-phases and git,
you have to take some amount of care to avoid rebasing changes that you
pulled from an authoritative server - if you don't, you can end up with
weird history divergence that can be tricky to resolve. The addition of
phases helps the tool prevent accidental history editing.

As a concrete example, I pull from mpm's repo for Mercurial, but I push to a
repo of my own when I've reviewed patches or otherwise have work for him to
push to the authoritative one. More than once phases have prevented me from
rebasing his work onto my own, because I had a brain fart.

Does that help explain how it's a benefit in the decentralized case?

> 
> Best,
> -Nikolaus
> 





From lac at openend.se  Wed Sep 16 21:26:02 2015
From: lac at openend.se (Laura Creighton)
Date: Wed, 16 Sep 2015 21:26:02 +0200
Subject: [Python-Dev] congrats on 3.5! Alas,
	windows 7 users are having problems installing it
In-Reply-To: <CAP1=2W4cfq0NP26+soos1WBVqaTX7_gLgPHrSHa6EsYnBge2aw@mail.gmail.com>
References: <201509132041.t8DKftII030747@fido.openend.se>
 <CAFYqXL-8LOO89VVeECa9YjM6sJKG0QgYdUF33r08eU-gahKBuw@mail.gmail.com>
 <CAP1=2W4cfq0NP26+soos1WBVqaTX7_gLgPHrSHa6EsYnBge2aw@mail.gmail.com>
Message-ID: <201509161926.t8GJQ23k014169@fido.openend.se>

In a message of Wed, 16 Sep 2015 16:56:54 -0000, Brett Cannon writes:
>I don't see any issue opened about Windows 7 installation issues, so if
>someone who has had the issue can thus can help Steve diagnose the problem
>that would be great (Steve is also currently on vacation so having this all
>in a bug that he can read when he gets back would also help).

>> Same here. I get a "0x80240017 error" during installation.

Wearing my webmaster hat I talked to somebody who had this error with
their windows 8.1 install.  They wrote back that they had found this
on the net and following the sequence of things to do called 'Method
1'in http://wind8apps.com/error-0x80240017-windows/

fixed things  for them.

Laura

From pierre-yves.david at ens-lyon.org  Wed Sep 16 20:58:23 2015
From: pierre-yves.david at ens-lyon.org (Pierre-Yves David)
Date: Wed, 16 Sep 2015 11:58:23 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150916092025.GA15714@phdru.name>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
Message-ID: <55F9BBCF.3080007@ens-lyon.org>



On 09/16/2015 02:20 AM, Oleg Broytman wrote:
> Hi!
>
> On Tue, Sep 15, 2015 at 07:44:28PM +0000, Augie Fackler <raf at durin42.com> wrote:
>> Hi! I work on Mercurial. I???ve got some inline responses, but I want to
>> summarize and put this in context for those without much energy for the topic.
>
>     Thank you!
>
>> There are a lot of reasons to prefer one tool over another. Common ones are
>> familiarity, simplicity, and power.
>
>     Add here documentation, speed, availability of extensions and
> 3rd-party tools, hosting options (both locally installable and web
> services).
>
>> Oleg Broytman <phd <at> phdru.name> writes:
>>> With git we can have
>>> per-directory .gitignore and .gitattributes.
>
>     No per-directory .hgignore? Never? Quite useful in a big project
> where subproject live in subdirectories and are developed by separate
> teams.
>
>>> tags point exactly to the commits they tag.
>>
>> I'm chalking these up to personal taste, but know that the tagging behavior
>> of git vs hg is a very complicated tradeoff. Mercurial chose a path that
>> makes tags audit-able in the future, whereas in Git a tag could disappear
>> and it'd be hard to prove.
>
>     I think signed tags can help.
>
>>>     I learned commit editing and found that it was the thing I wanted so
>>> badly in hg. When I started Mercurial was at version 1.7 and there was
>>> no commit editing at all; there was ``hg rollback`` but it only could
>>> undo one transaction.
>>
>> Please forget rollback exists. It's dangerous, and we're hiding it from new
>> users for a reason. :)
>
>     Sure, I forgot them many years ago. ;-)
>
>>> ``git add -p``
>>> allows me to review and edit patches before commit while ``hg record``
>>> commits immediately.
>>
>> FWIW, I totally *get* wanting a staging area. That said, other than the
>> staging area, record (aka commit --interactive) and git add -p are identical
>> functionality-wise.
>
>     Functionality-wise - yes, but staging area still makes the process
> much more convenient.

Matter of habit probably. I find the staging area a significant 
annoyance for new users. I get the exact same process flexibility by 
amending my last commit over and over, interactively getting new stuff 
in and out of it. And having this extra context of stagging area is just 
a pain to me as you have to remember all this various config flag you 
have to use to see its content. The interactive tool around it are nice 
but they do not really need the staging area concept in itself to exists.

>>> ``git log --grep=`` (and all related search options,
>>> especially ``-G``)
>>
>> Remember how I mentioned revsets replace a lot of Git command line flags?
>> This is an example. hg help -r 'grep(foo)'.
>
> $ hg help -r 'grep(foo)'
> hg help: option -r not recognized
> hg help [-ec] [TOPIC]

I think Augie meant: hg log -r 'grep(foo)'

>> See also `hg help revsets`,
>> which are a very rich query system for revision history usable throughout
>> mercurial rather than only in log.
>
>     What is the flag for case-insensitive grep()? For git log -Gregex?

All revsets function matching string can have specific behavior. For 
exanple it can be turned into matching regex using "re:" prefix etc. 
This is global and unified.

>>>     As I stopped using Mercurial I do not understand what phases are.
>>> they are phases of commit according to what? To the origin (let me
>>> borrow the word from git terminology)?
>>
>> Commits seen in the main public repository are marked as public, and
>> Mercurial refuses to edit them. Most history rewriting woes happen when
>> people rewrite widely shared history and force push the new version.
>> Disallowing non-fast-forward push on the server prevents the rewriting from
>> propagating unintentionally. Phases proactively prevent users from shooting
>> themselves in the foot.
>>
>> More details here https://www.logilab.org/blogentry/88203
>
>     Thanks. I think upstream remote-tracking branches in git are rather
> similar. If one's afraid of rewriting published history she should never
> rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
> good enough.
>     The biggest difference here is that git doesn't stop one to rebase
> beyond @{upstream}.

I've to stop you right there. Mercurial is not forbidding you to do 
anything. You can trivially move phase backward and rewrite these 
changesets anyway.

Hg is not the inflexible corporate tool that limit what use can do while 
git would be the awesome free range developer tool.

Mercurial is just asserting that new users have probably a partial 
understanding of what they are doing and target to be safe by default, 
while still giving access to advance feature and work-flow to advanced 
users. My daily work-flow with mercurial would probably make most 
advance git user head hurts (And yet is nice a smooth down there ?).

-- 
Pierre-Yves David

From pierre-yves.david at ens-lyon.org  Wed Sep 16 21:14:27 2015
From: pierre-yves.david at ens-lyon.org (Pierre-Yves David)
Date: Wed, 16 Sep 2015 12:14:27 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150916092025.GA15714@phdru.name>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
Message-ID: <55F9BF93.3040603@ens-lyon.org>

(wonderfully forgot to address the point that triggered reply)

On 09/16/2015 02:20 AM, Oleg Broytman wrote:
>> Oleg Broytman <phd <at> phdru.name> writes:
>>> With git we can have
>>> per-directory .gitignore and .gitattributes.
>
>     No per-directory .hgignore? Never? Quite useful in a big project
> where subproject live in subdirectories and are developed by separate
> teams.

We have an inclusion mechanism that allow the top level .hgignore to 
include some other in subdirectory. This gives you the best of both 
world. skipping performance implication of subdirectory walking while 
allowing big enough subproject to have their own hgignore. Used in 
production with great success.

-- 
Pierre-Yves David

From raf at durin42.com  Wed Sep 16 21:26:34 2015
From: raf at durin42.com (Augie Fackler)
Date: Wed, 16 Sep 2015 19:26:34 +0000 (UTC)
Subject: [Python-Dev] PEP: Collecting information about git
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <87k2rrx840.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CACac1F_wintJUh5YfhE=KDy5tTjx=Yry_NUO1zZXcf_aaqqETw@mail.gmail.com>
 <87twqu4a5y.fsf@thinkpad.rath.org>
Message-ID: <loom.20150916T212456-801@post.gmane.org>

Nikolaus Rath <Nikolaus <at> rath.org> writes:

> 
> On Sep 16 2015, Paul Moore <p.f.moore <at> gmail.com> wrote:
> > On 16 September 2015 at 06:10, Stephen J. Turnbull <stephen <at>
xemacs.org> wrote:
> 
> In general you can do that by configuring the repository with
> 
>       [phases]
>       publish = False
> 
> However, I believe BitBucket doesn't allow you to do that. But that's
> not hg's fault.

Actually, BitBucket *does* support marking a repo as non-publishing. They
don't yet support exchanging the bit of metadata that lets obsolete draft
changes disappear, but I believe they have someone working on that now.

(I don't work for them, so I'm potentially working off of outdated rumors.)





From Nikolaus at rath.org  Wed Sep 16 22:38:41 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Wed, 16 Sep 2015 13:38:41 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CACac1F_fu=ugigzfNqJo8N55dA=rh=5gwrKcgyvFSZM+B08=VQ@mail.gmail.com>
 (Paul Moore's message of "Wed, 16 Sep 2015 18:45:54 +0100")
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <87k2rrx840.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CACac1F_wintJUh5YfhE=KDy5tTjx=Yry_NUO1zZXcf_aaqqETw@mail.gmail.com>
 <87twqu4a5y.fsf@thinkpad.rath.org>
 <CACac1F_fu=ugigzfNqJo8N55dA=rh=5gwrKcgyvFSZM+B08=VQ@mail.gmail.com>
Message-ID: <87d1xi3xri.fsf@thinkpad.rath.org>

On Sep 16 2015, Paul Moore <p.f.moore at gmail.com> wrote:
> I'm on revision X, which is at tip (master in git, the default branch
> in Mercurial). I do git checkout -b foo (or hg bookmark foo). Now I
> check in some changes. In git, I'm on branch foo and I can go back to
> master with git checkout master. In Mercurial, I am at bookmark foo,
> but where's the place I started from? The main line of development
> (the default branch) doesn't have a bookmark, so I have to go hunting
> for the revision I first switched to the bookmark at.

Yes - but you could bookmark it before committing, then you don't have
to hunt for it :-).

$ hg pull
$ hg bookmark "my-origin-branch"
$ hg bookmark "my-local-branch"
$ hg update -r my-local-branch
$ hg commit
$ hg update -r my-origin-branch

> Similarly, if I'm at revision X, hg bookmark foo; hg bookmark bar
> creates 2 bookmarks. If I then check in a change, I guess *both*
> bookmarks move.

No, only the active bookmark moves automatically:

$ hg bookmark foo
$ hg bookmark bar
$ hg log -r tip
changeset:   0:d1c121e915b8
bookmark:    bar
bookmark:    foo
tag:         tip
user:        Nikolaus Rath <Nikolaus at rath.org>
date:        Wed Sep 16 13:31:13 2015 -0700
files:       file
description:
initial commit


$ hg update -r foo
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
(activating bookmark foo)
$ echo barf > file
$ hg commit -m "Barf!"
file
committed changeset 1:ad44f9b935dc
$ hg log -r tip
changeset:   1:ad44f9b935dc
bookmark:    foo
tag:         tip
user:        Nikolaus Rath <Nikolaus at rath.org>
date:        Wed Sep 16 13:31:42 2015 -0700
files:       file
description:
Barf!

> In git, if I do git checkout -b foo; git checkout -b
> bar, I have created two branches, and checkins now only go on bar. The
> difference comes from the fact that in git, branches are "real
> things", but in hg, bookmarks are names for points on the DAG

You'll have to elaborate on that. What is it the difference between a
named leaf in the DAG and a branch that makes the branch "real"?

> See what I mean when I say I get confused? ;-)

I think what you mean is that you haven't read the Mercurial
documentation for quite some time :-).

>> The "remote tracking branch" in Mercurial always exists, but it doesn't
>> have a special name. In hg, branches do not need to have names, they are
>> identified by their commit id. Assigning names is pure convenience, this
>> is why they're called "bookmarks".
>
> And yet branches are *not* simply names in git - a branch with no
> commits on it is still distinct from its parent branch.
>
> So conceptually, the idea that hg bookmarks and git branches are the
> same thing, isn't actually true...

Well, the one thing were you thought they were different wasn't actually
the case. Is there another?

>>> Also, my workflow involves 2 separate PCs, and I use my personal
>>> github forks to share work in progress between them. Mercurial makes
>>> it very difficult to edit "published" history, and I can't tell it
>>> that my bitbucket repo doesn't count as "published" (as far as I
>>> know).
>>
>> In general you can do that by configuring the repository with
>>
>>       [phases]
>>       publish = False
>>
>> However, I believe BitBucket doesn't allow you to do that. But that's
>> not hg's fault.
>
> Well, yes and no. The fact that you have to edit the remote repository
> before it will allow you to violate its "history is immutable"

That's not true. You have to edit the remote repository only if you want
to edit history without --force.


Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From njs at pobox.com  Wed Sep 16 22:41:06 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 16 Sep 2015 13:41:06 -0700
Subject: [Python-Dev] [Numpy-discussion] The process I intend to follow
 for any proposed changes to NumPy
In-Reply-To: <CAMcnTE5V-ivCMkjSyaGAg-JUOqtfmBbxStvSoEt-L1zb2MPoqg@mail.gmail.com>
References: <CAMcnTE5V-ivCMkjSyaGAg-JUOqtfmBbxStvSoEt-L1zb2MPoqg@mail.gmail.com>
Message-ID: <CAPJVwBnJ88w+ppdqf28_Nfp4B2PjTexFEEUDriQ8PovDSWbneA@mail.gmail.com>

Hi all,

Thanks, Travis, for the followup. I know some people were confused or
concerned by some points in Travis?s recent emails (as was I,
initially), but after checking in with Travis and the NumPy steering
council, it sounds like the main points of possible confusion are
actually things where we at least are actually on the same page. So to
avoid any uncertainty or miscommunication, I just want to reiterate
some hopefully-uncontroversial points here:

- There is currently no plan whatsoever for NumPy to drop Python 2
support; something like ~80% of our users are still using Python 2,
and we anticipate that both Python 2 and Python 3 will continue to
receive full support for the foreseeable future.

- While it is possible that there will eventually be a
compatibility-breaking ?NumPy 2.0? release, it won?t happen without a
community consensus that this is a good idea, and that consensus has
not yet been reached.

- As a clarification on how NumPy governance works: While we all
continue to be grateful to Travis for his past contributions, in terms
of formal authority he stepped down from his leadership role in the
project several years ago, and the project has since switched to a
community-driven governance model [1]. Under this model, all
contributors participate as equal peers, and (outside of specific
exceptional circumstances) all contributors should be assumed to be
speaking only on behalf of themselves, not the project as a whole.

- Discussion about the best way to improve NumPy?s dtype system is
ongoing, and several approaches are under consideration. No proposal
will be accepted without review and consensus by the broader NumPy
community. We welcome anyone who?s interested in these issues to join
us on the mailing list -- the more input we have, the better the
result will be :-).

Apologies for the wide distribution of this message; I suggest any
followups be directed to numpy-discussion at scipy.org only.

Thanks,
- Nathaniel

[1] http://thread.gmane.org/gmane.comp.python.numeric.general/61106
(we?ll move it into the repository soon, we promise!)

On Sun, Sep 13, 2015 at 3:51 PM, Travis Oliphant <travis at continuum.io> wrote:
> Hey all,
>
> I just wanted to clarify, that I am very excited about a few ideas I have
> --- but I don't have time myself to engage in the community process to get
> these changes into NumPy.     However, those are real processes --- I've
> been coaching a few people in those processes for the past several years
> already.
>
> So, rather than do nothing, what I'm looking to do is to work with a few
> people who I can share my ideas with, get excited about the ideas, and then
> who will work with the community to get them implemented.   That's what I
> was announcing and talking about yesterday --- looking for interested people
> who want to work on NumPy *with* the NumPy community.
>
> In my enthusiasm, I realize that some may have mis-understood my intention.
> There is no 'imminent' fork, nor am I planning on doing some crazy amount of
> work that I then try to force on other developers of NumPy.
>
> What I'm planning to do is find people to train on NumPy code base (people
> to increase the diversity of the developers would be ideal -- but hard to
> accomplish).  I plan to train them on NumPy based on my experience, and on
> what I think should be done --- and then have *them* work through the
> community process and engage with others to get consensus (hopefully not
> losing too much in translation in the process --- but instead getting even
> better).
>
> During that process I will engage as a member of the community and help
> write NEPs and other documents and help clarify where it makes sense as I
> can.   I will be filtering for people that actually want to see NumPy get
> better.    Until I identify the people and work with them, it will be hard
> to tell how this will best work.   So, stay tuned.
>
> If all goes well, what you should see in a few weeks time are specific
> proposals, a branch or two, and the beginnings of some pull requests.    If
> you don't see that, then I will not have found the right people to help me,
> and we will all continue to go back to searching.
>
> While I'm expecting the best, in the worst case, we get additional people
> who know the NumPy code base and can help squash bugs as well as implement
> changes that are desired.    Three things are needed if you want to
> participate in this:  1) A willingness to work with the open source
> community, 2) a deep knowledge of C and in-particular CPython's brand of C,
> and 3) a willingness to engage with me, do a mind-meld and dump around the
> NumPy code base, and then improve on what is in my head with the rest of the
> community.
>
> Thanks,
>
> -Travis
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Nathaniel J. Smith -- http://vorpus.org

From Nikolaus at rath.org  Wed Sep 16 22:45:41 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Wed, 16 Sep 2015 13:45:41 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150916173440.91C5325101E@webabinitio.net> (R. David Murray's
 message of "Wed, 16 Sep 2015 13:34:35 -0400")
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <20150916094658.GA16932@phdru.name>
 <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>
 <20150916133429.F193525100C@webabinitio.net>
 <87lhc649ul.fsf@thinkpad.rath.org>
 <20150916173440.91C5325101E@webabinitio.net>
Message-ID: <87a8sm3xfu.fsf@thinkpad.rath.org>

On Sep 16 2015, "R. David Murray" <rdmurray at bitdance.com> wrote:
> On Wed, 16 Sep 2015 09:17:38 -0700, Nikolaus Rath <Nikolaus at rath.org> wrote:
>> On Sep 16 2015, "R. David Murray" <rdmurray at bitdance.com> wrote:
>> > The DAG plus git branches-as-labels *fits in my head* in a way that the
>> > DAG plus named-branches-and-other-things does not.
>> 
>> Hmm, that's odd. As far as I know, the difference between the hg and git
>> DAG model can be summarized like this:
>> 
>>  * In git, leaves of the DAG must be assigned a name. If they don't have
>>    a name, they will be garbage collected. If they have a name, they are
>>    called a branch.
>> 
>>  * In hg, leaves of the DAG persist. If you want to remove them, you
>>    have to do so explicitly (hg strip), if you want them to have a name,
>>    you must do so explicitly (hg bookmark). A node of the DAG with a
>>    name is called a bookmark.
>> 
>>  * hg named branches have no equivalent in git. 
>> 
>> Does that help?
>
> Well, that last bullet kind of complicates the model, doesn't it?  :)

Not if you come from git and want to use hg. You can just ignore
bookmarks.

But there is an easy explanation if you want one. Think of a named
branch as automatically appending "this went to <branchname>" to your
commit message.


> Especially when you add the fact that (IIUC) which named branch a commit
> is on is recorded in the commit or something, which means the DAG is
> more complicated than just being a DAG of commits

No, it's just some extra information in the commit. Like author, date,
or commit message.

> The fact that I have to worry about (remember to delete) branches I no
> longer want is also an additional mental load,

Yes, this is a disadvantage of Mercurial.

> especially since
> (again, IIUC) I'd have to figure out which commit I wanted to strip
> *from* in order to get rid of an abandoned branch.

..but this is not. You can easily automate that (though I don't
recommend typing in the expression by hand every time, the idea is to
tel hg to "delete this changeset and all ancestors until you reach an
ancestor that has more than one child").

> This is what I mean by hg not being *oriented* toward the simple model:
> if I end up with extra heads in my cpython repo I treat this as a bug
> that needs to be fixed.

But why?

> In git, it's just a branch I'm working with and
> later do something with...or delete, and git takes care of cleaning up
> the orphaned commits for me.

In hg it's exactly the same, it's just a head you're working with, and
later you can do something with it.. or delete it. If it helps, create a
cronjob that deletes all DAG leaves that don't have bookmarks.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From Nikolaus at rath.org  Wed Sep 16 22:47:20 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Wed, 16 Sep 2015 13:47:20 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <87zj0mw9jh.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's
 message of "Thu, 17 Sep 2015 02:36:50 +0900")
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <20150916094658.GA16932@phdru.name>
 <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>
 <20150916133429.F193525100C@webabinitio.net>
 <87lhc649ul.fsf@thinkpad.rath.org>
 <87zj0mw9jh.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <877fnq3xd3.fsf@thinkpad.rath.org>

On Sep 17 2015, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> Nikolaus Rath writes:
>
>  > Hmm, that's odd. As far as I know, the difference between the hg and git
>  > DAG model can be summarized like this:
>  > 
>  >  * In git, leaves of the DAG must be assigned a name. If they don't have
>  >    a name, they will be garbage collected.
>
> You can turn off automatic garbage collection.  I usually do: it's
> very unusual that I create millions of objects, or even megabytes
> worth of objects, that I'm creating.

Okay... (I don't quite see why this matters here).


>  >    If they have a name, they are called a branch.
>
> Tags are also refs, the difference being that committing child of the
> tip of the current branch advances the branch pointer, while that
> won't happen with a tag.

Yeah, it's like that both in hg and git, so I'm not quite sure what
you're trying to say...


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From tjreedy at udel.edu  Thu Sep 17 02:59:13 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 16 Sep 2015 20:59:13 -0400
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <loom.20150916T041314-300@post.gmane.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <CAPTjJmpss7jjJWAUg0mbLDE9+PoXZg12Put7fqrxpiOomfBkOQ@mail.gmail.com>
 <loom.20150916T041314-300@post.gmane.org>
Message-ID: <55FA1061.7080606@udel.edu>

On 9/15/2015 10:14 PM, Augie Fackler wrote:

> (Note that I'm not subbed to python-devel, so you'll get faster service by
> leaving me cc'ed on the thread.)

I am not either, because I read and post (since its beginning) via the 
gmane.comp.python.devel mirror at news.gmane.org.  Choose newsgroup or 
web interface.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Thu Sep 17 03:59:40 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 16 Sep 2015 21:59:40 -0400
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <20150916092025.GA15714@phdru.name>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
Message-ID: <mtd6re$imr$1@ger.gmane.org>

On 9/16/2015 5:20 AM, Oleg Broytman wrote:

> On Tue, Sep 15, 2015 at 07:44:28PM +0000, Augie Fackler <raf at durin42.com> wrote:

>> There are a lot of reasons to prefer one tool over another. Common ones are
>> familiarity, simplicity, and power.
>
>     Add here documentation, speed, availability of extensions and
> 3rd-party tools, hosting options (both locally installable and web
> services).

For me, the killer 3rd party tool in favor of hg is TortoiseHg, which I 
use on Windows. As far as I know (I did check a bit), there is no 
equivalent for git on Windows.  For me, the evaluation should be between 
hg+TortoiseHG versus git+???.

For instance, having the DAG nicely displayed is especially important 
given the CPython repository policy of 1 head per branch and all commits 
on maintenance branches merged forward. A week ago, someone left an 
unmerged 3.5 commit. When I opened THG and looked at the graph, it was 
immediately obvious.  About 6 clicks and it was merged forward, 
committed, and pushed. To me, the idea of having to instead type (and 
likely, mistype) 3 commands is unacceptible.

-- 
Terry Jan Reedy


From stephen at xemacs.org  Thu Sep 17 04:22:29 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 17 Sep 2015 11:22:29 +0900
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <87a8sm3xfu.fsf@thinkpad.rath.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <20150916094658.GA16932@phdru.name>
 <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>
 <20150916133429.F193525100C@webabinitio.net>
 <87lhc649ul.fsf@thinkpad.rath.org>
 <20150916173440.91C5325101E@webabinitio.net>
 <87a8sm3xfu.fsf@thinkpad.rath.org>
Message-ID: <87si6dwzru.fsf@uwakimon.sk.tsukuba.ac.jp>

Nikolaus Rath writes:

 > >>  * hg named branches have no equivalent in git. 
 > >> 
 > >> Does that help?
 > >
 > > Well, that last bullet kind of complicates the model, doesn't it?  :)
 > 
 > Not if you come from git and want to use hg. You can just ignore
 > bookmarks.

No, you cannot just ignore bookmarks (but who would want to?) or named
branches (and there's the rub because named branches don't branch,
they are a partition of the set of commits).

The problem is that git and hg are communication tools: between a
developer and himself over time, and between developers at the same
time.  If your project uses named branches, you have to use named
branches.  Bookmarks, ditto.

CPython's use of named branches is very disciplined and "discrete"
because they're widely separated in both commit space and mental
space, so is very unlikely to result in anomolies.  But use of named
branches for feature branches requires some care, especially if you
have long-lived features with individual "milestones" that can be
merge *to* trunk at intervals combined with a project workflow that
emphasizes the mainline.

 > But there is an easy explanation if you want one. Think of a named
 > branch as automatically appending "this went to <branchname>" to your
 > commit message.

No, that doesn't help the anomolies that occur at branch points and
merges, which can only be on one of the named branches (including the
implicit name).

 > No, it's just some extra information in the commit. Like author, date,
 > or commit message.

True, but it makes certain operations that filter on named branches
behave strangely (at least to me).

 > In hg it's exactly the same, it's just a head you're working with, and
 > later you can do something with it.. or delete it. If it helps, create a
 > cronjob that deletes all DAG leaves that don't have bookmarks.

Ugh.  What if that cron job runs while you're in the middle of merge?



From stephen at xemacs.org  Thu Sep 17 04:57:19 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 17 Sep 2015 11:57:19 +0900
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <877fnq3xd3.fsf@thinkpad.rath.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <20150916094658.GA16932@phdru.name>
 <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>
 <20150916133429.F193525100C@webabinitio.net>
 <87lhc649ul.fsf@thinkpad.rath.org>
 <87zj0mw9jh.fsf@uwakimon.sk.tsukuba.ac.jp>
 <877fnq3xd3.fsf@thinkpad.rath.org>
Message-ID: <87pp1hwy5s.fsf@uwakimon.sk.tsukuba.ac.jp>

Nikolaus Rath writes:
 > On Sep 17 2015, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
 > > Nikolaus Rath writes:
 > >
 > >  > Hmm, that's odd. As far as I know, the difference between the hg and git
 > >  > DAG model can be summarized like this:
 > >  > 
 > >  >  * In git, leaves of the DAG must be assigned a name. If they don't have
 > >  >    a name, they will be garbage collected.
 > >
 > > You can turn off automatic garbage collection.  I usually do: it's
 > > very unusual that I create millions of objects, or even megabytes
 > > worth of objects, that I'm creating.
 > 
 > Okay... (I don't quite see why this matters here).

Because it's very possible to have unnamed heads in git, although
naive usage in git doesn't create them.  The most common case used to
be after a rebase, but now the reflog provides a name and prevents
deletion for quite a while.  Now you have to do something weird like
delete a ref and change your mind, or commit to a detached HEAD and
then checkout something else.

Turning off GC is a very specialized taste, though.  I'm a packrat and
I'm also interested in workflow management (my day job is teaching
economics in a management school).  Spelunking in the detritus of my
work has made me more conscious of *how* I do various activities (not
limited to programming!), which helps in teaching others either to do
the same or to adapt my preferred workflows to their needs.

 > > >    If they have a name, they are called a branch.
 > >
 > > Tags are also refs, the difference being that committing child of the
 > > tip of the current branch advances the branch pointer, while that
 > > won't happen with a tag.
 > 
 > Yeah, it's like that both in hg and git, so I'm not quite sure what
 > you're trying to say...

Well, first of all tags in hg are *commits*, not refs.  That bugs git
people.

Second, "explicit is better than implicit".  In git, there's one
implicit object: the "cache", "index", or "staging area".  This
confuses a lot of people.  For example, "git diff" does NOT give a
diff against HEAD, it gives a diff against the staging area -- which
for my usual workflow which commits files by name is the same thing
because the staging area *equals* HEAD in that scenario.  But in cases
where I do use "git add", that's no longer true, and at first I was
surprised by the resulting diffs.[1]  In hg, there may be several
implicit objects, namely the unnamed heads.

I'm not going to insist on the importance of the *number* of implicit
objects (among other things, it's not obvious how many objects the
index should be counted as).  But what is implicit in git and hg is
*different*.  In git, heads are always explicitly named (even detached
heads have the name HEAD) when you want to operate on them.  In hg,
the most commonly used heads (the default branch and merge heads) are
not.  In hg, you don't have to worry about the difference between the
index (there is one: that's what things like "hg add" affect) and tip,
because the index isn't used implicitly by any commands (except
status, but that's a special case that isn't going to bother anybody).



Footnotes: [1] Now I find this useful, as I almost never make a
mistake with "git add <file>", and the diff against the index filters
out all the files I haven't decided about yet, as well as notifying me
that I've made changes -- often unintended -- to previously added
files.  But for me this was definitely an acquired taste, it wasn't
natural at first.


From Nikolaus at rath.org  Thu Sep 17 05:04:14 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Wed, 16 Sep 2015 20:04:14 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <87a8sm3xfu.fsf@thinkpad.rath.org> (Nikolaus Rath's message of
 "Wed, 16 Sep 2015 13:45:41 -0700")
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name>
 <CAPTjJmod3MxkDcVY8yGME-y2X2tfuLwRGiCQMWtjujb4xQCOZA@mail.gmail.com>
 <20150916094658.GA16932@phdru.name>
 <CAPTjJmp-s5YpGi_NuRGn2Y3yK2GSnMAAF-svTYtcS9FwrkHtOg@mail.gmail.com>
 <20150916133429.F193525100C@webabinitio.net>
 <87lhc649ul.fsf@thinkpad.rath.org>
 <20150916173440.91C5325101E@webabinitio.net>
 <87a8sm3xfu.fsf@thinkpad.rath.org>
Message-ID: <877fnpvj9t.fsf@vostro.rath.org>

On Sep 16 2015, Nikolaus Rath <Nikolaus at rath.org> wrote:
> On Sep 16 2015, "R. David Murray" <rdmurray at bitdance.com> wrote:
>> On Wed, 16 Sep 2015 09:17:38 -0700, Nikolaus Rath <Nikolaus at rath.org> wrote:
>>> On Sep 16 2015, "R. David Murray" <rdmurray at bitdance.com> wrote:
>>> > The DAG plus git branches-as-labels *fits in my head* in a way that the
>>> > DAG plus named-branches-and-other-things does not.
>>> 
>>> Hmm, that's odd. As far as I know, the difference between the hg and git
>>> DAG model can be summarized like this:
>>> 
>>>  * In git, leaves of the DAG must be assigned a name. If they don't have
>>>    a name, they will be garbage collected. If they have a name, they are
>>>    called a branch.
>>> 
>>>  * In hg, leaves of the DAG persist. If you want to remove them, you
>>>    have to do so explicitly (hg strip), if you want them to have a name,
>>>    you must do so explicitly (hg bookmark). A node of the DAG with a
>>>    name is called a bookmark.
>>> 
>>>  * hg named branches have no equivalent in git. 
>>> 
>>> Does that help?
>>
>> Well, that last bullet kind of complicates the model, doesn't it?  :)
>
> Not if you come from git and want to use hg. You can just ignore
> bookmarks.

Obviously, that should have read "..you can just ignore named branches".


Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From Nikolaus at rath.org  Thu Sep 17 05:11:44 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Wed, 16 Sep 2015 20:11:44 -0700
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <mtd6re$imr$1@ger.gmane.org> (Terry Reedy's message of "Wed, 16
 Sep 2015 21:59:40 -0400")
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name>
 <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name> <mtd6re$imr$1@ger.gmane.org>
Message-ID: <871tdxvixb.fsf@vostro.rath.org>

On Sep 16 2015, Terry Reedy <tjreedy at udel.edu> wrote:
> On 9/16/2015 5:20 AM, Oleg Broytman wrote:
>
>> On Tue, Sep 15, 2015 at 07:44:28PM +0000, Augie Fackler <raf at durin42.com> wrote:
>
>>> There are a lot of reasons to prefer one tool over another. Common ones are
>>> familiarity, simplicity, and power.
>>
>>     Add here documentation, speed, availability of extensions and
>> 3rd-party tools, hosting options (both locally installable and web
>> services).
>
> For me, the killer 3rd party tool in favor of hg is TortoiseHg, which
> I use on Windows. As far as I know (I did check a bit), there is no
> equivalent for git on Windows.

.. or elsewhere. Tortoisehg rocks.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From mail at timgolden.me.uk  Thu Sep 17 09:09:56 2015
From: mail at timgolden.me.uk (Tim Golden)
Date: Thu, 17 Sep 2015 08:09:56 +0100
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <mtd6re$imr$1@ger.gmane.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name> <mtd6re$imr$1@ger.gmane.org>
Message-ID: <55FA6744.6080909@timgolden.me.uk>

On 17/09/2015 02:59, Terry Reedy wrote:
> On 9/16/2015 5:20 AM, Oleg Broytman wrote:
> 
>> On Tue, Sep 15, 2015 at 07:44:28PM +0000, Augie Fackler
>> <raf at durin42.com> wrote:
> 
>>> There are a lot of reasons to prefer one tool over another. Common
>>> ones are
>>> familiarity, simplicity, and power.
>>
>>     Add here documentation, speed, availability of extensions and
>> 3rd-party tools, hosting options (both locally installable and web
>> services).
> 
> For me, the killer 3rd party tool in favor of hg is TortoiseHg, which I
> use on Windows. As far as I know (I did check a bit), there is no
> equivalent for git on Windows.  For me, the evaluation should be between
> hg+TortoiseHG versus git+???.

There certainly is (and with the obvious name!):

https://tortoisegit.org/

I use it every day

TJG

From p.andrefreitas at gmail.com  Thu Sep 17 09:17:34 2015
From: p.andrefreitas at gmail.com (=?UTF-8?Q?Andr=C3=A9_Freitas?=)
Date: Thu, 17 Sep 2015 07:17:34 +0000
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <871tdxvixb.fsf@vostro.rath.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name> <mtd6re$imr$1@ger.gmane.org>
 <871tdxvixb.fsf@vostro.rath.org>
Message-ID: <CAMkX=YXvShd++-UqK6=SfJpcWRoHzHaKdgRGNq1MAO9WPf64Pw@mail.gmail.com>

Regarding Git tools for Windows, GitHub Desktop and Sourcetree are actually
very good with nice features.

A Qui, 17/09/2015, 04:12, Nikolaus Rath <Nikolaus at rath.org> escreveu:

> On Sep 16 2015, Terry Reedy <tjreedy at udel.edu> wrote:
> > On 9/16/2015 5:20 AM, Oleg Broytman wrote:
> >
> >> On Tue, Sep 15, 2015 at 07:44:28PM +0000, Augie Fackler <
> raf at durin42.com> wrote:
> >
> >>> There are a lot of reasons to prefer one tool over another. Common
> ones are
> >>> familiarity, simplicity, and power.
> >>
> >>     Add here documentation, speed, availability of extensions and
> >> 3rd-party tools, hosting options (both locally installable and web
> >> services).
> >
> > For me, the killer 3rd party tool in favor of hg is TortoiseHg, which
> > I use on Windows. As far as I know (I did check a bit), there is no
> > equivalent for git on Windows.
>
> .. or elsewhere. Tortoisehg rocks.
>
> Best,
> -Nikolaus
>
> --
> GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
> Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
>
>              ?Time flies like an arrow, fruit flies like a Banana.?
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/p.andrefreitas%40gmail.com
>
-- 
Andr? Freitas
andrefreitas.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150917/dc9e305b/attachment-0001.html>

From barry at barrys-emacs.org  Thu Sep 17 11:13:47 2015
From: barry at barrys-emacs.org (Barry Scott)
Date: Thu, 17 Sep 2015 10:13:47 +0100
Subject: [Python-Dev] python windows installation inconsistent use of
	registry keys
In-Reply-To: <FAF389F0-07C6-4AB7-84A7-CD42E1BAB520@barrys-emacs.org>
References: <FAF389F0-07C6-4AB7-84A7-CD42E1BAB520@barrys-emacs.org>
Message-ID: <F6E70C30-9C3A-43C2-99EB-128D2E63F88F@barrys-emacs.org>


> On 15 Sep 2015, at 18:39, Barry Scott <barry at barrys-emacs.org> wrote:
> 
> I am used to looking in HKLM:\SOFTWARE\Python\PythonCore\%(py_maj)d.%(py_min)d\InstallPath
> to find out where python is installed so that my installation kit can add itself to site-packages.
> 
> I just found that the registry key used for 32 bit python 3.5 on windows changed to be '3.5-32',
> which I can change my installer to cope with.
> 
> However the key for the 64bit install is ?3.5? but not '3.5-64'.
> 
> Why was this changed and why not consistently between 32 and 64 bit versions?
> 

Raised as bug http://bugs.python.org/issue25148

> Barry
> PyCXX, PySVN maintainer
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/barry%40barrys-emacs.org


From bcannon at gmail.com  Thu Sep 17 20:40:25 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 17 Sep 2015 18:40:25 +0000
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
Message-ID: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>

I opened http://bugs.python.org/issue25154 for this idea and below is
what I put in the issue as to why I think we should deprecate the
pyvenv script in favour of `python3 -m venv`.


I propose that the pyvenv script be deprecated in Python 3.5.1 and
removed in Python 3.8. The reason for this proposal is because it is
non-obvious what version of Python a pyvenv command is tied to (heck,
it isn't necessarily obvious that it's Python 3). There would be no
loss in functionality since the exact same functionality is available
through `python3 -m venv`. This is a backwards-compatibility change,
hence the deprecation, but changing various shell scripts and such
should be trivial thanks to the -m flag. This would also help promote
the use of -m, especially for any projects that rely on being tied to
a specific installed interpreter.

As pointed out in issue #25152 <http://bugs.python.org/issue25152>,
virtualenv provides a -p flag to specify what version of Python should
be used to create a virtual environment:
https://virtualenv.pypa.io/en/latest/reference.html#virtualenv-command.
The pyvenv script and venv package provide no such mechanism since it
is included in the stdlib, which makes sense since improvements will
be tied to the stdlib of the Python interpreter being used while
virtualenv is a standalone project/app.

Some may argue that worrying about this is unnecessary, but we are
already ending up with OSs that come with multiple versions of Python
pre-installed, let alone when people install their own versions of
Python on top of the system installation. For instance, OS X Yosemite
comes with Python 2.6 and 2.7, and then if you install the latest
version of Python independently you end up with 3 installations. If
they all happened to have a pyvenv script you wouldn't easily know
which Python interpreter the pyvenv command was going to use for the
virtual environment.

Since the pyvenv script is just a script, the deprecation will be in
the form of a message printed to sys.stderr in the
Tools/scripts/pyvenv
<http://hg.python.org/cpython/file/default/Tools/scripts/pyvenv> file
mentioning that the deprecation and that people should switch to
`python3 -m venv` instead. The long deprecation cycle is for those who
have pyvenv provided by their OS and only upgrade Python every few
years, and thus run the risk of missing the deprecation warning. As
for the deprecation in Python 3.5.1, that's to get the warning out
immediately and to minimize people missing the deprecation prior to
the removal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150917/dfe38f61/attachment.html>

From barry at python.org  Thu Sep 17 21:04:58 2015
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Sep 2015 15:04:58 -0400
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
Message-ID: <20150917150458.75c85727@limelight.wooz.org>

On Sep 17, 2015, at 06:40 PM, Brett Cannon wrote:

>I propose that the pyvenv script be deprecated in Python 3.5.1 and
>removed in Python 3.8. The reason for this proposal is because it is
>non-obvious what version of Python a pyvenv command is tied to (heck,
>it isn't necessarily obvious that it's Python 3).

That's why in Debian/Ubuntu we include /usr/bin/pyvenv-X.Y for all supported
versions (currently 3.4 and 3.5 in Ubuntu 15.10), and then symlink
/usr/bin/pyvenv to the default one.  So I'm sympathetic to this proposal.

Cheers,
-Barry

From tjreedy at udel.edu  Thu Sep 17 21:06:37 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 17 Sep 2015 15:06:37 -0400
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <55FA6744.6080909@timgolden.me.uk>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name> <mtd6re$imr$1@ger.gmane.org>
 <55FA6744.6080909@timgolden.me.uk>
Message-ID: <mtf311$rbk$1@ger.gmane.org>

On 9/17/2015 3:09 AM, Tim Golden wrote:
> On 17/09/2015 02:59, Terry Reedy wrote:
>> On 9/16/2015 5:20 AM, Oleg Broytman wrote:
>>
>>> On Tue, Sep 15, 2015 at 07:44:28PM +0000, Augie Fackler
>>> <raf at durin42.com> wrote:
>>
>>>> There are a lot of reasons to prefer one tool over another. Common
>>>> ones are
>>>> familiarity, simplicity, and power.
>>>
>>>      Add here documentation, speed, availability of extensions and
>>> 3rd-party tools, hosting options (both locally installable and web
>>> services).
>>
>> For me, the killer 3rd party tool in favor of hg is TortoiseHg, which I
>> use on Windows. As far as I know (I did check a bit), there is no
>> equivalent for git on Windows.  For me, the evaluation should be between
>> hg+TortoiseHG versus git+???.

TortoiseHG includes the Workbench program, which to me is the superstar 
of the package and what I use daily for everything except a batch 
program to pull and update the multiple repositories (currently 3.6 and 
3.5, 3.4, and 2.7 shares).  Screenshot here
https://tortoisehg.readthedocs.org/en/latest/workbench.html

The main dag + (changeset + working directory) pane can have a tab for 
each branch repository. A sub-pane for the selected changeset or working 
directory lists the files changed. A sub-sub-pane shows a diff for the 
selected file.  So it is easy to check that all branch repositories are 
ready for a commit+merge. Once ready, committing to 2.7 and 3.4, merging 
to 3.5 and 3.6, and pushing takes less than a minute, thereby minimizing 
the change of losing a push race.

> There certainly is (and with the obvious name!):
>
> https://tortoisegit.org/

This works off of right-click context menus, as tortoisesvn did and 
tortoisehg can, but I looked at the screenshots and there is no 
workbench program.  So, for me, not equivalent at all.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Thu Sep 17 21:07:55 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 17 Sep 2015 15:07:55 -0400
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <CAMkX=YXvShd++-UqK6=SfJpcWRoHzHaKdgRGNq1MAO9WPf64Pw@mail.gmail.com>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name> <mtd6re$imr$1@ger.gmane.org>
 <871tdxvixb.fsf@vostro.rath.org>
 <CAMkX=YXvShd++-UqK6=SfJpcWRoHzHaKdgRGNq1MAO9WPf64Pw@mail.gmail.com>
Message-ID: <mtf33e$rbk$2@ger.gmane.org>

On 9/17/2015 3:17 AM, Andr? Freitas wrote:
> Regarding Git tools for Windows, GitHub Desktop and Sourcetree are
> actually very good with nice features.

Do you know if either have anything like TortoiseHg Workbench?
https://tortoisehg.readthedocs.org/en/latest/workbench.html
(screenshot at top)

-- 
Terry Jan Reedy



From rymg19 at gmail.com  Thu Sep 17 21:13:16 2015
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Thu, 17 Sep 2015 14:13:16 -0500
Subject: [Python-Dev] PEP: Collecting information about git
In-Reply-To: <mtf33e$rbk$2@ger.gmane.org>
References: <20150912135451.GA13004@phdru.name>
 <CALeMXf6_kNo_H7AS8EpJcgAPvHK21k3h8yF39cfb=zVuA7mRHg@mail.gmail.com>
 <20150912184231.GA21426@phdru.name>
 <CAN8CLg=-Nx+2zuHFRfUZTUc-ALPpKzuemh7OuezpHHiqU3Cn8g@mail.gmail.com>
 <20150913023140.GA31544@phdru.name> <loom.20150915T210932-903@post.gmane.org>
 <20150916092025.GA15714@phdru.name> <mtd6re$imr$1@ger.gmane.org>
 <871tdxvixb.fsf@vostro.rath.org>
 <CAMkX=YXvShd++-UqK6=SfJpcWRoHzHaKdgRGNq1MAO9WPf64Pw@mail.gmail.com>
 <mtf33e$rbk$2@ger.gmane.org>
Message-ID: <CAO41-mNQPjbnPWOHSE_4GE3VhTZO3iaMcrcbaHCvpxqNb6GQzA@mail.gmail.com>

*cough* Google *cough*

http://stackoverflow.com/questions/5911774/git-gui-like-hg-workbench-in-ms-windows

SourceTree looks quite similar.


On Thu, Sep 17, 2015 at 2:07 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 9/17/2015 3:17 AM, Andr? Freitas wrote:
>
>> Regarding Git tools for Windows, GitHub Desktop and Sourcetree are
>> actually very good with nice features.
>>
>
> Do you know if either have anything like TortoiseHg Workbench?
> https://tortoisehg.readthedocs.org/en/latest/workbench.html
> (screenshot at top)
>
> --
> Terry Jan Reedy
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something?s wrong.
http://kirbyfan64.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150917/6ec68b6b/attachment.html>

From ncoghlan at gmail.com  Fri Sep 18 11:53:25 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 18 Sep 2015 19:53:25 +1000
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <20150917150458.75c85727@limelight.wooz.org>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
Message-ID: <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>

On 18 September 2015 at 05:04, Barry Warsaw <barry at python.org> wrote:
> On Sep 17, 2015, at 06:40 PM, Brett Cannon wrote:
>
>>I propose that the pyvenv script be deprecated in Python 3.5.1 and
>>removed in Python 3.8. The reason for this proposal is because it is
>>non-obvious what version of Python a pyvenv command is tied to (heck,
>>it isn't necessarily obvious that it's Python 3).
>
> That's why in Debian/Ubuntu we include /usr/bin/pyvenv-X.Y for all supported
> versions (currently 3.4 and 3.5 in Ubuntu 15.10), and then symlink
> /usr/bin/pyvenv to the default one.  So I'm sympathetic to this proposal.

I currently use pyvenv directly, but I agree with starting a migration
to only supporting the more explicit "python -m venv". There's always
an inherent ambiguity on *nix with unqualified version sensitive
Python commands as to whether they're referring to Python 2 or 3, as
the answer often depends on *how old* the particular script is  (e.g.
pip and virtualenv relate to the Python 2 installation, while pyvenv
relates to the Python 3 installation).

There's one slightly oddity in the migration, which is that "pyvenv"
will still run even if you're in an activated Python 2 virtual
environment, while "python -m venv" fails. The answer is to use a
qualified Python version in the latter call.

I assume the change to the script will include forcing that particular
deprecation warning to be visible by default.

Regards,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From victor.stinner at gmail.com  Fri Sep 18 15:13:03 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 18 Sep 2015 15:13:03 +0200
Subject: [Python-Dev] My collection of Python 3.5.0 regressions
Message-ID: <CAMpsgwbeN=chJ1NRk=LMbd9f8WrAS3xeVrTM1Z1-t6hgt2J=0w@mail.gmail.com>

Hi,

Sadly, Python 3.5.0 comes with regressions. FYI I fixed the following
regressions:

"OSError in os.waitpid() on Windows"
http://bugs.python.org/issue25118

"Windows: datetime.datetime.now() raises an OverflowError for date
after year 2038"
http://bugs.python.org/issue25155


Victor

From victor.stinner at gmail.com  Fri Sep 18 15:18:32 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 18 Sep 2015 15:18:32 +0200
Subject: [Python-Dev] My collection of Python 3.5.0 regressions
Message-ID: <CAMpsgwYS=rM1o0BFw8ZKTp8vtuS87iuoXfbiHS0=06=KZYj-iQ@mail.gmail.com>

(Oh hey, I don't understand how I sent the previous email. Mistake
with keyboard shortcut in Gmail?)

Hi,

Sadly, Python 3.5.0 comes with regressions. FYI I fixed the following
regressions:

"OSError in os.waitpid() on Windows"
http://bugs.python.org/issue25118

"Windows: datetime.datetime.now() raises an OverflowError for date
after year 2038"
http://bugs.python.org/issue25155

"3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of
the third-party yt module fails on Python 3.5)"
http://bugs.python.org/issue25150

It may be good to not wait too long before releasing a first 3.5.1
bugfix version :-)

I just pushed fixes. We may wait a little bit for buildbots ;-)

--

There are some more issues which may be Python 3.5 regressions:

"Regression: test_datetime fails on 3.5, Win 7, works on 3.4"
http://bugs.python.org/issue25092

"asynico: add ssl_object extra info"
http://bugs.python.org/issue25114

"test_httpservers hangs on 3.5.0, win 7"
http://bugs.python.org/issue25095

Victor

From barry at python.org  Fri Sep 18 17:16:02 2015
From: barry at python.org (Barry Warsaw)
Date: Fri, 18 Sep 2015 11:16:02 -0400
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
 <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
Message-ID: <20150918111602.54ab56c5@limelight.wooz.org>

On Sep 18, 2015, at 07:53 PM, Nick Coghlan wrote:

>I currently use pyvenv directly, but I agree with starting a migration
>to only supporting the more explicit "python -m venv". There's always
>an inherent ambiguity on *nix with unqualified version sensitive
>Python commands as to whether they're referring to Python 2 or 3, as
>the answer often depends on *how old* the particular script is  (e.g.
>pip and virtualenv relate to the Python 2 installation, while pyvenv
>relates to the Python 3 installation).

On Debian, we often use things like -2 or -3 suffixes, but there's no naming
standard, and you inevitably get to monstrosities like nose2-3. ;)   For
scripts which have to be Python-version specific, the slight loss of usability
for `python -m blah` outweighs the ambiguity and ugliness of the direct
alternative.

>There's one slightly oddity in the migration, which is that "pyvenv"
>will still run even if you're in an activated Python 2 virtual
>environment, while "python -m venv" fails. The answer is to use a
>qualified Python version in the latter call.

One thing that came up in a similar discussion is pip, and the suggested move to
`python -m pip`, which makes a lot of sense.  However, *inside* a virtualenv,
there's no ambiguity about the Python version associated with direct `pip`
invocation, so it still makes sense to install that there.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150918/4ad339e0/attachment.sig>

From rdmurray at bitdance.com  Fri Sep 18 17:27:36 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 18 Sep 2015 11:27:36 -0400
Subject: [Python-Dev] My collection of Python 3.5.0 regressions
In-Reply-To: <CAMpsgwYS=rM1o0BFw8ZKTp8vtuS87iuoXfbiHS0=06=KZYj-iQ@mail.gmail.com>
References: <CAMpsgwYS=rM1o0BFw8ZKTp8vtuS87iuoXfbiHS0=06=KZYj-iQ@mail.gmail.com>
Message-ID: <20150918152736.D88BDB1408E@webabinitio.net>

Once Steve comes back from vacation he's going to have a lot of Windows
install issues to look at.  IMO, we should resolve those, and then issue
3.5.1.

It's really too bad more people didn't test the installation with the
release candidates, and I'm very glad that those people who did so did
so....I know there were a significant number of issues with the new
Windows installer infrastructure that were caught and fixed before final.

On Fri, 18 Sep 2015 15:18:32 +0200, Victor Stinner <victor.stinner at gmail.com> wrote:
> (Oh hey, I don't understand how I sent the previous email. Mistake
> with keyboard shortcut in Gmail?)
> 
> Hi,
> 
> Sadly, Python 3.5.0 comes with regressions. FYI I fixed the following
> regressions:
> 
> "OSError in os.waitpid() on Windows"
> http://bugs.python.org/issue25118
> 
> "Windows: datetime.datetime.now() raises an OverflowError for date
> after year 2038"
> http://bugs.python.org/issue25155
> 
> "3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of
> the third-party yt module fails on Python 3.5)"
> http://bugs.python.org/issue25150
> 
> It may be good to not wait too long before releasing a first 3.5.1
> bugfix version :-)
> 
> I just pushed fixes. We may wait a little bit for buildbots ;-)
> 
> --
> 
> There are some more issues which may be Python 3.5 regressions:
> 
> "Regression: test_datetime fails on 3.5, Win 7, works on 3.4"
> http://bugs.python.org/issue25092
> 
> "asynico: add ssl_object extra info"
> http://bugs.python.org/issue25114
> 
> "test_httpservers hangs on 3.5.0, win 7"
> http://bugs.python.org/issue25095
> 
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com

From breamoreboy at yahoo.co.uk  Fri Sep 18 17:54:59 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Fri, 18 Sep 2015 16:54:59 +0100
Subject: [Python-Dev] My collection of Python 3.5.0 regressions
In-Reply-To: <20150918152736.D88BDB1408E@webabinitio.net>
References: <CAMpsgwYS=rM1o0BFw8ZKTp8vtuS87iuoXfbiHS0=06=KZYj-iQ@mail.gmail.com>
 <20150918152736.D88BDB1408E@webabinitio.net>
Message-ID: <mthc4u$8s0$1@ger.gmane.org>

On 18/09/2015 16:27, R. David Murray wrote:
> Once Steve comes back from vacation he's going to have a lot of Windows
> install issues to look at.  IMO, we should resolve those, and then issue
> 3.5.1.
>
> It's really too bad more people didn't test the installation with the
> release candidates, and I'm very glad that those people who did so did
> so....I know there were a significant number of issues with the new
> Windows installer infrastructure that were caught and fixed before final.
>

I agree very strongly with your point here.  Raising umpteen issues over 
installation failures when a full release comes out strikes me as below 
the belt when there have been multiple previous releases without a squeak.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From status at bugs.python.org  Fri Sep 18 18:08:29 2015
From: status at bugs.python.org (Python tracker)
Date: Fri, 18 Sep 2015 18:08:29 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20150918160829.DE530568EC@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2015-09-11 - 2015-09-18)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    5130 (+54)
  closed 31798 (+45)
  total  36928 (+99)

Open issues with patches: 2270 


Issues opened (67)
==================

#22627: Calling timestamp() on a datetime object modifies the timestam
http://bugs.python.org/issue22627  reopened by belopolsky

#25072: CGI large POST data string truncated
http://bugs.python.org/issue25072  opened by Vincent Caloone

#25074: Bind logger and waninigs modules for asyncio __del__ methods
http://bugs.python.org/issue25074  opened by asvetlov

#25077: Compiler warnings: initialization from incompatible pointer ty
http://bugs.python.org/issue25077  opened by mgedmin

#25080: The example-code for making XML-RPC requests through proxy, fa
http://bugs.python.org/issue25080  opened by ankostis

#25081: Windows installer Upgrade->Customize->Back goes to Install pag
http://bugs.python.org/issue25081  opened by steve.dower

#25083: Python can sometimes create incorrect .pyc files
http://bugs.python.org/issue25083  opened by tzickel

#25084: remove semi-busy loop in py2.7 threading.Condition.wait(timeou
http://bugs.python.org/issue25084  opened by flavio

#25085: Windows x86-64 embeddable zip file contains test directorys
http://bugs.python.org/issue25085  opened by tds333

#25086: Windows x86-64 embeddable zip file, lot of big EXE files in di
http://bugs.python.org/issue25086  opened by tds333

#25087: Type variable substitution in type instances
http://bugs.python.org/issue25087  opened by skrah

#25089: Can't run Python Launcher on Windows
http://bugs.python.org/issue25089  opened by BreamoreBoy

#25090: IDLE: remove noisy icons from class (module) browser
http://bugs.python.org/issue25090  opened by markroseman

#25091: Windows Installer uses small font
http://bugs.python.org/issue25091  opened by terry.reedy

#25092: Regression: test_datetime fails on 3.5, Win 7, works on 3.4
http://bugs.python.org/issue25092  opened by terry.reedy

#25093: New 3.5.0 failure in test_tcl on win7
http://bugs.python.org/issue25093  opened by terry.reedy

#25094: Test_tools not working on Windows.
http://bugs.python.org/issue25094  opened by terry.reedy

#25095: test_httpservers hangs on 3.5.0, win 7
http://bugs.python.org/issue25095  opened by terry.reedy

#25097: test_logging may fail with 'Access is denied' when pywin32 is 
http://bugs.python.org/issue25097  opened by zach.ware

#25098: test_uuid fails with pywin32 installed
http://bugs.python.org/issue25098  opened by zach.ware

#25099: test_compileall fails when run by unprivileged user on install
http://bugs.python.org/issue25099  opened by zach.ware

#25100: Test_distutils fails instead of skipping if no VS2015
http://bugs.python.org/issue25100  opened by terry.reedy

#25101: test_zipfile failure when run by unprivileged user with instal
http://bugs.python.org/issue25101  opened by zach.ware

#25102: Windows installer: 'precompile standard library' option should
http://bugs.python.org/issue25102  opened by zach.ware

#25103: 3.5.0 installed standard library on Windows has LF line ending
http://bugs.python.org/issue25103  opened by zach.ware

#25106: Hash computation speedup for {buffer, string, unicode}object
http://bugs.python.org/issue25106  opened by alecsandru.patrascu

#25109: test_code_module tests fail when run from the installed locati
http://bugs.python.org/issue25109  opened by doko

#25111: Broken compatibility in FrameSummary equality
http://bugs.python.org/issue25111  opened by serhiy.storchaka

#25112: Windows installer assigns non-existent icons to Python file ty
http://bugs.python.org/issue25112  opened by thijsvandien

#25114: asynico: add ssl_object extra info
http://bugs.python.org/issue25114  opened by haypo

#25115: SSL_set_verify_depth not exposed by the ssl module
http://bugs.python.org/issue25115  opened by gbremer

#25116: It failed to install Py3.5 on win2008R2
http://bugs.python.org/issue25116  opened by Kevin Zhang

#25117: Windows installer: precompiling stdlib fails with missing DLL 
http://bugs.python.org/issue25117  opened by mgedmin

#25123: Logging Documentation - dictConfig disable_existing_loggers
http://bugs.python.org/issue25123  opened by coderobot

#25124: No single .msi available for 3.5 release
http://bugs.python.org/issue25124  opened by Christian.Ullrich

#25125: "Edit with IDLE" does not work for shortcuts
http://bugs.python.org/issue25125  opened by thijsvandien

#25126: Non-web installer fails without a connection when doing debug 
http://bugs.python.org/issue25126  opened by thijsvandien

#25129: Rounding mode of floating-point division is not well documente
http://bugs.python.org/issue25129  opened by pitrou

#25130: Make tests more PyPy compatible
http://bugs.python.org/issue25130  opened by serhiy.storchaka

#25131: The AST for dict and set displays has the lineno of the first 
http://bugs.python.org/issue25131  opened by Claudiu.Popa

#25133: Clarify that the constants in selectors are module-level
http://bugs.python.org/issue25133  opened by brett.cannon

#25135: Deques to adopt the standard clearing procedure for mutable ob
http://bugs.python.org/issue25135  opened by rhettinger

#25136: Python doesn't find Xcode 7 stub libraries
http://bugs.python.org/issue25136  opened by tdsmith

#25138: test_socket: socket.EAI_NODATA doesn't exist on FreeBSD
http://bugs.python.org/issue25138  opened by haypo

#25139: Just a little refactoring
http://bugs.python.org/issue25139  opened by ?????????????? ??????????????

#25143: 3.5 install fails poorly on Windows XP
http://bugs.python.org/issue25143  opened by pwatson at phs.org

#25144: 3.5 Win install fails with "TARGETDIR"
http://bugs.python.org/issue25144  opened by fov

#25145: urllib how-to should be updated to remove PyGoogle
http://bugs.python.org/issue25145  opened by nneonneo

#25146: IDLE debugger could better visualize program execution
http://bugs.python.org/issue25146  opened by markroseman

#25148: Windows registry PythonCore key changed inconsistent with othe
http://bugs.python.org/issue25148  opened by barry.scott

#25151: venv does not work with debian releases, if you want to instal
http://bugs.python.org/issue25151  opened by lac

#25152: venv documentation doesn't tell you how to specify a particula
http://bugs.python.org/issue25152  opened by lac

#25153: PCbuild/*.vcxproj* should use CRLF line endings
http://bugs.python.org/issue25153  opened by zach.ware

#25154: Drop the pyvenv script
http://bugs.python.org/issue25154  opened by brett.cannon

#25156: shutil.copyfile should internally use os.sendfile when possibl
http://bugs.python.org/issue25156  opened by desbma

#25157: Installing Python 3.5.0 32bit on Windows 8.1 64bit system give
http://bugs.python.org/issue25157  opened by lac

#25158: Python 3.2.2 and 3.5.0 Do not seem compatible with OpenSSL 1.0
http://bugs.python.org/issue25158  opened by eeiddne

#25159: Import time regression
http://bugs.python.org/issue25159  opened by serhiy.storchaka

#25160: Stop using deprecated imp module; imp should now emit a real D
http://bugs.python.org/issue25160  opened by haypo

#25161: Missing periods at the end of sentences
http://bugs.python.org/issue25161  opened by artakase

#25162: Windows installation does not appear in list of installed appl
http://bugs.python.org/issue25162  opened by Christian.Ullrich

#25163: Windows installer in AllUsers mode presents wrong installation
http://bugs.python.org/issue25163  opened by Christian.Ullrich

#25164: Windows default installation path is inconsistent between per-
http://bugs.python.org/issue25164  opened by Christian.Ullrich

#25165: Windows uninstallation should not remove launcher if other ver
http://bugs.python.org/issue25165  opened by Christian.Ullrich

#25166: Windows AllUsers installation places uninstaller in user profi
http://bugs.python.org/issue25166  opened by Christian.Ullrich

#25168: test_datetime.test_strptime() random failures on "s390x SLES" 
http://bugs.python.org/issue25168  opened by haypo

#25169: multiprocess documentation
http://bugs.python.org/issue25169  opened by jftuga



Most recent 15 issues with no replies (15)
==========================================

#25166: Windows AllUsers installation places uninstaller in user profi
http://bugs.python.org/issue25166

#25165: Windows uninstallation should not remove launcher if other ver
http://bugs.python.org/issue25165

#25164: Windows default installation path is inconsistent between per-
http://bugs.python.org/issue25164

#25163: Windows installer in AllUsers mode presents wrong installation
http://bugs.python.org/issue25163

#25162: Windows installation does not appear in list of installed appl
http://bugs.python.org/issue25162

#25158: Python 3.2.2 and 3.5.0 Do not seem compatible with OpenSSL 1.0
http://bugs.python.org/issue25158

#25156: shutil.copyfile should internally use os.sendfile when possibl
http://bugs.python.org/issue25156

#25153: PCbuild/*.vcxproj* should use CRLF line endings
http://bugs.python.org/issue25153

#25148: Windows registry PythonCore key changed inconsistent with othe
http://bugs.python.org/issue25148

#25145: urllib how-to should be updated to remove PyGoogle
http://bugs.python.org/issue25145

#25144: 3.5 Win install fails with "TARGETDIR"
http://bugs.python.org/issue25144

#25139: Just a little refactoring
http://bugs.python.org/issue25139

#25138: test_socket: socket.EAI_NODATA doesn't exist on FreeBSD
http://bugs.python.org/issue25138

#25133: Clarify that the constants in selectors are module-level
http://bugs.python.org/issue25133

#25125: "Edit with IDLE" does not work for shortcuts
http://bugs.python.org/issue25125



Most recent 15 issues waiting for review (15)
=============================================

#25161: Missing periods at the end of sentences
http://bugs.python.org/issue25161

#25139: Just a little refactoring
http://bugs.python.org/issue25139

#25136: Python doesn't find Xcode 7 stub libraries
http://bugs.python.org/issue25136

#25135: Deques to adopt the standard clearing procedure for mutable ob
http://bugs.python.org/issue25135

#25130: Make tests more PyPy compatible
http://bugs.python.org/issue25130

#25115: SSL_set_verify_depth not exposed by the ssl module
http://bugs.python.org/issue25115

#25114: asynico: add ssl_object extra info
http://bugs.python.org/issue25114

#25112: Windows installer assigns non-existent icons to Python file ty
http://bugs.python.org/issue25112

#25111: Broken compatibility in FrameSummary equality
http://bugs.python.org/issue25111

#25106: Hash computation speedup for {buffer, string, unicode}object
http://bugs.python.org/issue25106

#25102: Windows installer: 'precompile standard library' option should
http://bugs.python.org/issue25102

#25101: test_zipfile failure when run by unprivileged user with instal
http://bugs.python.org/issue25101

#25093: New 3.5.0 failure in test_tcl on win7
http://bugs.python.org/issue25093

#25092: Regression: test_datetime fails on 3.5, Win 7, works on 3.4
http://bugs.python.org/issue25092

#25084: remove semi-busy loop in py2.7 threading.Condition.wait(timeou
http://bugs.python.org/issue25084



Top 10 most discussed issues (10)
=================================

#24965: Implement PEP 498: Literal String Formatting
http://bugs.python.org/issue24965  23 msgs

#25092: Regression: test_datetime fails on 3.5, Win 7, works on 3.4
http://bugs.python.org/issue25092  22 msgs

#25106: Hash computation speedup for {buffer, string, unicode}object
http://bugs.python.org/issue25106  18 msgs

#25129: Rounding mode of floating-point division is not well documente
http://bugs.python.org/issue25129  10 msgs

#25003: os.urandom() should call getrandom(2) not getentropy(2) on Sol
http://bugs.python.org/issue25003   9 msgs

#25084: remove semi-busy loop in py2.7 threading.Condition.wait(timeou
http://bugs.python.org/issue25084   8 msgs

#25152: venv documentation doesn't tell you how to specify a particula
http://bugs.python.org/issue25152   8 msgs

#25089: Can't run Python Launcher on Windows
http://bugs.python.org/issue25089   7 msgs

#25093: New 3.5.0 failure in test_tcl on win7
http://bugs.python.org/issue25093   6 msgs

#25095: test_httpservers hangs on 3.5.0, win 7
http://bugs.python.org/issue25095   6 msgs



Issues closed (45)
==================

#21874: test_strptime fails on rhel/centos/fedora systems
http://bugs.python.org/issue21874  closed by haypo

#23517: datetime.utcfromtimestamp rounds results incorrectly
http://bugs.python.org/issue23517  closed by haypo

#24756: doctest run_docstring_examples does have an obvious utility
http://bugs.python.org/issue24756  closed by python-dev

#24840: implement bool conversion for enums to prevent odd edge case
http://bugs.python.org/issue24840  closed by python-dev

#24872: Add /NODEFAULTLIB:MSVCRT to _msvccompiler
http://bugs.python.org/issue24872  closed by steve.dower

#24927: multiprocessing.Pool hangs forever on segfault
http://bugs.python.org/issue24927  closed by Jonas Obrist

#24982: shutil.make_archive doesn't archive empty directories
http://bugs.python.org/issue24982  closed by serhiy.storchaka

#25021: product_setstate() Out-of-bounds Read
http://bugs.python.org/issue25021  closed by rhettinger

#25027: Python 3.5.0rc3 on Windows can not load more than 127 C extens
http://bugs.python.org/issue25027  closed by larry

#25043: document socket constants for Bluetooth
http://bugs.python.org/issue25043  closed by martin.panter

#25063: shutil.copyfileobj should internally use os.sendfile when poss
http://bugs.python.org/issue25063  closed by r.david.murray

#25070: Python 2.6 - Python 3.4 allows unparenthesized generator with 
http://bugs.python.org/issue25070  closed by yselivanov

#25071: Windows installer requires TargetDir parameter when installing
http://bugs.python.org/issue25071  closed by steve.dower

#25073: Document asyncio.test_utils
http://bugs.python.org/issue25073  closed by yselivanov

#25075: issue from python in encode base64 with Json Model
http://bugs.python.org/issue25075  closed by martin.panter

#25076: Wrong parameter name in distutils documentation
http://bugs.python.org/issue25076  closed by python-dev

#25078: Document InstallAllUsers installer parameter default 0
http://bugs.python.org/issue25078  closed by python-dev

#25079: Tokenize generates NL instead of NEWLINE for comments
http://bugs.python.org/issue25079  closed by skrah

#25082: Editing What's New In Python 3.5
http://bugs.python.org/issue25082  closed by yselivanov

#25088: scipy (0.16.0) install fails on 3.5
http://bugs.python.org/issue25088  closed by ned.deily

#25096: test_gdb failed to read version for gdb >= 7.10
http://bugs.python.org/issue25096  closed by haypo

#25104: Wrong documentation for "chr(i)" function.
http://bugs.python.org/issue25104  closed by zach.ware

#25105: Docs 3.x buildbot: ":root" found in ...
http://bugs.python.org/issue25105  closed by berker.peksag

#25107: Windows 32-bit: exe-files doesn't run
http://bugs.python.org/issue25107  closed by zach.ware

#25108: traceback.extract_stack() compatibility break in 3.5
http://bugs.python.org/issue25108  closed by serhiy.storchaka

#25110: Documentation sometimes still links to py3.4
http://bugs.python.org/issue25110  closed by larry

#25113: documentation version switcher is broken
http://bugs.python.org/issue25113  closed by berker.peksag

#25118: OSError in os.waitpid() on Windows [3.5.0 regression]
http://bugs.python.org/issue25118  closed by haypo

#25119: Windows installer fails to install VCRUNTIME140.DLL
http://bugs.python.org/issue25119  closed by eryksun

#25120: No option displayed in the Python install on windows XP
http://bugs.python.org/issue25120  closed by larry

#25121: python logger RotatingFileHandler can't wrap log file and blow
http://bugs.python.org/issue25121  closed by r.david.murray

#25122: test_eintr randomly fails on FreeBSD
http://bugs.python.org/issue25122  closed by haypo

#25127: typo in concurrent.futures.Executor.shutdown() example
http://bugs.python.org/issue25127  closed by berker.peksag

#25128: https://docs.python.org/3/download.html incorrect links to fil
http://bugs.python.org/issue25128  closed by berker.peksag

#25132: unable to install mongo-python-driver-3.0.3 driver
http://bugs.python.org/issue25132  closed by r.david.murray

#25134: SSL asyncio
http://bugs.python.org/issue25134  closed by haypo

#25137: Behavioral change / regression? with nested functools.partial
http://bugs.python.org/issue25137  closed by haypo

#25140: platform.platform() incorrectly identifies Windows 10 as 'Wind
http://bugs.python.org/issue25140  closed by lemburg

#25141: Spam
http://bugs.python.org/issue25141  closed by petri.lehtinen

#25142: Misleading error when initing ImportError
http://bugs.python.org/issue25142  closed by berker.peksag

#25147: Enum: remove dependency on OrderedDict
http://bugs.python.org/issue25147  closed by python-dev

#25149: datetime.weekday() off by one if handling a date from utcfromt
http://bugs.python.org/issue25149  closed by odianus

#25150: 3.5: Include/pyatomic.h is incompatible with OpenMP (compilati
http://bugs.python.org/issue25150  closed by haypo

#25155: Windows: datetime.datetime.now() raises an OverflowError for d
http://bugs.python.org/issue25155  closed by haypo

#25167: Spam
http://bugs.python.org/issue25167  closed by haypo

From tjreedy at udel.edu  Sat Sep 19 01:23:13 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 18 Sep 2015 19:23:13 -0400
Subject: [Python-Dev] My collection of Python 3.5.0 regressions
In-Reply-To: <CAMpsgwYS=rM1o0BFw8ZKTp8vtuS87iuoXfbiHS0=06=KZYj-iQ@mail.gmail.com>
References: <CAMpsgwYS=rM1o0BFw8ZKTp8vtuS87iuoXfbiHS0=06=KZYj-iQ@mail.gmail.com>
Message-ID: <mti6e7$5ab$1@ger.gmane.org>

On 9/18/2015 9:18 AM, Victor Stinner wrote:

> Sadly, Python 3.5.0 comes with regressions. FYI I fixed the following
> regressions:

The tracker needs a new keyword: '3.5regression', to match others.

> "OSError in os.waitpid() on Windows"
> http://bugs.python.org/issue25118
>
> "Windows: datetime.datetime.now() raises an OverflowError for date
> after year 2038"
> http://bugs.python.org/issue25155
>
> "3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of
> the third-party yt module fails on Python 3.5)"
> http://bugs.python.org/issue25150
>
> It may be good to not wait too long before releasing a first 3.5.1
> bugfix version :-)
>
> I just pushed fixes. We may wait a little bit for buildbots ;-)
>
> --
>
> There are some more issues which may be Python 3.5 regressions:
>
> "Regression: test_datetime fails on 3.5, Win 7, works on 3.4"
> http://bugs.python.org/issue25092
>
> "asynico: add ssl_object extra info"
> http://bugs.python.org/issue25114
>
> "test_httpservers hangs on 3.5.0, win 7"
> http://bugs.python.org/issue25095

You also diagnosed another regression:

"AST for dict and set displays has the lineno of the first value"
https://bugs.python.org/issue25131


-- 
Terry Jan Reedy


From ncoghlan at gmail.com  Sat Sep 19 06:23:07 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Sep 2015 14:23:07 +1000
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <20150918111602.54ab56c5@limelight.wooz.org>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
 <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
 <20150918111602.54ab56c5@limelight.wooz.org>
Message-ID: <CADiSq7e73R=3rGDq2AQKZo55DS1t9kibRiFoEy16xOPk8FH8EA@mail.gmail.com>

On 19 September 2015 at 01:16, Barry Warsaw <barry at python.org> wrote:
> On Sep 18, 2015, at 07:53 PM, Nick Coghlan wrote:
>
>>I currently use pyvenv directly, but I agree with starting a migration
>>to only supporting the more explicit "python -m venv". There's always
>>an inherent ambiguity on *nix with unqualified version sensitive
>>Python commands as to whether they're referring to Python 2 or 3, as
>>the answer often depends on *how old* the particular script is  (e.g.
>>pip and virtualenv relate to the Python 2 installation, while pyvenv
>>relates to the Python 3 installation).
>
> On Debian, we often use things like -2 or -3 suffixes, but there's no naming
> standard, and you inevitably get to monstrosities like nose2-3. ;)   For
> scripts which have to be Python-version specific, the slight loss of usability
> for `python -m blah` outweighs the ambiguity and ugliness of the direct
> alternative.
>
>>There's one slightly oddity in the migration, which is that "pyvenv"
>>will still run even if you're in an activated Python 2 virtual
>>environment, while "python -m venv" fails. The answer is to use a
>>qualified Python version in the latter call.
>
> One thing that came up in a similar discussion is pip, and the suggested move to
> `python -m pip`, which makes a lot of sense.  However, *inside* a virtualenv,
> there's no ambiguity about the Python version associated with direct `pip`
> invocation, so it still makes sense to install that there.

Right. This is moving more into python-ideas and/or distutils-sig
territory, but this point also gave me an idea regarding what we might
want to do with the "python" command on Linux systems that have
migrated to using Python 3 as the system Python: what if we agreed to
change "python" on Linux systems to be a script that launches a
"default" virtual environment stored in the user's home directory
(location TBD), and similarly changed the unqualified system "pip"
command to manipulate that default virtual environment?

The question of "Which Python does 'python' run and 'pip' manipulate?"
would then be determined by how that default virtual environment was
set up rather than using a distro specific runtime switching
technology. If could either be Python 2.7 based using virtualenv, or
else a native Python 3 venv. Switching to a different default runtime
(e.g. PyPy) would be a matter of replacing that default virtual
environment with one created using a different interpreter. (This
approach would likely also deal with the perennial "Should pip default
to --user for global installs?" question).

Presumably, we could figure out a way to make that work on Windows as
well, such that "python" and "pip" *always* meant activating and
working in the user's default virtual environment, if there wasn't
already a virtual environment activated.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From stephen at xemacs.org  Sat Sep 19 07:24:16 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 19 Sep 2015 14:24:16 +0900
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <20150918111602.54ab56c5@limelight.wooz.org>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
 <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
 <20150918111602.54ab56c5@limelight.wooz.org>
Message-ID: <87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > One thing that came up in a similar discussion is pip, and the
 > suggested move to `python -m pip`, which makes a lot of sense.
 > However, *inside* a virtualenv, there's no ambiguity about the
 > Python version associated with direct `pip` invocation, so it still
 > makes sense to install that there.

And then the poor newbie who's just following orders (eg, in
mailman3/src/mailman/docs/INSTALL<wink/>) will try pip'ing outside of
the virtualenv for some reason, and have a WTF experience.  I think we
should KISS the pip command good-bye.

A somewhat different way I look at it: the OS provides a shell, and
you invoke aptitude (CLI) or synaptic (from clickety-clickety GUI
shell) from that OS shell to manage OS packages.  By analogy (always
slippery but this one feels good to me), to manage python packages you
should be working in the Python "shell".  R does it that way with
great success.  Emacsen do it (with lesser success :-P ).  perl and
TeX don't -- but they don't have interactive shells (at least not
universally available to the users).


From stephen at xemacs.org  Sat Sep 19 07:38:36 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 19 Sep 2015 14:38:36 +0900
Subject: [Python-Dev] My collection of Python 3.5.0 regressions
In-Reply-To: <mthc4u$8s0$1@ger.gmane.org>
References: <CAMpsgwYS=rM1o0BFw8ZKTp8vtuS87iuoXfbiHS0=06=KZYj-iQ@mail.gmail.com>
 <20150918152736.D88BDB1408E@webabinitio.net>
 <mthc4u$8s0$1@ger.gmane.org>
Message-ID: <87a8sjynmr.fsf@uwakimon.sk.tsukuba.ac.jp>

Mark Lawrence writes:

 > I agree very strongly with your point here.  Raising umpteen issues
 > over installation failures when a full release comes out strikes me
 > as below the belt when there have been multiple previous releases
 > without a squeak.

Raising issues is always useful and appropriate.  It's up to Larry
Hastings to decide whether he personally needs to do more work.

I suspect he probably will, though.  I knew these changes were risky
on the lead time given, even though I don't do Windows, and I'm not a
core Python developer.  I would hope that Steve Dower and Larry were
at least as well aware of what they were getting into, and there are a
lot of Windows users we *want* to support well.  (*Not* "have to", and
YMMV.  But the Python developer community clearly has a working
consensus on supporting Windows well.)


From tjreedy at udel.edu  Sat Sep 19 07:49:19 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 19 Sep 2015 01:49:19 -0400
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
 <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
 <20150918111602.54ab56c5@limelight.wooz.org>
 <87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <mtit25$elc$1@ger.gmane.org>

On 9/19/2015 1:24 AM, Stephen J. Turnbull wrote:
> Barry Warsaw writes:
>
>   > One thing that came up in a similar discussion is pip, and the
>   > suggested move to `python -m pip`, which makes a lot of sense.
>   > However, *inside* a virtualenv, there's no ambiguity about the
>   > Python version associated with direct `pip` invocation, so it still
>   > makes sense to install that there.
>
> And then the poor newbie who's just following orders (eg, in
> mailman3/src/mailman/docs/INSTALL<wink/>) will try pip'ing outside of
> the virtualenv for some reason, and have a WTF experience.  I think we
> should KISS the pip command good-bye.
>
> A somewhat different way I look at it: the OS provides a shell, and
> you invoke aptitude (CLI) or synaptic (from clickety-clickety GUI
> shell) from that OS shell to manage OS packages.  By analogy (always
> slippery but this one feels good to me), to manage python packages you
> should be working in the Python "shell".

It is somewhat possible to do this by importing pip.main and translating 
pip command line calls to main() calls. I reported proof-of-concept 
experiments on issue 23551. To be practical, this should be wrapped in a 
tkinter gui.  Once written, I will add it to the Idle menu.  Other gui 
shells, could and probably would do the same.

> R does it that way with
> great success.  Emacsen do it (with lesser success :-P ).   perl and
> TeX don't -- but they don't have interactive shells (at least not
> universally available to the users).

Am I correct in guessing that on Windows, at least, R and Emacs do *not* 
run in Command Prompt?

-- 
Terry Jan Reedy


From stephen at xemacs.org  Sat Sep 19 09:25:48 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 19 Sep 2015 16:25:48 +0900
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <mtit25$elc$1@ger.gmane.org>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
 <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
 <20150918111602.54ab56c5@limelight.wooz.org>
 <87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>
 <mtit25$elc$1@ger.gmane.org>
Message-ID: <877fnmzx8j.fsf@uwakimon.sk.tsukuba.ac.jp>

Terry Reedy writes:

 > Am I correct in guessing that on Windows, at least, R and Emacs do *not* 
 > run in Command Prompt?

I'm not sure what you mean by that.  Of course they do run under
Command Prompt, but the limitations of the command window are so
severe that almost nobody ever does that, they click on an icon to
start.  Nevertheless the basic interactions that are always available
are command-shell-like (as in IDLE), although there are icon- or menu-
driven GUI shells or modes available for each.

In Emacs, the basic interface is the "list-packages" command, which
brings up a (text) menu of installed and available packages on the
ELPA package repository.  In R, it's the package.install() function,
which I think has a subfeature that will list the packages available
from the CRAN package repository (but I always just go to the
website).

From srkunze at mail.de  Sat Sep 19 11:12:52 2015
From: srkunze at mail.de (Sven R. Kunze)
Date: Sat, 19 Sep 2015 11:12:52 +0200
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
 <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
 <20150918111602.54ab56c5@limelight.wooz.org>
 <87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <55FD2714.2030607@mail.de>

On 19.09.2015 07:24, Stephen J. Turnbull wrote:
> Barry Warsaw writes:
>
>   > One thing that came up in a similar discussion is pip, and the
>   > suggested move to `python -m pip`, which makes a lot of sense.
>   > However, *inside* a virtualenv, there's no ambiguity about the
>   > Python version associated with direct `pip` invocation, so it still
>   > makes sense to install that there.
>
> And then the poor newbie who's just following orders (eg, in
> mailman3/src/mailman/docs/INSTALL<wink/>) will try pip'ing outside of
> the virtualenv for some reason, and have a WTF experience.  I think we
> should KISS the pip command good-bye.

The only question I have: is there a particular reason (not technical 
one) why there are many pips on my PC?

I would imagine 1 pip for the whole OS, that is capable to install 
packages inside arbitrary venvs AND handles different versions of Python.


Best,
Sven

From eric at trueblade.com  Sat Sep 19 13:03:05 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Sat, 19 Sep 2015 07:03:05 -0400
Subject: [Python-Dev] PEP 498 (interpolated f-string) tweak
Message-ID: <55FD40E9.4010708@trueblade.com>

While finishing up the implementation of PEP 498, I realized that the
PEP has an error. It says that this code:

f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'

Is equivalent to:

'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
+ str(expr3).__format__('') + 'ghi'

But that's not correct. The right way to call __format__ is:

type(expr1).__format__(expr1, spec1)

That is, the lookup of __format__ is done on the type, not the instance.

Instead of calling __format__, I've changed the code generator to call
format(expr1, spec1). As an optimization, I might add special opcodes to
deal with this and string concatenation, but that's for another day (if
ever).

I've posted a new version of the code in issue 24965. I'll update the
PEP itself sometime this weekend.


From p.f.moore at gmail.com  Sat Sep 19 14:44:27 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 19 Sep 2015 13:44:27 +0100
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <55FD2714.2030607@mail.de>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
 <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
 <20150918111602.54ab56c5@limelight.wooz.org>
 <87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>
 <55FD2714.2030607@mail.de>
Message-ID: <CACac1F9_e+_OJuUL29NsrLb5FOEjbqgN5khbWAKxpdwQvHjiOw@mail.gmail.com>

On 19 September 2015 at 10:12, Sven R. Kunze <srkunze at mail.de> wrote:
> The only question I have: is there a particular reason (not technical one)
> why there are many pips on my PC?

That's not an unreasonable question, but (IMO) most of the answers are
technical, or amount to "why would you think that's wrong". So
apologies, I do know this isn't a direct answer to your question.

1. There are a lot of ways in which pip's implementation assumes it's
installing modules for the Python installation that is running it.
2. We have no installation process or path management to allow you to
install a Python package *outside* of a Python installation and run it
with the user's choice of Python.
3. You've got lots of pythons on your PC (otherwise you wouldn't have
lots of pips!) so why do you think it's *not* equally reasonable to
have lots of pips?
4. The "py" launcher (on Windows) manages your multiple Pythons for
you - it can also manage pip if you don't mind using "py -m pip" to
invoke pip. You can of course alias this (wrap it in a powershell
function, bat file, shell script or whatever) as you choose.

So, to directly answer:

    Because there are technical challenges that no-one has stepped up to solve.

I would assume you're thinking of a "single pip" in the same way that
the py.exe launcher is a "single python". Assuming so, then the
"single pip" solution is "py -m pip" (leveraging py.exe's options for
picking which Python to use). I don't know if there's a Unix
equivalent to the launcher - if not, then maybe there should be?

Paul

From p.f.moore at gmail.com  Sat Sep 19 14:46:49 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 19 Sep 2015 13:46:49 +0100
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <mtit25$elc$1@ger.gmane.org>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
 <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
 <20150918111602.54ab56c5@limelight.wooz.org>
 <87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>
 <mtit25$elc$1@ger.gmane.org>
Message-ID: <CACac1F8_Br4F4j7t-8zsSwYp04ssaZWaL2ZmzPR8s29aANWmOQ@mail.gmail.com>

On 19 September 2015 at 06:49, Terry Reedy <tjreedy at udel.edu> wrote:
> On 9/19/2015 1:24 AM, Stephen J. Turnbull wrote:
>>
>> Barry Warsaw writes:
>>
>>   > One thing that came up in a similar discussion is pip, and the
>>   > suggested move to `python -m pip`, which makes a lot of sense.
>>   > However, *inside* a virtualenv, there's no ambiguity about the
>>   > Python version associated with direct `pip` invocation, so it still
>>   > makes sense to install that there.
>>
>> And then the poor newbie who's just following orders (eg, in
>> mailman3/src/mailman/docs/INSTALL<wink/>) will try pip'ing outside of
>> the virtualenv for some reason, and have a WTF experience.  I think we
>> should KISS the pip command good-bye.
>>
>> A somewhat different way I look at it: the OS provides a shell, and
>> you invoke aptitude (CLI) or synaptic (from clickety-clickety GUI
>> shell) from that OS shell to manage OS packages.  By analogy (always
>> slippery but this one feels good to me), to manage python packages you
>> should be working in the Python "shell".
>
>
> It is somewhat possible to do this by importing pip.main and translating pip
> command line calls to main() calls. I reported proof-of-concept experiments
> on issue 23551. To be practical, this should be wrapped in a tkinter gui.
> Once written, I will add it to the Idle menu.  Other gui shells, could and
> probably would do the same.

I've raised https://github.com/pypa/pip/issues/3121 as a starting
point for discussion on how pip could support a high-level Python API
(i.e. make pip.main a bit less "you're on your own"). I don't have any
plans right now to work on it, but it provides somewhere to centralise
any discussion (and of course, if anyone *else* feels like
contributing patches, that'd be great too ;-))

Paul

From ncoghlan at gmail.com  Sat Sep 19 17:58:21 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Sep 2015 01:58:21 +1000
Subject: [Python-Dev] My collection of Python 3.5.0 regressions
In-Reply-To: <87a8sjynmr.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAMpsgwYS=rM1o0BFw8ZKTp8vtuS87iuoXfbiHS0=06=KZYj-iQ@mail.gmail.com>
 <20150918152736.D88BDB1408E@webabinitio.net>
 <mthc4u$8s0$1@ger.gmane.org>
 <87a8sjynmr.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CADiSq7fHv7gZ8LneV2gbYrdA_ZgxUXMwbv7OV_UB0njgR-aXzg@mail.gmail.com>

On 19 Sep 2015 15:40, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>
> Mark Lawrence writes:
>
>  > I agree very strongly with your point here.  Raising umpteen issues
>  > over installation failures when a full release comes out strikes me
>  > as below the belt when there have been multiple previous releases
>  > without a squeak.
>
> Raising issues is always useful and appropriate.  It's up to Larry
> Hastings to decide whether he personally needs to do more work.
>
> I suspect he probably will, though.  I knew these changes were risky
> on the lead time given, even though I don't do Windows, and I'm not a
> core Python developer.  I would hope that Steve Dower and Larry were
> at least as well aware of what they were getting into, and there are a
> lot of Windows users we *want* to support well.  (*Not* "have to", and
> YMMV.  But the Python developer community clearly has a working
> consensus on supporting Windows well.)

There were some pretty big changes on the Windows side of things for Python
3.5.0 - not just porting the installer to the Wix toolset and migrating to
a new of Visual Studio, but also adjusting to some fairly major underlying
changes to the way the Microsoft C runtime works in general. As part of all
that, I believe we also finally switched to being a well behaved Windows
citizen and now default to installing into Program Files rather than the
root of C:\.

With the wide variety of system configurations out there, that degree of
change from past practices was always going to encounter some teething
troubles. Fortunately, we're unlikely to ever have to go through a shift
like this again, and are now in a situation where our installation
practices not only better align with Microsoft's recommendations, but are
able to benefit from future evolution in the Wix toolset rather than
necessarily having to track changes to Microsoft's recommendations directly.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150920/d6f5fe94/attachment.html>

From guido at python.org  Sat Sep 19 18:25:32 2015
From: guido at python.org (Guido van Rossum)
Date: Sat, 19 Sep 2015 09:25:32 -0700
Subject: [Python-Dev] PEP 498 (interpolated f-string) tweak
In-Reply-To: <55FD40E9.4010708@trueblade.com>
References: <55FD40E9.4010708@trueblade.com>
Message-ID: <CAP7+vJJaEp3KDC5YwtUL-KnBrcF6BiLr=N_dBKSqKRhFSuVvgA@mail.gmail.com>

Good catch, Eric.

For those who wonder what the difference is or why it matters, it's what we
do for all dunder operators: the magic method is looked up on the class,
not on the instance. This means you can't e.g. override + on a per-instance
basis by having an instance variable named '__add__' pointing to some
function. That's a rare use case, it's pretty obfuscated, it would slow
down everything, and if you really need that pattern, there are other ways
to do it (you could have a regular instance method __add__ on the class
that looks for an instance variable, e.g. named _add, and call it if it
exists -- otherwise call super().__add__).

--Guido

On Sat, Sep 19, 2015 at 4:03 AM, Eric V. Smith <eric at trueblade.com> wrote:

> While finishing up the implementation of PEP 498, I realized that the
> PEP has an error. It says that this code:
>
> f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
>
> Is equivalent to:
>
> 'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
> + str(expr3).__format__('') + 'ghi'
>
> But that's not correct. The right way to call __format__ is:
>
> type(expr1).__format__(expr1, spec1)
>
> That is, the lookup of __format__ is done on the type, not the instance.
>
> Instead of calling __format__, I've changed the code generator to call
> format(expr1, spec1). As an optimization, I might add special opcodes to
> deal with this and string concatenation, but that's for another day (if
> ever).
>
> I've posted a new version of the code in issue 24965. I'll update the
> PEP itself sometime this weekend.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150919/26d025b2/attachment.html>

From srkunze at mail.de  Sat Sep 19 19:15:20 2015
From: srkunze at mail.de (Sven R. Kunze)
Date: Sat, 19 Sep 2015 19:15:20 +0200
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <CACac1F9_e+_OJuUL29NsrLb5FOEjbqgN5khbWAKxpdwQvHjiOw@mail.gmail.com>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>	<20150917150458.75c85727@limelight.wooz.org>	<CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>	<20150918111602.54ab56c5@limelight.wooz.org>	<87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>	<55FD2714.2030607@mail.de>
 <CACac1F9_e+_OJuUL29NsrLb5FOEjbqgN5khbWAKxpdwQvHjiOw@mail.gmail.com>
Message-ID: <55FD9828.2050608@mail.de>

On 19.09.2015 14:44, Paul Moore wrote:
> On 19 September 2015 at 10:12, Sven R. Kunze <srkunze at mail.de> wrote:
>> The only question I have: is there a particular reason (not technical one)
>> why there are many pips on my PC?
> That's not an unreasonable question, but (IMO) most of the answers are
> technical, or amount to "why would you think that's wrong". So
> apologies, I do know this isn't a direct answer to your question.
>
> 1. There are a lot of ways in which pip's implementation assumes it's
> installing modules for the Python installation that is running it.

We need to cope with that in some way.

> 2. We have no installation process or path management to allow you to
> install a Python package *outside* of a Python installation and run it
> with the user's choice of Python.

I wouldn't go so far so put the installation somewhere else. The current 
site-packages is good enough (although, it's a somewhat strange name).

But what I would love to see is a real package management, where 
installing packages is safe (asking when overriding existing files), 
where I can have proper upgrading/downgrading, query dependencies, query 
installed files/scripts/data, query redundant packages and so on and so 
forth. Just like zypper, apt-get or its kind. We get there but I fear it 
will be a long time before Python gets the package management it deserves.

pip = Python installs Python. That's how it started; however, real 
package management is far more.

> 3. You've got lots of pythons on your PC (otherwise you wouldn't have
> lots of pips!) so why do you think it's *not* equally reasonable to
> have lots of pips?

pip happens to use Python but both serve different purposes. Why it's 
not reasonable? Good question, the best answer I can come up with is 
that "just invoking pip" does not tell you what Python it is going to 
un-/install packages for. You see it (when it's installing), but would 
be step forward to be asked kindly if I am okay with the installation 
location (and user+group permissions) and if not I could change it. 
Something like this. I think it's the usability I am really concerned with.

> 4. The "py" launcher (on Windows) manages your multiple Pythons for
> you - it can also manage pip if you don't mind using "py -m pip" to
> invoke pip. You can of course alias this (wrap it in a powershell
> function, bat file, shell script or whatever) as you choose.

Interesting. So, py knows the location of all Python installations. What 
about py knows about all venvs? Then it could manage them in one place.

> So, to directly answer:
>
>      Because there are technical challenges that no-one has stepped up to solve.

Let's solve them. :)

Best,
Sven

From p.f.moore at gmail.com  Sat Sep 19 19:19:26 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 19 Sep 2015 18:19:26 +0100
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <55FD9828.2050608@mail.de>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
 <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
 <20150918111602.54ab56c5@limelight.wooz.org>
 <87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>
 <55FD2714.2030607@mail.de>
 <CACac1F9_e+_OJuUL29NsrLb5FOEjbqgN5khbWAKxpdwQvHjiOw@mail.gmail.com>
 <55FD9828.2050608@mail.de>
Message-ID: <CACac1F8ciF15ZUDsh0X_nLs9vYgOqa9XUi+mL3nGLqt+uWdsUw@mail.gmail.com>

On 19 September 2015 at 18:15, Sven R. Kunze <srkunze at mail.de> wrote:
>> So, to directly answer:
>>
>>      Because there are technical challenges that no-one has stepped up to
>> solve.
>
>
> Let's solve them. :)

I thought my point was "yes, go for it - your code contribution would
be appreciated" :-)
Paul

From srkunze at mail.de  Sat Sep 19 19:37:06 2015
From: srkunze at mail.de (Sven R. Kunze)
Date: Sat, 19 Sep 2015 19:37:06 +0200
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <CACac1F8ciF15ZUDsh0X_nLs9vYgOqa9XUi+mL3nGLqt+uWdsUw@mail.gmail.com>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>	<20150917150458.75c85727@limelight.wooz.org>	<CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>	<20150918111602.54ab56c5@limelight.wooz.org>	<87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>	<55FD2714.2030607@mail.de>	<CACac1F9_e+_OJuUL29NsrLb5FOEjbqgN5khbWAKxpdwQvHjiOw@mail.gmail.com>	<55FD9828.2050608@mail.de>
 <CACac1F8ciF15ZUDsh0X_nLs9vYgOqa9XUi+mL3nGLqt+uWdsUw@mail.gmail.com>
Message-ID: <55FD9D42.5020808@mail.de>

On 19.09.2015 19:19, Paul Moore wrote:
> I thought my point was "yes, go for it - your code contribution would 
> be appreciated" :-) Paul 

Well, before coding shouldn't we have vision and a plan for pip somehow 
and pinpoint it somewhere where everybody who's willing to contribute 
can see it?

Don't get me wrong, I'd be glad to contribute code (what I've already 
done to other open-source projects), but I feel somewhat disoriented 
when in comes to "Python core".

Best,
Sven

From brett at python.org  Sat Sep 19 20:37:41 2015
From: brett at python.org (Brett Cannon)
Date: Sat, 19 Sep 2015 18:37:41 +0000
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <55FD9D42.5020808@mail.de>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
 <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
 <20150918111602.54ab56c5@limelight.wooz.org>
 <87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>
 <55FD2714.2030607@mail.de>
 <CACac1F9_e+_OJuUL29NsrLb5FOEjbqgN5khbWAKxpdwQvHjiOw@mail.gmail.com>
 <55FD9828.2050608@mail.de>
 <CACac1F8ciF15ZUDsh0X_nLs9vYgOqa9XUi+mL3nGLqt+uWdsUw@mail.gmail.com>
 <55FD9D42.5020808@mail.de>
Message-ID: <CAP1=2W4CYuyMH_7-DPZB1se+p087A0Y6u=LfU_g+Dv2wv=z1Eg@mail.gmail.com>

Guys, this thread is about removing the pyvenv script, not pip. If you want
to start a discussion about pip and its command structure that should
probably happen on pip's issue tracker or over at distutils-sig.

On Sat, 19 Sep 2015 at 10:37 Sven R. Kunze <srkunze at mail.de> wrote:

> On 19.09.2015 19:19, Paul Moore wrote:
> > I thought my point was "yes, go for it - your code contribution would
> > be appreciated" :-) Paul
>
> Well, before coding shouldn't we have vision and a plan for pip somehow
> and pinpoint it somewhere where everybody who's willing to contribute
> can see it?
>
> Don't get me wrong, I'd be glad to contribute code (what I've already
> done to other open-source projects), but I feel somewhat disoriented
> when in comes to "Python core".
>
> Best,
> Sven
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150919/a280cdb7/attachment.html>

From storchaka at gmail.com  Sat Sep 19 21:22:32 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 19 Sep 2015 22:22:32 +0300
Subject: [Python-Dev] PEP 498 (interpolated f-string) tweak
In-Reply-To: <55FD40E9.4010708@trueblade.com>
References: <55FD40E9.4010708@trueblade.com>
Message-ID: <mtkclp$gqu$1@ger.gmane.org>

On 19.09.15 14:03, Eric V. Smith wrote:
> While finishing up the implementation of PEP 498, I realized that the
> PEP has an error. It says that this code:
>
> f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
>
> Is equivalent to:
>
> 'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
> + str(expr3).__format__('') + 'ghi'
>
> But that's not correct. The right way to call __format__ is:
>
> type(expr1).__format__(expr1, spec1)
>
> That is, the lookup of __format__ is done on the type, not the instance.
>
> Instead of calling __format__, I've changed the code generator to call
> format(expr1, spec1). As an optimization, I might add special opcodes to
> deal with this and string concatenation, but that's for another day (if
> ever).

Concatenating many strings is not efficient. More efficient way is to 
use string formatting. Why not translate f-string to

     'abc%s%sdef%sghi' % (format(expr1, spec1),
                          format(repr(expr2), spec2), expr3)

or even to

     'abc{:spec1}{!r:spec2}def{!s}ghi'.format(expr1, expr2, expr3)

?



From eric at trueblade.com  Sat Sep 19 21:36:40 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Sat, 19 Sep 2015 15:36:40 -0400
Subject: [Python-Dev] PEP 498 (interpolated f-string) tweak
In-Reply-To: <mtkclp$gqu$1@ger.gmane.org>
References: <55FD40E9.4010708@trueblade.com> <mtkclp$gqu$1@ger.gmane.org>
Message-ID: <55FDB948.4010405@trueblade.com>

On 9/19/2015 3:22 PM, Serhiy Storchaka wrote:
> On 19.09.15 14:03, Eric V. Smith wrote:
>> While finishing up the implementation of PEP 498, I realized that the
>> PEP has an error. It says that this code:
>>
>> f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
>>
>> Is equivalent to:
>>
>> 'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
>> + str(expr3).__format__('') + 'ghi'
>>
>> But that's not correct. The right way to call __format__ is:
>>
>> type(expr1).__format__(expr1, spec1)
>>
>> That is, the lookup of __format__ is done on the type, not the instance.
>>
>> Instead of calling __format__, I've changed the code generator to call
>> format(expr1, spec1). As an optimization, I might add special opcodes to
>> deal with this and string concatenation, but that's for another day (if
>> ever).
> 
> Concatenating many strings is not efficient. More efficient way is to
> use string formatting. Why not translate f-string to
> 
>     'abc%s%sdef%sghi' % (format(expr1, spec1),
>                          format(repr(expr2), spec2), expr3)

As the PEP says, the expression with '+' is illustrative, not how it's
actually implemented. The implementation currently uses ''.join,
although I reserve the right to change it.

> or even to
> 
>     'abc{:spec1}{!r:spec2}def{!s}ghi'.format(expr1, expr2, expr3)

That's surprisingly difficult to get right. I've implemented the code at
least 3 different ways, and the current implementation seems the most
straightforward. I might add a special opcode to use a _PyUncode_Writer,
though.

Eric.

From p.f.moore at gmail.com  Sat Sep 19 21:45:51 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 19 Sep 2015 20:45:51 +0100
Subject: [Python-Dev] Proposing the deprecation of the pyvenv script
In-Reply-To: <CAP1=2W4CYuyMH_7-DPZB1se+p087A0Y6u=LfU_g+Dv2wv=z1Eg@mail.gmail.com>
References: <CAP1=2W7A-G03r3w45VsR6H3tzhZ8LB=QOqr8Y2NQQ-aTQppdUQ@mail.gmail.com>
 <20150917150458.75c85727@limelight.wooz.org>
 <CADiSq7ewY5yf9PAd+HXRpsTeKCWg3qnXGgMF_=v+gJQ9Fv6rUA@mail.gmail.com>
 <20150918111602.54ab56c5@limelight.wooz.org>
 <87bnczyoan.fsf@uwakimon.sk.tsukuba.ac.jp>
 <55FD2714.2030607@mail.de>
 <CACac1F9_e+_OJuUL29NsrLb5FOEjbqgN5khbWAKxpdwQvHjiOw@mail.gmail.com>
 <55FD9828.2050608@mail.de>
 <CACac1F8ciF15ZUDsh0X_nLs9vYgOqa9XUi+mL3nGLqt+uWdsUw@mail.gmail.com>
 <55FD9D42.5020808@mail.de>
 <CAP1=2W4CYuyMH_7-DPZB1se+p087A0Y6u=LfU_g+Dv2wv=z1Eg@mail.gmail.com>
Message-ID: <CACac1F8+Ej5jAuq8VEid_NX1P4+2_dXrgv8Drn=4kxbzWqRAuw@mail.gmail.com>

On 19 September 2015 at 19:37, Brett Cannon <brett at python.org> wrote:
> Guys, this thread is about removing the pyvenv script, not pip. If you want
> to start a discussion about pip and its command structure that should
> probably happen on pip's issue tracker or over at distutils-sig.

Sorry, good point.

Back to the original question, I'm +1 on deprecating pyvenv as described.
Paul

From eric at trueblade.com  Sat Sep 19 22:53:23 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Sat, 19 Sep 2015 16:53:23 -0400
Subject: [Python-Dev] PEP 498 (interpolated f-string) tweak
In-Reply-To: <55FDB948.4010405@trueblade.com>
References: <55FD40E9.4010708@trueblade.com> <mtkclp$gqu$1@ger.gmane.org>
 <55FDB948.4010405@trueblade.com>
Message-ID: <55FDCB43.80605@trueblade.com>

On 9/19/2015 3:36 PM, Eric V. Smith wrote:
> On 9/19/2015 3:22 PM, Serhiy Storchaka wrote:
>> On 19.09.15 14:03, Eric V. Smith wrote:
>>> Instead of calling __format__, I've changed the code generator to call
>>> format(expr1, spec1). As an optimization, I might add special opcodes to
>>> deal with this and string concatenation, but that's for another day (if
>>> ever).
>>
>> Concatenating many strings is not efficient. More efficient way is to
>> use string formatting. Why not translate f-string to
>>
>>     'abc%s%sdef%sghi' % (format(expr1, spec1),
>>                          format(repr(expr2), spec2), expr3)
> 
> As the PEP says, the expression with '+' is illustrative, not how it's
> actually implemented. The implementation currently uses ''.join,
> although I reserve the right to change it.

I should also note: an earlier version of the PEP showed the ''.join()
version of the equivalent code, but the feedback was that it was
confusing, and the '+' version was easier to understand.

And another reason that I don't use %-formatting or ''.format() as the
implementation is for performance: the parser spends a lot of effort to
parse the f-string. To then put it back together and have ''.format()
immediately re-parse it didn't make much sense. And I'm not convinced
there aren't edge cases where the f-string parser and the ''.format()
parse differ, especially when dealing with nested format_specs with
funky characters.

Instead, I generate two additional AST nodes: ast.FormattedValue and
ast.JoinedStr. JoinedStr just has list of string expressions which get
joined together (as I said: currently using ''.join()). FormattedValue
contains the expression and its optional conversion character and
optional format_spec, which get formatted into a string (currently using
the builtin format()).

Eric.


From rosuav at gmail.com  Sun Sep 20 00:42:15 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Sun, 20 Sep 2015 08:42:15 +1000
Subject: [Python-Dev] PEP 498 (interpolated f-string) tweak
In-Reply-To: <55FDB948.4010405@trueblade.com>
References: <55FD40E9.4010708@trueblade.com> <mtkclp$gqu$1@ger.gmane.org>
 <55FDB948.4010405@trueblade.com>
Message-ID: <CAPTjJmr7_VFS8DFTHdVC8_HbAeoUfDMi4aJpVT-D4Wsh_0dgug@mail.gmail.com>

On Sun, Sep 20, 2015 at 5:36 AM, Eric V. Smith <eric at trueblade.com> wrote:
> As the PEP says, the expression with '+' is illustrative, not how it's
> actually implemented. The implementation currently uses ''.join,
> although I reserve the right to change it.
>
>> or even to
>>
>>     'abc{:spec1}{!r:spec2}def{!s}ghi'.format(expr1, expr2, expr3)
>
> That's surprisingly difficult to get right. I've implemented the code at
> least 3 different ways, and the current implementation seems the most
> straightforward. I might add a special opcode to use a _PyUncode_Writer,
> though.

Since this is entirely under the control of the parser, there's no
particular reason to promise anything about the implementation or its
performance metrics. The semantics won't change if CPython 3.7.4
decides to change to using ''.join() instead of concatenation.

Let's not bikeshed the implementation details. I'm sure Eric knows
what he's doing.

ChrisA

From storchaka at gmail.com  Sun Sep 20 08:44:54 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sun, 20 Sep 2015 09:44:54 +0300
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
Message-ID: <mtlkl6$ur9$1@ger.gmane.org>

For now the default value of the stacklevel parameter in warnings.warn() 
is 1. But in most cases stacklevel=2 is required, sometimes >2, and I 
don't know cases that need stacklevel=1. I propose to make the default 
value of stacklevel to be 2. I think that unlikely this will break 
existing code. But rather can fix existing bugs. If stacklevel=1 is 
required (I don't know cases), it can be explicitly specified.


From njs at pobox.com  Sun Sep 20 08:55:44 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Sat, 19 Sep 2015 23:55:44 -0700
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <mtlkl6$ur9$1@ger.gmane.org>
References: <mtlkl6$ur9$1@ger.gmane.org>
Message-ID: <CAPJVwBmftOk7Tu14a=XuBX638V-X7BFheRMx9EY1yGaJvpY4wQ@mail.gmail.com>

On Sat, Sep 19, 2015 at 11:44 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> For now the default value of the stacklevel parameter in warnings.warn() is
> 1. But in most cases stacklevel=2 is required, sometimes >2, and I don't
> know cases that need stacklevel=1. I propose to make the default value of
> stacklevel to be 2. I think that unlikely this will break existing code. But
> rather can fix existing bugs. If stacklevel=1 is required (I don't know
> cases), it can be explicitly specified.

+1

I don't have enough fingers to count how many times I've had to
explain how stacklevel= works to maintainers of widely-used packages
-- they had no idea that this was even a thing they were getting
wrong.

OTOH I guess if there is anyone out there who's intentionally using
stacklevel=1 they might be reasonably surprised at this change. I
guess for some kinds of warnings stacklevel=2 is not obviously correct
-- the one that comes to mind is "warning: the computer on the other
end of this network connection did something weird, continuing
anyway". OTOOH in this case I'm not sure stacklevel=1 is any better
either, since the thing being warned about has nothing to do with the
current call stack at all.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

From storchaka at gmail.com  Sun Sep 20 09:20:07 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sun, 20 Sep 2015 10:20:07 +0300
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <CAPJVwBmftOk7Tu14a=XuBX638V-X7BFheRMx9EY1yGaJvpY4wQ@mail.gmail.com>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAPJVwBmftOk7Tu14a=XuBX638V-X7BFheRMx9EY1yGaJvpY4wQ@mail.gmail.com>
Message-ID: <2402881.tluj8IBVTP@raxxla>

??????, 19-???-2015 23:55:44 Nathaniel Smith ????????:
> OTOH I guess if there is anyone out there who's intentionally using
> stacklevel=1 they might be reasonably surprised at this change.

That is why I ask on Python-Dev instead of just open an issue.

But I doubt that there is such case.
 

From breamoreboy at yahoo.co.uk  Sun Sep 20 10:03:59 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Sun, 20 Sep 2015 09:03:59 +0100
Subject: [Python-Dev] My collection of Python 3.5.0 regressions
In-Reply-To: <87a8sjynmr.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAMpsgwYS=rM1o0BFw8ZKTp8vtuS87iuoXfbiHS0=06=KZYj-iQ@mail.gmail.com>
 <20150918152736.D88BDB1408E@webabinitio.net> <mthc4u$8s0$1@ger.gmane.org>
 <87a8sjynmr.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <mtlp9t$u8o$1@ger.gmane.org>

On 19/09/2015 06:38, Stephen J. Turnbull wrote:
> Mark Lawrence writes:
>
>   > I agree very strongly with your point here.  Raising umpteen issues
>   > over installation failures when a full release comes out strikes me
>   > as below the belt when there have been multiple previous releases
>   > without a squeak.
>
> Raising issues is always useful and appropriate.  It's up to Larry
> Hastings to decide whether he personally needs to do more work.

My point is that issues were raised after the full release was made, but 
no attempt was made to test for these problems in any of the previous 
releases, whether alpha, beta or release candidate.  There was advance 
warning here http://stevedower.id.au/blog/the-python-3-5-installer/, 
which was flagged up here 
http://www.gossamer-threads.com/lists/python/dev/1175080. Larry doesn't 
need to do anything that I'm aware of, except perhaps be guided by our 
windows gurus.

>
> I suspect he probably will, though.  I knew these changes were risky
> on the lead time given, even though I don't do Windows, and I'm not a
> core Python developer.  I would hope that Steve Dower and Larry were
> at least as well aware of what they were getting into, and there are a
> lot of Windows users we *want* to support well.  (*Not* "have to", and
> YMMV.  But the Python developer community clearly has a working
> consensus on supporting Windows well.)
>

I'm certain that Steve was well aware of what he was getting into, 
Larry, at least with respect to Windows, I'm not so sure about.  Not 
that it really matters to me.  All I know is that the build procedures 
have been made easier on Windows, thanks mostly to Steve and Zach Ware 
in recent years, building on work done by Tim Golden, Martin v. L?wis 
and Mark Hammond amongst others.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From gjcarneiro at gmail.com  Sun Sep 20 12:27:00 2015
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Sun, 20 Sep 2015 11:27:00 +0100
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <CAPJVwBmftOk7Tu14a=XuBX638V-X7BFheRMx9EY1yGaJvpY4wQ@mail.gmail.com>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAPJVwBmftOk7Tu14a=XuBX638V-X7BFheRMx9EY1yGaJvpY4wQ@mail.gmail.com>
Message-ID: <CAO-CpEJN6GtB6h2KUX3=EdEcS0Vb4LBSfRrhdP1YB+z8Cnpjog@mail.gmail.com>

On 20 September 2015 at 07:55, Nathaniel Smith <njs at pobox.com> wrote:

> On Sat, Sep 19, 2015 at 11:44 PM, Serhiy Storchaka <storchaka at gmail.com>
> wrote:
> > For now the default value of the stacklevel parameter in warnings.warn()
> is
> > 1. But in most cases stacklevel=2 is required, sometimes >2, and I don't
> > know cases that need stacklevel=1. I propose to make the default value of
> > stacklevel to be 2. I think that unlikely this will break existing code.
> But
> > rather can fix existing bugs. If stacklevel=1 is required (I don't know
> > cases), it can be explicitly specified.
>
> +1
>
> I don't have enough fingers to count how many times I've had to
> explain how stacklevel= works to maintainers of widely-used packages
> -- they had no idea that this was even a thing they were getting
> wrong.
>
> OTOH I guess if there is anyone out there who's intentionally using
> stacklevel=1 they might be reasonably surprised at this change. I
> guess for some kinds of warnings stacklevel=2 is not obviously correct
> -- the one that comes to mind is "warning: the computer on the other
> end of this network connection did something weird, continuing
> anyway". OTOOH in this case I'm not sure stacklevel=1 is any better
> either, since the thing being warned about has nothing to do with the
> current call stack at all.
>

In this case you should use the logging module instead.

-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150920/54d9f022/attachment.html>

From ncoghlan at gmail.com  Sun Sep 20 14:37:21 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Sep 2015 22:37:21 +1000
Subject: [Python-Dev] PEP 498 (interpolated f-string) tweak
In-Reply-To: <55FD40E9.4010708@trueblade.com>
References: <55FD40E9.4010708@trueblade.com>
Message-ID: <CADiSq7czpk1qQpfsDQMfxKSY_=hCmH3VwN-P5OK0s67OVn_nRg@mail.gmail.com>

On 19 September 2015 at 21:03, Eric V. Smith <eric at trueblade.com> wrote:
> While finishing up the implementation of PEP 498, I realized that the
> PEP has an error. It says that this code:
>
> f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
>
> Is equivalent to:
>
> 'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
> + str(expr3).__format__('') + 'ghi'
>
> But that's not correct. The right way to call __format__ is:
>
> type(expr1).__format__(expr1, spec1)
>
> That is, the lookup of __format__ is done on the type, not the instance.
>
> Instead of calling __format__, I've changed the code generator to call
> format(expr1, spec1). As an optimization, I might add special opcodes to
> deal with this and string concatenation, but that's for another day (if
> ever).

Does this mean overriding format at the module level or in builtins
will affect the way f-strings are evaluated at runtime? (I don't have
a strong preference one way or the other, but I think the PEP should
be explicit as to the expected behaviour rather than leaving it as
implementation defined).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Sun Sep 20 14:47:02 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Sep 2015 22:47:02 +1000
Subject: [Python-Dev] My collection of Python 3.5.0 regressions
In-Reply-To: <mtlp9t$u8o$1@ger.gmane.org>
References: <CAMpsgwYS=rM1o0BFw8ZKTp8vtuS87iuoXfbiHS0=06=KZYj-iQ@mail.gmail.com>
 <20150918152736.D88BDB1408E@webabinitio.net>
 <mthc4u$8s0$1@ger.gmane.org>
 <87a8sjynmr.fsf@uwakimon.sk.tsukuba.ac.jp>
 <mtlp9t$u8o$1@ger.gmane.org>
Message-ID: <CADiSq7e_jqeaQpQtDWyBaOWyKmeJTxd2wX9dj3muHJKK=ieiSQ@mail.gmail.com>

On 20 September 2015 at 18:03, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> I'm certain that Steve was well aware of what he was getting into, Larry, at
> least with respect to Windows, I'm not so sure about.  Not that it really
> matters to me.  All I know is that the build procedures have been made
> easier on Windows, thanks mostly to Steve and Zach Ware in recent years,
> building on work done by Tim Golden, Martin v. L?wis and Mark Hammond
> amongst others.

>From a process perspective, the release manager is responsible for
wrangling the release process, tagging the source tree, and creating
and publishing the source tarball, but the binary installers are in
the hands of the platform specialists listed in the release PEP
(https://www.python.org/dev/peps/pep-0478/ in the case of 3.5).

The full release process is at
https://www.python.org/dev/peps/pep-0101/, which has details of the
unfortunately manual Windows installation testing process at the end.
It might be interesting to see if running the installs at least in
quiet mode could be automated on Appveyor to reduce the manual testing
requirements.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From eric at trueblade.com  Sun Sep 20 15:51:06 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Sun, 20 Sep 2015 09:51:06 -0400
Subject: [Python-Dev] PEP 498 (interpolated f-string) tweak
In-Reply-To: <CADiSq7czpk1qQpfsDQMfxKSY_=hCmH3VwN-P5OK0s67OVn_nRg@mail.gmail.com>
References: <55FD40E9.4010708@trueblade.com>
 <CADiSq7czpk1qQpfsDQMfxKSY_=hCmH3VwN-P5OK0s67OVn_nRg@mail.gmail.com>
Message-ID: <55FEB9CA.4030509@trueblade.com>

On 9/20/2015 8:37 AM, Nick Coghlan wrote:
> On 19 September 2015 at 21:03, Eric V. Smith <eric at trueblade.com> wrote:
>> Instead of calling __format__, I've changed the code generator to call
>> format(expr1, spec1). As an optimization, I might add special opcodes to
>> deal with this and string concatenation, but that's for another day (if
>> ever).
> 
> Does this mean overriding format at the module level or in builtins
> will affect the way f-strings are evaluated at runtime? (I don't have
> a strong preference one way or the other, but I think the PEP should
> be explicit as to the expected behaviour rather than leaving it as
> implementation defined).

Yes, in the current implementation, if you mess with format(), str(),
repr(), or ascii() you can break f-strings. The latter 3 are used to
implement !s, !r, and !a.

I have a plan to change this, by adding one or more opcodes to implement
the formatting and string joining. I'll defer a decision on updating the
PEP until I can establish the feasibility (and desirability) of that
approach.

Eric.

From storchaka at gmail.com  Sun Sep 20 17:15:23 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sun, 20 Sep 2015 18:15:23 +0300
Subject: [Python-Dev] PEP 498 (interpolated f-string) tweak
In-Reply-To: <55FEB9CA.4030509@trueblade.com>
References: <55FD40E9.4010708@trueblade.com>
 <CADiSq7czpk1qQpfsDQMfxKSY_=hCmH3VwN-P5OK0s67OVn_nRg@mail.gmail.com>
 <55FEB9CA.4030509@trueblade.com>
Message-ID: <mtmiic$udr$1@ger.gmane.org>

On 20.09.15 16:51, Eric V. Smith wrote:
> On 9/20/2015 8:37 AM, Nick Coghlan wrote:
>> On 19 September 2015 at 21:03, Eric V. Smith <eric at trueblade.com> wrote:
>>> Instead of calling __format__, I've changed the code generator to call
>>> format(expr1, spec1). As an optimization, I might add special opcodes to
>>> deal with this and string concatenation, but that's for another day (if
>>> ever).
>>
>> Does this mean overriding format at the module level or in builtins
>> will affect the way f-strings are evaluated at runtime? (I don't have
>> a strong preference one way or the other, but I think the PEP should
>> be explicit as to the expected behaviour rather than leaving it as
>> implementation defined).
>
> Yes, in the current implementation, if you mess with format(), str(),
> repr(), or ascii() you can break f-strings. The latter 3 are used to
> implement !s, !r, and !a.
>
> I have a plan to change this, by adding one or more opcodes to implement
> the formatting and string joining. I'll defer a decision on updating the
> PEP until I can establish the feasibility (and desirability) of that
> approach.

I propose to add internal builting formatter type. Instances should be 
marshallable and callable. The code generated for f-strings should just 
load formatter constant and call it with arguments. The formatter builds 
resulting string by concatenating literal strings and results of 
formatting arguments with specified specifications.

Later we could change compiler (just peephole optimizer?) to replace 
literal_string.format(*args) and literal_string % args with calling 
precompiled formatter.

Later we could rewrite str.format, str.__mod__ and re.sub to create 
temporary formatter object and call it.

Later we could expose public API for creating formatter object. It can 
be used by third-party template engines.



From eric at trueblade.com  Sun Sep 20 21:22:55 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Sun, 20 Sep 2015 15:22:55 -0400
Subject: [Python-Dev] PEP 498 (interpolated f-string) tweak
In-Reply-To: <mtmiic$udr$1@ger.gmane.org>
References: <55FD40E9.4010708@trueblade.com>
 <CADiSq7czpk1qQpfsDQMfxKSY_=hCmH3VwN-P5OK0s67OVn_nRg@mail.gmail.com>
 <55FEB9CA.4030509@trueblade.com> <mtmiic$udr$1@ger.gmane.org>
Message-ID: <0F093137-42B7-4AA8-97D0-33B736F13E56@trueblade.com>


> On Sep 20, 2015, at 11:15 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 
>> On 20.09.15 16:51, Eric V. Smith wrote:
>>> On 9/20/2015 8:37 AM, Nick Coghlan wrote:
>>>> On 19 September 2015 at 21:03, Eric V. Smith <eric at trueblade.com> wrote:
>>>> Instead of calling __format__, I've changed the code generator to call
>>>> format(expr1, spec1). As an optimization, I might add special opcodes to
>>>> deal with this and string concatenation, but that's for another day (if
>>>> ever).
>>> 
>>> Does this mean overriding format at the module level or in builtins
>>> will affect the way f-strings are evaluated at runtime? (I don't have
>>> a strong preference one way or the other, but I think the PEP should
>>> be explicit as to the expected behaviour rather than leaving it as
>>> implementation defined).
>> 
>> Yes, in the current implementation, if you mess with format(), str(),
>> repr(), or ascii() you can break f-strings. The latter 3 are used to
>> implement !s, !r, and !a.
>> 
>> I have a plan to change this, by adding one or more opcodes to implement
>> the formatting and string joining. I'll defer a decision on updating the
>> PEP until I can establish the feasibility (and desirability) of that
>> approach.
> 
> I propose to add internal builting formatter type. Instances should be marshallable and callable. The code generated for f-strings should just load formatter constant and call it with arguments. The formatter builds resulting string by concatenating literal strings and results of formatting arguments with specified specifications.
> 
> Later we could change compiler (just peephole optimizer?) to replace literal_string.format(*args) and literal_string % args with calling precompiled formatter.
> 
> Later we could rewrite str.format, str.__mod__ and re.sub to create temporary formatter object and call it.
> 
> Later we could expose public API for creating formatter object. It can be used by third-party template engines.
> 

I think this is InterpolationTemplate from PEP 501.

Eric. 


From larry at hastings.org  Sun Sep 20 23:26:51 2015
From: larry at hastings.org (Larry Hastings)
Date: Sun, 20 Sep 2015 22:26:51 +0100
Subject: [Python-Dev] Is there an official order for Misc/NEWS sections?
Message-ID: <55FF249B.5070609@hastings.org>



What is the official order for sections in Misc/NEWS?  I'm sure that 
"Core and Builtins" is first, and "Library" is second, but after that... 
I'm not sure.

This seems about right, though I'm not certain we're 100% consistent 
about it:
     Core and Builtins
     Library
     IDLE
     Documentation
     Tests
     Build
     Windows
     Tools/Demos
     C API

Is it documented anywhere?  I didn't see it in the Dev Guide.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150920/7c5aac4e/attachment.html>

From brett at python.org  Mon Sep 21 01:49:00 2015
From: brett at python.org (Brett Cannon)
Date: Sun, 20 Sep 2015 23:49:00 +0000
Subject: [Python-Dev] Is there an official order for Misc/NEWS sections?
In-Reply-To: <55FF249B.5070609@hastings.org>
References: <55FF249B.5070609@hastings.org>
Message-ID: <CAP1=2W6Q-zK6nh7DvzpGxLK8J7LdNXe8oqV6MYHT6yv6yJS8rA@mail.gmail.com>

There is no official order to the NEWS file. I know I have always just
referred to the last release when trying to decide whether to stick a
section.

On Sun, Sep 20, 2015, 14:27 Larry Hastings <larry at hastings.org> wrote:

>
>
> What is the official order for sections in Misc/NEWS?  I'm sure that "Core
> and Builtins" is first, and "Library" is second, but after that... I'm not
> sure.
>
> This seems about right, though I'm not certain we're 100% consistent about
> it:
>     Core and Builtins
>     Library
>     IDLE
>     Documentation
>     Tests
>     Build
>     Windows
>     Tools/Demos
>     C API
>
> Is it documented anywhere?  I didn't see it in the Dev Guide.
>
>
> */arry*
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150920/fd975a4e/attachment.html>

From alexander.belopolsky at gmail.com  Mon Sep 21 05:49:22 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Sun, 20 Sep 2015 23:49:22 -0400
Subject: [Python-Dev] PEP 495 (Local Time Disambiguation) is ready for
	pronouncement
In-Reply-To: <CAP7h-xapmYDX_5=a4ODBrd+ZTSkOja49JNYxES5p2jtOs+gMsA@mail.gmail.com>
References: <CAP7h-xapmYDX_5=a4ODBrd+ZTSkOja49JNYxES5p2jtOs+gMsA@mail.gmail.com>
Message-ID: <CAP7h-xYVZCtFxrtC=xxX=X2K0ZPHjvK9pRyCaTjRN_NFRqybRg@mail.gmail.com>

On Sat, Aug 15, 2015 at 8:49 PM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:
>
> PEP 495 [1] is a deliberately minimalistic proposal to remove an
> ambiguity in representing some local times as datetime.datetime
> objects.

A major issue has come up since my announcement above.  Tim Peters have
noticed that PEP 495 would violate the "hash invariant" unless the fold
attribute is accounted for in inter-zone comparisons.
See [2] for details.  This issue has been resolved by modifying the
definition [3] of the "==" operator for aware datetimes with post-PEP
tzinfo.  Note that no program will be affected by this change unless it
uses a post-PEP tzinfo implementation.

I made some smaller changes [4] to the PEP as well and it should finally be
ready for pronouncement.

[1]: https://www.python.org/dev/peps/pep-0495
[2]:
https://mail.python.org/pipermail/datetime-sig/2015-September/000625.html
[3]:
https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison
[4]: https://hg.python.org/peps/log/39b7c1da05a2/pep-0495.txt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150920/a68615fe/attachment.html>

From victor.stinner at gmail.com  Mon Sep 21 09:14:07 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 21 Sep 2015 09:14:07 +0200
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <mtlkl6$ur9$1@ger.gmane.org>
References: <mtlkl6$ur9$1@ger.gmane.org>
Message-ID: <CAMpsgwZz394wBMt-8Ge+Nbr22eHsb080uh-Zu2naBaU56DWyag@mail.gmail.com>

Would it be too verbose to display two frames or more by default?
Maybe depending on the action (ex: only if the warning is emitted only
once).

Victor

2015-09-20 8:44 GMT+02:00 Serhiy Storchaka <storchaka at gmail.com>:
> For now the default value of the stacklevel parameter in warnings.warn() is
> 1. But in most cases stacklevel=2 is required, sometimes >2, and I don't
> know cases that need stacklevel=1. I propose to make the default value of
> stacklevel to be 2. I think that unlikely this will break existing code. But
> rather can fix existing bugs. If stacklevel=1 is required (I don't know
> cases), it can be explicitly specified.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com

From victor.stinner at gmail.com  Mon Sep 21 09:18:28 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 21 Sep 2015 09:18:28 +0200
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <mtlkl6$ur9$1@ger.gmane.org>
References: <mtlkl6$ur9$1@ger.gmane.org>
Message-ID: <CAMpsgwZWyXbOm6qj4mPjO2cPo=CjzS9c2JSTAcUdjmYkXEzsmQ@mail.gmail.com>

2015-09-20 8:44 GMT+02:00 Serhiy Storchaka <storchaka at gmail.com>:
> I propose to make the default value of stacklevel to be 2.
> I think that unlikely this will break existing code.

Consider this simple script:
---
import warnings
warnings.warn("here")
---

Currrent output:
---
x.py:3: UserWarning: here
  warnings.warn("here")
---

=> it shows the script name (x.py), the line number and the line, as expected.

Now try stacklevel=2:
---
import warnings
warnings.warn("here", stacklevel=2)
---

New output:
---
sys:1: UserWarning: here
---

"sys:1" is not really useful :-/

I would describe this as a regression, not an enhancement.

It's hard to find a "good" default value. It's better to always
specify stacklevel :-)

Victor

From njs at pobox.com  Mon Sep 21 09:21:53 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 21 Sep 2015 00:21:53 -0700
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <CAMpsgwZz394wBMt-8Ge+Nbr22eHsb080uh-Zu2naBaU56DWyag@mail.gmail.com>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZz394wBMt-8Ge+Nbr22eHsb080uh-Zu2naBaU56DWyag@mail.gmail.com>
Message-ID: <CAPJVwBnkniG3VAXNDDUGO=0K_VSC7CeQGPd5pdLpxBKysNQqmQ@mail.gmail.com>

On Sep 21, 2015 12:15 AM, "Victor Stinner" <victor.stinner at gmail.com> wrote:
>
> Would it be too verbose to display two frames or more by default?
> Maybe depending on the action (ex: only if the warning is emitted only
> once).

It's not just about how it gets displayed -- the frame that it gets
"attributed" to is also used when comparing against the warnings filters to
determine what action to take. What if stacklevel=1 makes it match a filter
with action "ignore", and stacklevel=2 makes it match a filter with action
"raise"?

(This is a common example I've encountered in the context of wanting to set
up CI tests so that if *my* code uses deprecated functionality then I want
to fail the test so I notice, but if some library I'm using uses deprecated
functionality internally then that's not my problem. This breaks down when
the library makes the common error of issuing DeprecationWarnings with
stacklevel=1, because that makes python think that they are deprecating
themselves, not warning that I did something deprecated.)

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150921/f25278f0/attachment.html>

From ncoghlan at gmail.com  Mon Sep 21 10:31:24 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 21 Sep 2015 18:31:24 +1000
Subject: [Python-Dev] PEP 498 (interpolated f-string) tweak
In-Reply-To: <0F093137-42B7-4AA8-97D0-33B736F13E56@trueblade.com>
References: <55FD40E9.4010708@trueblade.com>
 <CADiSq7czpk1qQpfsDQMfxKSY_=hCmH3VwN-P5OK0s67OVn_nRg@mail.gmail.com>
 <55FEB9CA.4030509@trueblade.com> <mtmiic$udr$1@ger.gmane.org>
 <0F093137-42B7-4AA8-97D0-33B736F13E56@trueblade.com>
Message-ID: <CADiSq7ef2s2Vu_5iwvw8R-aMFhArUE2ZnvHb=7tPYkK7HW1jxA@mail.gmail.com>

On 21 September 2015 at 05:22, Eric V. Smith <eric at trueblade.com> wrote:
>
>> On Sep 20, 2015, at 11:15 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
>>
>>> On 20.09.15 16:51, Eric V. Smith wrote:
>>>> On 9/20/2015 8:37 AM, Nick Coghlan wrote:
>>>>> On 19 September 2015 at 21:03, Eric V. Smith <eric at trueblade.com> wrote:
>>>>> Instead of calling __format__, I've changed the code generator to call
>>>>> format(expr1, spec1). As an optimization, I might add special opcodes to
>>>>> deal with this and string concatenation, but that's for another day (if
>>>>> ever).
>>>>
>>>> Does this mean overriding format at the module level or in builtins
>>>> will affect the way f-strings are evaluated at runtime? (I don't have
>>>> a strong preference one way or the other, but I think the PEP should
>>>> be explicit as to the expected behaviour rather than leaving it as
>>>> implementation defined).
>>>
>>> Yes, in the current implementation, if you mess with format(), str(),
>>> repr(), or ascii() you can break f-strings. The latter 3 are used to
>>> implement !s, !r, and !a.
>>>
>>> I have a plan to change this, by adding one or more opcodes to implement
>>> the formatting and string joining. I'll defer a decision on updating the
>>> PEP until I can establish the feasibility (and desirability) of that
>>> approach.
>>
>> I propose to add internal builting formatter type. Instances should be marshallable and callable. The code generated for f-strings should just load formatter constant and call it with arguments. The formatter builds resulting string by concatenating literal strings and results of formatting arguments with specified specifications.
>>
>> Later we could change compiler (just peephole optimizer?) to replace literal_string.format(*args) and literal_string % args with calling precompiled formatter.
>>
>> Later we could rewrite str.format, str.__mod__ and re.sub to create temporary formatter object and call it.
>>
>> Later we could expose public API for creating formatter object. It can be used by third-party template engines.
>>
>
> I think this is InterpolationTemplate from PEP 501.

It's certainly a similar idea, although PEP 501 just proposed storing
strings and tuples on the code object, with the interpolation template
itself still being a mutable object constructed at runtime. Serhiy's
suggestion goes a step further to suggest making the template itself
immutable, and passing in all the potentially mutable data as method
arguments.

I think there's a simpler approach available though, which is to go
the way we went in introducing first the __import__ builtin and later
the __build_class__ builtin to encapsulate some of the complexity of
their respective statements without requiring a raft of new opcodes.

The last draft of PEP 501 before I deferred it proposed the following
for interpolation templates, since it was able to rely on having
f-strings available as a primitive and wanted to offer more
flexibility than string formatting needs:

    _raw_template = "Substitute {names} and {expressions()} at runtime"
    _parsed_template = (
        ("Substitute ", "names"),
        (" and ", "expressions()"),
        (" at runtime", None),
    )
    _field_values = (names, expressions())
    _format_specifiers = (f"", f"")
    template = types.InterpolationTemplate(_raw_template,
                                          _parsed_template,
                                          _field_values,
                                          _format_specifiers)

A __format__ builtin (or a dedicated opcode) could use a simpler data
model that consisted of the following constant and variable elements:

Compile time constant: tuple of (<leading_text>,
<tuple_of_leading_specifier_elements>) pairs
Runtime variable: tuple of (<substitution_field_value>,
<tuple_of_specifier_substitution_field_values>) pairs

If the format string didn't end with a substitution field, then the
runtime variable tuple would be 1 element shorter than the constant
tuple.

With that approach, then __format__ (or an opcode that popped these
two tuples directly off the stack) could be defined as something like:

    def __format__(constant_parts, variable_parts):
        num_fields = len(variable_parts)
        segments = []
        for idx, (leading_text, specifier_constants) in constant_parts:
            segments.append(leading_text)
            if idx < num_fields:
                field_value, specifier_variables = variable_parts[idx]
                if specifier_variables:
                    specifier = __format__(specifier_constants,
specifier_variables)
                else:
                    assert len(specifier_constants) == 1
                    specifier = specifier_constants[0]
                if specifier.startswith("!"):
                    # Handle "!a", "!r", "!s" by modifying field_value
*and* specifier
                if specifier:
                    segments.append(format(field_value, specifier)
    return "".join(segments)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Mon Sep 21 11:05:34 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 21 Sep 2015 19:05:34 +1000
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <CAPJVwBnkniG3VAXNDDUGO=0K_VSC7CeQGPd5pdLpxBKysNQqmQ@mail.gmail.com>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZz394wBMt-8Ge+Nbr22eHsb080uh-Zu2naBaU56DWyag@mail.gmail.com>
 <CAPJVwBnkniG3VAXNDDUGO=0K_VSC7CeQGPd5pdLpxBKysNQqmQ@mail.gmail.com>
Message-ID: <CADiSq7dSL=N-u+zXXkJpkpeVxG03mrV_DSJvgPL685sHqLsfLA@mail.gmail.com>

On 21 September 2015 at 17:21, Nathaniel Smith <njs at pobox.com> wrote:
> On Sep 21, 2015 12:15 AM, "Victor Stinner" <victor.stinner at gmail.com> wrote:
>>
>> Would it be too verbose to display two frames or more by default?
>> Maybe depending on the action (ex: only if the warning is emitted only
>> once).
>
> It's not just about how it gets displayed -- the frame that it gets
> "attributed" to is also used when comparing against the warnings filters to
> determine what action to take. What if stacklevel=1 makes it match a filter
> with action "ignore", and stacklevel=2 makes it match a filter with action
> "raise"?
>
> (This is a common example I've encountered in the context of wanting to set
> up CI tests so that if *my* code uses deprecated functionality then I want
> to fail the test so I notice, but if some library I'm using uses deprecated
> functionality internally then that's not my problem. This breaks down when
> the library makes the common error of issuing DeprecationWarnings with
> stacklevel=1, because that makes python think that they are deprecating
> themselves, not warning that I did something deprecated.)

As Victor notes, though, that's not the right default for *scripts*
that are issuing deprecation warnings to end users - there, they
really are deprecating themselves. It's also not the right default for
pretty much any warning other than DeprecationWarning - for those,
you're generally wanting to say "we hit this problematic code path",
not report anything about your caller.

Passing "stacklevel=2" for API deprecations is by no means obvious
though, so perhaps it makes sense to add a
"warnings.warn_deprecated(message)" function that's implemented as:

    def warn_deprecated(message, stacklevel=1):
        return warnings.warn(message, DeprecationWarning,
stacklevel=(2+stacklevel)).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From guido at python.org  Mon Sep 21 17:08:25 2015
From: guido at python.org (Guido van Rossum)
Date: Mon, 21 Sep 2015 08:08:25 -0700
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <CADiSq7dSL=N-u+zXXkJpkpeVxG03mrV_DSJvgPL685sHqLsfLA@mail.gmail.com>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZz394wBMt-8Ge+Nbr22eHsb080uh-Zu2naBaU56DWyag@mail.gmail.com>
 <CAPJVwBnkniG3VAXNDDUGO=0K_VSC7CeQGPd5pdLpxBKysNQqmQ@mail.gmail.com>
 <CADiSq7dSL=N-u+zXXkJpkpeVxG03mrV_DSJvgPL685sHqLsfLA@mail.gmail.com>
Message-ID: <CAP7+vJLb=6kuDCZXVk+T4-H9MXR6C4cDA2uQb5WLraG4XeCmhQ@mail.gmail.com>

I think it's been conclusively shown that we should not change the default.
Instead I recommend updating the docs with an example showing when
stacklevel=2 is appropriate.

On Mon, Sep 21, 2015 at 2:05 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 21 September 2015 at 17:21, Nathaniel Smith <njs at pobox.com> wrote:
> > On Sep 21, 2015 12:15 AM, "Victor Stinner" <victor.stinner at gmail.com>
> wrote:
> >>
> >> Would it be too verbose to display two frames or more by default?
> >> Maybe depending on the action (ex: only if the warning is emitted only
> >> once).
> >
> > It's not just about how it gets displayed -- the frame that it gets
> > "attributed" to is also used when comparing against the warnings filters
> to
> > determine what action to take. What if stacklevel=1 makes it match a
> filter
> > with action "ignore", and stacklevel=2 makes it match a filter with
> action
> > "raise"?
> >
> > (This is a common example I've encountered in the context of wanting to
> set
> > up CI tests so that if *my* code uses deprecated functionality then I
> want
> > to fail the test so I notice, but if some library I'm using uses
> deprecated
> > functionality internally then that's not my problem. This breaks down
> when
> > the library makes the common error of issuing DeprecationWarnings with
> > stacklevel=1, because that makes python think that they are deprecating
> > themselves, not warning that I did something deprecated.)
>
> As Victor notes, though, that's not the right default for *scripts*
> that are issuing deprecation warnings to end users - there, they
> really are deprecating themselves. It's also not the right default for
> pretty much any warning other than DeprecationWarning - for those,
> you're generally wanting to say "we hit this problematic code path",
> not report anything about your caller.
>
> Passing "stacklevel=2" for API deprecations is by no means obvious
> though, so perhaps it makes sense to add a
> "warnings.warn_deprecated(message)" function that's implemented as:
>
>     def warn_deprecated(message, stacklevel=1):
>         return warnings.warn(message, DeprecationWarning,
> stacklevel=(2+stacklevel)).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150921/50e2f415/attachment.html>

From walter at livinglogic.de  Mon Sep 21 16:48:27 2015
From: walter at livinglogic.de (Walter =?utf-8?q?D=C3=B6rwald?=)
Date: Mon, 21 Sep 2015 16:48:27 +0200
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <CAMpsgwZWyXbOm6qj4mPjO2cPo=CjzS9c2JSTAcUdjmYkXEzsmQ@mail.gmail.com>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZWyXbOm6qj4mPjO2cPo=CjzS9c2JSTAcUdjmYkXEzsmQ@mail.gmail.com>
Message-ID: <C0573807-0859-43E6-8DFA-D5147407A980@livinglogic.de>

On 21 Sep 2015, at 9:18, Victor Stinner wrote:

> 2015-09-20 8:44 GMT+02:00 Serhiy Storchaka <storchaka at gmail.com>:
>> I propose to make the default value of stacklevel to be 2.
>> I think that unlikely this will break existing code.
>
> Consider this simple script:
> ---
> import warnings
> warnings.warn("here")
> ---
>
> Currrent output:
> ---
> x.py:3: UserWarning: here
> warnings.warn("here")
> ---
>
> => it shows the script name (x.py), the line number and the line, as 
> expected.
>
> Now try stacklevel=2:
> ---
> import warnings
> warnings.warn("here", stacklevel=2)
> ---
>
> New output:
> ---
> sys:1: UserWarning: here
> ---
>
> "sys:1" is not really useful :-/
>
> I would describe this as a regression, not an enhancement.
>
> It's hard to find a "good" default value. It's better to always
> specify stacklevel :-)

A "dynamic" stacklevel might help. Normally when you implement a call to 
warning.warn() inside a module, you want to report the innermost 
stacklevel that is outside of your module, because that's the spot where 
the error likely is. This could be done automatically (report the first 
module that is different from the one where the call to warning.warn() 
is), or by specifying a base package name or regular expression, i.e. 
report the innermost stackframe that is not from 
"mypackage.mysubpackage").

See http://bugs.python.org/issue850482

Bye,
    Walter D?rwald

From storchaka at gmail.com  Mon Sep 21 19:00:13 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Mon, 21 Sep 2015 20:00:13 +0300
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <CAMpsgwZWyXbOm6qj4mPjO2cPo=CjzS9c2JSTAcUdjmYkXEzsmQ@mail.gmail.com>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZWyXbOm6qj4mPjO2cPo=CjzS9c2JSTAcUdjmYkXEzsmQ@mail.gmail.com>
Message-ID: <mtpd2u$n0p$1@ger.gmane.org>

On 21.09.15 10:18, Victor Stinner wrote:
> 2015-09-20 8:44 GMT+02:00 Serhiy Storchaka <storchaka at gmail.com>:
>> I propose to make the default value of stacklevel to be 2.
>> I think that unlikely this will break existing code.
>
> Consider this simple script:
> ---
> import warnings
> warnings.warn("here")
> ---
>
> Currrent output:
> ---
> x.py:3: UserWarning: here
>    warnings.warn("here")
> ---
>
> => it shows the script name (x.py), the line number and the line, as expected.
>
> Now try stacklevel=2:
> ---
> import warnings
> warnings.warn("here", stacklevel=2)
> ---
>
> New output:
> ---
> sys:1: UserWarning: here
> ---
>
> "sys:1" is not really useful :-/

This is not new. The same output we get when run a module that correctly 
emits a warning at module level (with explicit stacklevel=2).

$ ./python -Wa Lib/imp.py
sys:1: PendingDeprecationWarning: the imp module is deprecated in favour 
of importlib; see the module's documentation for alternative uses

If this message looks confusing for you, we can avoid it if stop 
skipping frames further if frame.f_back is None. This will got rid of 
"sys:1:" in both cases, explicit and implicit stacklevel=2.



From storchaka at gmail.com  Mon Sep 21 19:14:41 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Mon, 21 Sep 2015 20:14:41 +0300
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <CADiSq7dSL=N-u+zXXkJpkpeVxG03mrV_DSJvgPL685sHqLsfLA@mail.gmail.com>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZz394wBMt-8Ge+Nbr22eHsb080uh-Zu2naBaU56DWyag@mail.gmail.com>
 <CAPJVwBnkniG3VAXNDDUGO=0K_VSC7CeQGPd5pdLpxBKysNQqmQ@mail.gmail.com>
 <CADiSq7dSL=N-u+zXXkJpkpeVxG03mrV_DSJvgPL685sHqLsfLA@mail.gmail.com>
Message-ID: <mtpdu2$576$1@ger.gmane.org>

On 21.09.15 12:05, Nick Coghlan wrote:
> As Victor notes, though, that's not the right default for *scripts*
> that are issuing deprecation warnings to end users - there, they
> really are deprecating themselves. It's also not the right default for
> pretty much any warning other than DeprecationWarning - for those,
> you're generally wanting to say "we hit this problematic code path",
> not report anything about your caller.

If a warning is emitted in library function, user can't do anything with 
function's code and should change his code that calls the function. In 
this case the warning should point to the line where the function is used.

If a warning is emitted in user's code, he is able to add explicit 
stacklevel=1 if needed.

stacklevel=2 is correct argument for module level warnings, but as 
Nathaniel noted not all packages use it. When your run correctly written 
module as script you get the same "sys:1:". And this issue can be solved 
in general case.

not allecause the user wants to get a warning at the place where the 
module is imported.

> Passing "stacklevel=2" for API deprecations is by no means obvious
> though, so perhaps it makes sense to add a
> "warnings.warn_deprecated(message)" function that's implemented as:
>
>      def warn_deprecated(message, stacklevel=1):
>          return warnings.warn(message, DeprecationWarning,
> stacklevel=(2+stacklevel)).

This will not fix tons of modules that are not aware of correct stacklevel.


From brett at python.org  Mon Sep 21 19:32:57 2015
From: brett at python.org (Brett Cannon)
Date: Mon, 21 Sep 2015 17:32:57 +0000
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <mtpdu2$576$1@ger.gmane.org>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZz394wBMt-8Ge+Nbr22eHsb080uh-Zu2naBaU56DWyag@mail.gmail.com>
 <CAPJVwBnkniG3VAXNDDUGO=0K_VSC7CeQGPd5pdLpxBKysNQqmQ@mail.gmail.com>
 <CADiSq7dSL=N-u+zXXkJpkpeVxG03mrV_DSJvgPL685sHqLsfLA@mail.gmail.com>
 <mtpdu2$576$1@ger.gmane.org>
Message-ID: <CAP1=2W7bUnqBzg951-abaH6MLQnnBeAYgrMsDXzoaw2a1MHPJw@mail.gmail.com>

On Mon, 21 Sep 2015 at 10:15 Serhiy Storchaka <storchaka at gmail.com> wrote:

> On 21.09.15 12:05, Nick Coghlan wrote:
> > As Victor notes, though, that's not the right default for *scripts*
> > that are issuing deprecation warnings to end users - there, they
> > really are deprecating themselves. It's also not the right default for
> > pretty much any warning other than DeprecationWarning - for those,
> > you're generally wanting to say "we hit this problematic code path",
> > not report anything about your caller.
>
> If a warning is emitted in library function, user can't do anything with
> function's code and should change his code that calls the function. In
> this case the warning should point to the line where the function is used.
>
> If a warning is emitted in user's code, he is able to add explicit
> stacklevel=1 if needed.
>
> stacklevel=2 is correct argument for module level warnings, but as
> Nathaniel noted not all packages use it. When your run correctly written
> module as script you get the same "sys:1:". And this issue can be solved
> in general case.
>
> not allecause the user wants to get a warning at the place where the
> module is imported.
>
> > Passing "stacklevel=2" for API deprecations is by no means obvious
> > though, so perhaps it makes sense to add a
> > "warnings.warn_deprecated(message)" function that's implemented as:
> >
> >      def warn_deprecated(message, stacklevel=1):
> >          return warnings.warn(message, DeprecationWarning,
> > stacklevel=(2+stacklevel)).
>
> This will not fix tons of modules that are not aware of correct stacklevel.
>

The long-term solution to this is to add a warnings.deprecate_module()
function which does the right thing and simply not expose the stacklevel
argument to users. We can then consider warnings.warn() more of a power
user function and make the stacklevel a keyword-only argument with no
default value (although I can already hear Raymond saying "but the Python 2
users" for that part of the idea =).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150921/9cf7c6c0/attachment.html>

From storchaka at gmail.com  Mon Sep 21 20:23:27 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Mon, 21 Sep 2015 21:23:27 +0300
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <mtpd2u$n0p$1@ger.gmane.org>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZWyXbOm6qj4mPjO2cPo=CjzS9c2JSTAcUdjmYkXEzsmQ@mail.gmail.com>
 <mtpd2u$n0p$1@ger.gmane.org>
Message-ID: <mtphuv$81t$1@ger.gmane.org>

On 21.09.15 20:00, Serhiy Storchaka wrote:
> On 21.09.15 10:18, Victor Stinner wrote:
>> ---
>> sys:1: UserWarning: here
>> ---
>>
>> "sys:1" is not really useful :-/
>
> This is not new. The same output we get when run a module that correctly
> emits a warning at module level (with explicit stacklevel=2).
>
> $ ./python -Wa Lib/imp.py
> sys:1: PendingDeprecationWarning: the imp module is deprecated in favour
> of importlib; see the module's documentation for alternative uses
>
> If this message looks confusing for you, we can avoid it if stop
> skipping frames further if frame.f_back is None. This will got rid of
> "sys:1:" in both cases, explicit and implicit stacklevel=2.

The patch is provided in http://bugs.python.org/issue25204.


From storchaka at gmail.com  Mon Sep 21 20:28:51 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Mon, 21 Sep 2015 21:28:51 +0300
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <CAP1=2W7bUnqBzg951-abaH6MLQnnBeAYgrMsDXzoaw2a1MHPJw@mail.gmail.com>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZz394wBMt-8Ge+Nbr22eHsb080uh-Zu2naBaU56DWyag@mail.gmail.com>
 <CAPJVwBnkniG3VAXNDDUGO=0K_VSC7CeQGPd5pdLpxBKysNQqmQ@mail.gmail.com>
 <CADiSq7dSL=N-u+zXXkJpkpeVxG03mrV_DSJvgPL685sHqLsfLA@mail.gmail.com>
 <mtpdu2$576$1@ger.gmane.org>
 <CAP1=2W7bUnqBzg951-abaH6MLQnnBeAYgrMsDXzoaw2a1MHPJw@mail.gmail.com>
Message-ID: <mtpi96$edd$1@ger.gmane.org>

On 21.09.15 20:32, Brett Cannon wrote:
>
>
> On Mon, 21 Sep 2015 at 10:15 Serhiy Storchaka <storchaka at gmail.com
> <mailto:storchaka at gmail.com>> wrote:
>
>     On 21.09.15 12:05, Nick Coghlan wrote:
>      > Passing "stacklevel=2" for API deprecations is by no means obvious
>      > though, so perhaps it makes sense to add a
>      > "warnings.warn_deprecated(message)" function that's implemented as:
>      >
>      >      def warn_deprecated(message, stacklevel=1):
>      >          return warnings.warn(message, DeprecationWarning,
>      > stacklevel=(2+stacklevel)).
>
>     This will not fix tons of modules that are not aware of correct
>     stacklevel.
>
>
> The long-term solution to this is to add a warnings.deprecate_module()
> function which does the right thing and simply not expose the stacklevel
> argument to users. We can then consider warnings.warn() more of a power
> user function and make the stacklevel a keyword-only argument with no
> default value (although I can already hear Raymond saying "but the
> Python 2 users" for that part of the idea =).

warnings.deprecate_module() will do the right thing only for deprecated 
modules, but most deprecations refer to separate functions.



From brett at python.org  Mon Sep 21 20:53:13 2015
From: brett at python.org (Brett Cannon)
Date: Mon, 21 Sep 2015 18:53:13 +0000
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <mtpi96$edd$1@ger.gmane.org>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZz394wBMt-8Ge+Nbr22eHsb080uh-Zu2naBaU56DWyag@mail.gmail.com>
 <CAPJVwBnkniG3VAXNDDUGO=0K_VSC7CeQGPd5pdLpxBKysNQqmQ@mail.gmail.com>
 <CADiSq7dSL=N-u+zXXkJpkpeVxG03mrV_DSJvgPL685sHqLsfLA@mail.gmail.com>
 <mtpdu2$576$1@ger.gmane.org>
 <CAP1=2W7bUnqBzg951-abaH6MLQnnBeAYgrMsDXzoaw2a1MHPJw@mail.gmail.com>
 <mtpi96$edd$1@ger.gmane.org>
Message-ID: <CAP1=2W45RuUrgUGDXa8SS8DKASTmEgXhqOPRCQhpxvXDyo6S-w@mail.gmail.com>

On Mon, 21 Sep 2015 at 11:29 Serhiy Storchaka <storchaka at gmail.com> wrote:

> On 21.09.15 20:32, Brett Cannon wrote:
> >
> >
> > On Mon, 21 Sep 2015 at 10:15 Serhiy Storchaka <storchaka at gmail.com
> > <mailto:storchaka at gmail.com>> wrote:
> >
> >     On 21.09.15 12:05, Nick Coghlan wrote:
> >      > Passing "stacklevel=2" for API deprecations is by no means obvious
> >      > though, so perhaps it makes sense to add a
> >      > "warnings.warn_deprecated(message)" function that's implemented
> as:
> >      >
> >      >      def warn_deprecated(message, stacklevel=1):
> >      >          return warnings.warn(message, DeprecationWarning,
> >      > stacklevel=(2+stacklevel)).
> >
> >     This will not fix tons of modules that are not aware of correct
> >     stacklevel.
> >
> >
> > The long-term solution to this is to add a warnings.deprecate_module()
> > function which does the right thing and simply not expose the stacklevel
> > argument to users. We can then consider warnings.warn() more of a power
> > user function and make the stacklevel a keyword-only argument with no
> > default value (although I can already hear Raymond saying "but the
> > Python 2 users" for that part of the idea =).
>
> warnings.deprecate_module() will do the right thing only for deprecated
> modules, but most deprecations refer to separate functions.
>

And we can add one for functions as well. My point is that people seem to
not fully comprehend how to properly use the stacklevel argument and so I'm
suggesting we have functions for the common cases (modules, functions,
methods, classes).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150921/3fd6f632/attachment.html>

From guido at python.org  Tue Sep 22 00:03:09 2015
From: guido at python.org (Guido van Rossum)
Date: Mon, 21 Sep 2015 15:03:09 -0700
Subject: [Python-Dev] PEP 495 accepted
Message-ID: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>

Just so people know, over at the datetime-sig I've accepted PEP 495, which
adds a fold flag to datetime objects to distinguish ambiguous times. This
enables roundripping of conversions for those times where the local clock
is moved backward (creating ambiguous times that could not be distinguished
before).

I would like to thank Alexander and Tim for their unrelenting work on this.
The idea seems simple, but the details were excruciatingly hard to get
right, given the strict backwards compatibility requirements.

There may well be additional beneficial changes to the datetime module. The
datetime-sig is now open for their discussion. However, proposals that
break backwards compatibility are a waste of everybody's time, so be
prepared to explain how your proposal does not break existing code that
works under Python 3.5.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150921/e0e2d27b/attachment-0001.html>

From njs at pobox.com  Tue Sep 22 00:29:52 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 21 Sep 2015 15:29:52 -0700
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <mtpdu2$576$1@ger.gmane.org>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZz394wBMt-8Ge+Nbr22eHsb080uh-Zu2naBaU56DWyag@mail.gmail.com>
 <CAPJVwBnkniG3VAXNDDUGO=0K_VSC7CeQGPd5pdLpxBKysNQqmQ@mail.gmail.com>
 <CADiSq7dSL=N-u+zXXkJpkpeVxG03mrV_DSJvgPL685sHqLsfLA@mail.gmail.com>
 <mtpdu2$576$1@ger.gmane.org>
Message-ID: <CAPJVwBnTyo67YLKi2oQhzOOap0LiDW-C4J+HukkNoPCufLBzZQ@mail.gmail.com>

On Mon, Sep 21, 2015 at 10:14 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> stacklevel=2 is correct argument for module level warnings, but as Nathaniel
> noted not all packages use it. When your run correctly written module as
> script you get the same "sys:1:". And this issue can be solved in general
> case.

Point of information: for module deprecations, stacklevel=2 is correct
in 2.7 and 3.5, but in 3.4 the correct value is stacklevel=8 (see
https://bugs.python.org/issue24305#msg249981). I'm inclined to think
that this is a bug that should be fixed in 3.4.4, but Larry disagrees
and I don't really care enough to argue about it either way :-).

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

From victor.stinner at gmail.com  Tue Sep 22 01:16:46 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 22 Sep 2015 01:16:46 +0200
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
Message-ID: <CAMpsgwZx6QTHZq2zp-JFKF+hRQwiX-OZ+_LpCAEurvC22Jtozg@mail.gmail.com>

More context ;-)

PEP 0495 -- Local Time Disambiguation

Abstract

This PEP adds a new attribute fold to instances of the datetime.time
and datetime.datetime classes that can be used to differentiate
between two moments in time for which local times are the same. The
allowed values for the fold attribute will be 0 and 1 with 0
corresponding to the earlier and 1 to the later of the two possible
readings of an ambiguous local time.

https://www.python.org/dev/peps/pep-0495/

Victor

2015-09-22 0:03 GMT+02:00 Guido van Rossum <guido at python.org>:
> Just so people know, over at the datetime-sig I've accepted PEP 495, which
> adds a fold flag to datetime objects to distinguish ambiguous times. This
> enables roundripping of conversions for those times where the local clock is
> moved backward (creating ambiguous times that could not be distinguished
> before).
>
> I would like to thank Alexander and Tim for their unrelenting work on this.
> The idea seems simple, but the details were excruciatingly hard to get
> right, given the strict backwards compatibility requirements.
>
> There may well be additional beneficial changes to the datetime module. The
> datetime-sig is now open for their discussion. However, proposals that break
> backwards compatibility are a waste of everybody's time, so be prepared to
> explain how your proposal does not break existing code that works under
> Python 3.5.
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>

From ncoghlan at gmail.com  Tue Sep 22 02:19:05 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Sep 2015 10:19:05 +1000
Subject: [Python-Dev] Make stacklevel=2 by default in warnings.warn()
In-Reply-To: <mtpdu2$576$1@ger.gmane.org>
References: <mtlkl6$ur9$1@ger.gmane.org>
 <CAMpsgwZz394wBMt-8Ge+Nbr22eHsb080uh-Zu2naBaU56DWyag@mail.gmail.com>
 <CAPJVwBnkniG3VAXNDDUGO=0K_VSC7CeQGPd5pdLpxBKysNQqmQ@mail.gmail.com>
 <CADiSq7dSL=N-u+zXXkJpkpeVxG03mrV_DSJvgPL685sHqLsfLA@mail.gmail.com>
 <mtpdu2$576$1@ger.gmane.org>
Message-ID: <CADiSq7dr+1NFWm4YBaghbFhTSx2+OyEzXsCWrrnP5KVJOjvhgw@mail.gmail.com>

On 22 Sep 2015 03:16, "Serhiy Storchaka" <storchaka at gmail.com> wrote:
>
> On 21.09.15 12:05, Nick Coghlan wrote:
>>
>> As Victor notes, though, that's not the right default for *scripts*
>> that are issuing deprecation warnings to end users - there, they
>> really are deprecating themselves. It's also not the right default for
>> pretty much any warning other than DeprecationWarning - for those,
>> you're generally wanting to say "we hit this problematic code path",
>> not report anything about your caller.
>
>
> If a warning is emitted in library function, user can't do anything with
function's code and should change his code that calls the function. In this
case the warning should point to the line where the function is used.
>
> If a warning is emitted in user's code, he is able to add explicit
stacklevel=1 if needed.
>
> stacklevel=2 is correct argument for module level warnings, but as
Nathaniel noted not all packages use it. When your run correctly written
module as script you get the same "sys:1:". And this issue can be solved in
general case.

Aye, combined with your suggestion of not going beyond the top of the stack
when issuing warnings, I've been persuaded that changing the default stack
level to 2 makes sense.

The other relevant thing I recalled is the guidance in
https://docs.python.org/3/howto/logging.html#logging-basic-tutorial, which
suggests using warnings.warn if you want the caller to change their code,
logging.warn otherwise.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/15e39f1a/attachment.html>

From ncoghlan at gmail.com  Tue Sep 22 05:33:37 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Sep 2015 13:33:37 +1000
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
Message-ID: <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>

On 22 September 2015 at 08:03, Guido van Rossum <guido at python.org> wrote:
> Just so people know, over at the datetime-sig I've accepted PEP 495, which
> adds a fold flag to datetime objects to distinguish ambiguous times. This
> enables roundripping of conversions for those times where the local clock is
> moved backward (creating ambiguous times that could not be distinguished
> before).

Hurrah, and congratulations in particular on finding a name for the
flag which is memorable, meaningful and succinct.

> I would like to thank Alexander and Tim for their unrelenting work on this.
> The idea seems simple, but the details were excruciatingly hard to get
> right, given the strict backwards compatibility requirements.

I don't think I've seen a collision between mathematical and language
level invariants that complex since the first time I had to figure out
the conflict between container membership invariants and floating
point NaN values (and this one is even more subtle).

I'm reading through the full PEP now, and really appreciating the
thorough write up. Thanks to Alexander and Tim, and to all the folks
involved in the extensive discussions!

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Tue Sep 22 09:01:32 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Sep 2015 17:01:32 +1000
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
Message-ID: <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>

On 22 September 2015 at 13:33, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 22 September 2015 at 08:03, Guido van Rossum <guido at python.org> wrote:
>> Just so people know, over at the datetime-sig I've accepted PEP 495, which
>> adds a fold flag to datetime objects to distinguish ambiguous times. This
>> enables roundripping of conversions for those times where the local clock is
>> moved backward (creating ambiguous times that could not be distinguished
>> before).
>
> Hurrah, and congratulations in particular on finding a name for the
> flag which is memorable, meaningful and succinct.
>
>> I would like to thank Alexander and Tim for their unrelenting work on this.
>> The idea seems simple, but the details were excruciatingly hard to get
>> right, given the strict backwards compatibility requirements.
>
> I don't think I've seen a collision between mathematical and language
> level invariants that complex since the first time I had to figure out
> the conflict between container membership invariants and floating
> point NaN values (and this one is even more subtle).
>
> I'm reading through the full PEP now, and really appreciating the
> thorough write up. Thanks to Alexander and Tim, and to all the folks
> involved in the extensive discussions!

It turns out there's one aspect of the accepted proposal that I
*think* I understand, but want to confirm: the datetime -> POSIX
timestamp -> datetime roundtrip for missing times.

If I'm reading the PEP correctly, the defined invariant for local
times that actually exist is:

    dt == datetime.fromtimestamp(dt.timestamp())

No confusion there for the unambiguous times, or for times in a fold.
In the latter case, the timestamps produced match the points where the
UTC times match the local times in the "In the Fold" UTC/local
diagram.

The subtle part is the handling of the "timestamp()" method for the
"missing" times where the given time doesn't actually correspond to a
valid time in the applicable timezone (local time for a naive datetime
object).

Based on the UTC/local diagram from the "Mind the Gap" section, am I
correct in thinking that the modified invariant that also covers times
in a gap is:

    dt == datetime.fromtimestamp(dt.astimezone(utc).astimezone(dt.tzinfo).timestamp())

That is, for local times that exist, the invariant "dt ==
dt.astimezone(utc).astimezone(dt.tzinfo)" holds, but for times that
don't exist, "dt.astimezone(utc).astimezone(dt.tzinfo)" will normalise
them to be a time that actually exists in the original time zone, and
that normalisation also effectively happens when calling
"dt.timestamp()".

Regards,
Nick.

P.S. Thanks to whoever drew the diagrams for the In the Fold/Mind the
Gap sections - I found them incredibly helpful in understanding the
change!

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From guido at python.org  Tue Sep 22 16:43:23 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Sep 2015 07:43:23 -0700
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
Message-ID: <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>

On Tue, Sep 22, 2015 at 12:01 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> It turns out there's one aspect of the accepted proposal that I
> *think* I understand, but want to confirm: the datetime -> POSIX
> timestamp -> datetime roundtrip for missing times.
>
> If I'm reading the PEP correctly, the defined invariant for local
> times that actually exist is:
>
>     dt == datetime.fromtimestamp(dt.timestamp())
>

Yup, except for floating point errors! Those have been fixed, finally:
http://bugs.python.org/issue23517 is now closed (the fix didn't make 3.5.0;
it will be in 3.5.1 though).


> No confusion there for the unambiguous times, or for times in a fold.
> In the latter case, the timestamps produced match the points where the
> UTC times match the local times in the "In the Fold" UTC/local
> diagram.
>

And this is where the fold flag is essential for the roundtripping.


> The subtle part is the handling of the "timestamp()" method for the
> "missing" times where the given time doesn't actually correspond to a
> valid time in the applicable timezone (local time for a naive datetime
> object).
>
> Based on the UTC/local diagram from the "Mind the Gap" section, am I
> correct in thinking that the modified invariant that also covers times
> in a gap is:
>
>     dt ==
> datetime.fromtimestamp(dt.astimezone(utc).astimezone(dt.tzinfo).timestamp())
>
> That is, for local times that exist, the invariant "dt ==
> dt.astimezone(utc).astimezone(dt.tzinfo)" holds, but for times that
> don't exist, "dt.astimezone(utc).astimezone(dt.tzinfo)" will normalise
> them to be a time that actually exists in the original time zone, and
> that normalisation also effectively happens when calling
> "dt.timestamp()".
>

That can't be right -- There is no way any fromtimestamp() call can return
a time in the gap. I think about the only useful invariant here is

  dt.timestamp() == dt.astimezone(utc).timestamp() == dt.astimezone(<any
other tz>).timestamp()


> Regards,
> Nick.
>
> P.S. Thanks to whoever drew the diagrams for the In the Fold/Mind the
> Gap sections - I found them incredibly helpful in understanding the
> change!
>

You're welcome. It was a collaboration by myself and Alexander. I drew the
first version by hand because I couldn't follow the math without a visual
aid. :-)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/e82d7a82/attachment.html>

From alexander.belopolsky at gmail.com  Tue Sep 22 16:45:55 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Sep 2015 10:45:55 -0400
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
Message-ID: <CAP7h-xaicbENCULebqYaWrLsQ04giTRYJF+B+8OCndfW7=5ytQ@mail.gmail.com>

On Tue, Sep 22, 2015 at 3:01 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> ... for times that
> don't exist, "dt.astimezone(utc).astimezone(dt.tzinfo)" will normalise
> them to be a time that actually exists in the original time zone, and
> that normalisation also effectively happens when calling
> "dt.timestamp()".
>

Yes.  In fact, if you consider the canonical bijection between timestamps
and datetimes (t = EPOCH + s * timedelta(0, 1); s = (t - EPOCH) /
timedelta(0, 1)), t.astimezone(utc) and t.timestamp() become the same up to
some annoying numerical details.  The same logic applies to
u.astimezone(tzinfo) and datetime.fromtimestamp(s).  Note that I
deliberately did not mark the units on the sketches: you can think of the
UTC axis to be labeled by datetimes or by numeric timestamps.

Note that dt != dt.astimezone(utc).astimezone(dt.tzinfo) is one way to
detect that dt is in a gap, but I recommend
(dt.replace(fold=0).utcoffset() > dt.replace(fold=1).utcoffset().)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/d28e4e3d/attachment.html>

From alexander.belopolsky at gmail.com  Tue Sep 22 16:55:50 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Sep 2015 10:55:50 -0400
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
Message-ID: <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>

On Tue, Sep 22, 2015 at 10:43 AM, Guido van Rossum <guido at python.org> wrote:

> Based on the UTC/local diagram from the "Mind the Gap" section, am I
>> correct in thinking that the modified invariant that also covers times
>> in a gap is:
>>
>>     dt ==
>> datetime.fromtimestamp(dt.astimezone(utc).astimezone(dt.tzinfo).timestamp())
>>
>> That is, for local times that exist, the invariant "dt ==
>> dt.astimezone(utc).astimezone(dt.tzinfo)" holds, but for times that
>> don't exist, "dt.astimezone(utc).astimezone(dt.tzinfo)" will normalise
>> them to be a time that actually exists in the original time zone, and
>> that normalisation also effectively happens when calling
>> "dt.timestamp()".
>>
>
> That can't be right -- There is no way any fromtimestamp() call can return
> a time in the gap.
>

I don't think Nick said that.


> I think about the only useful invariant here is
>
>   dt.timestamp() == dt.astimezone(utc).timestamp() == dt.astimezone(<any
> other tz>).timestamp()
>

Yes, this is just another way to say that  .astimezone() conversions are
now "lossless."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/238793e0/attachment.html>

From alexander.belopolsky at gmail.com  Tue Sep 22 17:09:00 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Sep 2015 11:09:00 -0400
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
Message-ID: <CAP7h-xbnhoOgu48jCrFev3OV6z+EqpDq3ds1K9LrPkZzy8Vd+A@mail.gmail.com>

On Tue, Sep 22, 2015 at 10:55 AM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

> On Tue, Sep 22, 2015 at 10:43 AM, Guido van Rossum <guido at python.org>
> wrote:
>
>> Based on the UTC/local diagram from the "Mind the Gap" section, am I
>>> correct in thinking that the modified invariant that also covers times
>>> in a gap is:
>>>
>>>     dt ==
>>> datetime.fromtimestamp(dt.astimezone(utc).astimezone(dt.tzinfo).timestamp())
>>>
>>> That is, for local times that exist, the invariant "dt ==
>>> dt.astimezone(utc).astimezone(dt.tzinfo)" holds, but for times that
>>> don't exist, "dt.astimezone(utc).astimezone(dt.tzinfo)" will normalise
>>> them to be a time that actually exists in the original time zone, and
>>> that normalisation also effectively happens when calling
>>> "dt.timestamp()".
>>>
>>
>> That can't be right -- There is no way any fromtimestamp() call can
>> return a time in the gap.
>>
>
> I don't think Nick said that.
>

On the second reading, it looks like Nick's second sentence contradicts his
first.  Guido is right.  Moreover, there is no way to get a time in the gap
as a result of any conversion including astimezone() and fromutc() in
addition to fromtimestamp().   Such datetimes may appear if you construct
them explicitly, use .replace() to transplant a datetime to another
timezone (or modify other components) and in the result of datetime +
timedelta operation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/f0e2334f/attachment.html>

From tim.peters at gmail.com  Tue Sep 22 17:11:03 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 22 Sep 2015 10:11:03 -0500
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
Message-ID: <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>

[Nick Coghlan]
>>> Based on the UTC/local diagram from the "Mind the Gap" section, am I
>>> correct in thinking that the modified invariant that also covers times
>>> in a gap is:
>>>
>>>     dt ==
>>> datetime.fromtimestamp(dt.astimezone(utc).astimezone(dt.tzinfo).timestamp())
>>>
>>> That is, for local times that exist, the invariant "dt ==
>>> dt.astimezone(utc).astimezone(dt.tzinfo)" holds, but for times that
>>> don't exist, "dt.astimezone(utc).astimezone(dt.tzinfo)" will normalise
>>> them to be a time that actually exists in the original time zone, and
>>> that normalisation also effectively happens when calling
>>> "dt.timestamp()".

[Guido]
>> That can't be right -- There is no way any fromtimestamp() call can return
>> a time in the gap.

[Alexander Belopolsky]
> I don't think Nick said that.

I do, except that he didn't ;-)  Count the parens carefully.  The
top-level operation on the RHS is datetime.fromtimestamp().  However,
it didn't pass a tzinfo, so it creates a naive datetime.  Assuming dt
was aware to begin with, the attempt to compare will always (gap or
not) raise an exception.  If it had passed dt.tzinfo, then Guido is
right.


>> I think about the only useful invariant here is
>>
>>   dt.timestamp() == dt.astimezone(utc).timestamp() ==
>>      dt.astimezone(<any other tz>).timestamp()

> Yes, this is just another way to say that  .astimezone() conversions are now

Nick, to be very clear, there are two scenarios here after PEP 495 is
implemented in Python:

1. You're using a pre-495 tzinfo.  Then nothing changes from what happens today.

2. You're using a new 495-conforming tzinfo.  Then the discussion
starts to apply.

From tim.peters at gmail.com  Tue Sep 22 17:16:11 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 22 Sep 2015 10:16:11 -0500
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
Message-ID: <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>

[Tim]
> ...
> The
> top-level operation on the RHS is datetime.fromtimestamp().  However,
> it didn't pass a tzinfo, so it creates a naive datetime.  Assuming dt
> was aware to begin with, the attempt to compare will always (gap or
> not) raise an exception.

Oops!  In current Python, comparing naive and aware via `==` just
returns False.  That's even more confusing ;-)

From alexander.belopolsky at gmail.com  Tue Sep 22 18:25:27 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Sep 2015 12:25:27 -0400
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
Message-ID: <CAP7h-xae-8qo16+15rQajONwbkJ5A2ciK3KnGJH27o6OXydUvg@mail.gmail.com>

On Tue, Sep 22, 2015 at 11:11 AM, Tim Peters <tim.peters at gmail.com> wrote:

> [Nick Coghlan]
> ...
> >>>     dt ==
> >>>
> datetime.fromtimestamp(dt.astimezone(utc).astimezone(dt.tzinfo).timestamp())
> ...
> [Guido]
> >> That can't be right -- There is no way any fromtimestamp() call can
> return
> >> a time in the gap.
>
> [Alexander Belopolsky]
> > I don't think Nick said that.
>
> [Tim Peters]

> I do, except that he didn't ;-)  Count the parens carefully.
>

OK, it looks like Nick has managed to confuse both authors of the PEP, but
not Guido. :-)

The .astimezone() conversions in Nick's expression are a red herring.  They
don't change the value of the timestamp.  That's the invariant Guido
mentioned:

dt.timestamp() == dt.astimezone(utc).timestamp()
== dt.astimezone(utc).astimezone(dt.tzinfo).timestamp()


Now, if dt is in its tzinfo gap, then

 dt != datetime.fromtimestamp(dt.timestamp(), dt.tzinfo)

Instead, you get something like this:

 datetime.fromtimestamp(dt.timestamp(), dt.tzinfo) == dt + (1 - 2*dt.fold)
* gap

where gap is the size of the gap expressed as a timedelta (typically gap =
timedelta(hours=1)).   In words, when you ask for 2:40 AM, but the clock
jumps from 01:59 AM to 03:00 AM, the round trip through timestamp gives you
03:40 AM if fold=0 and 01:40 AM if fold=1.  This rule is somewhat
arbitrary, but it has many nice mathematical and "human" properties.

(There is an (imperfect) analogy with the roots of a quadratic equation
here: when no real solutions exist, the two complex solutions are a ? i*b
and "nice to have" real values are a ? b.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/4d38adbe/attachment.html>

From guido at python.org  Tue Sep 22 18:38:22 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Sep 2015 09:38:22 -0700
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
Message-ID: <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>

On Tue, Sep 22, 2015 at 8:16 AM, Tim Peters <tim.peters at gmail.com> wrote:

> [Tim]
> > ...
> > The
> > top-level operation on the RHS is datetime.fromtimestamp().  However,
> > it didn't pass a tzinfo, so it creates a naive datetime.  Assuming dt
> > was aware to begin with, the attempt to compare will always (gap or
> > not) raise an exception.
>
> Oops!  In current Python, comparing naive and aware via `==` just
> returns False.  That's even more confusing ;-)
>

Hm, but that's in general how == is *supposed* to work between objects of
incompatible types. < and > are supposed to fail but == is supposed to
return False (the __eq__ should return NotImplemented). If == ever raises
an exception, having two different objects as dict keys can cause random,
hard-to-debug failures.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/f2f16933/attachment-0001.html>

From tim.peters at gmail.com  Tue Sep 22 18:47:02 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 22 Sep 2015 11:47:02 -0500
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
Message-ID: <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>

[Tim]
>>> ...
>>> The
>>> top-level operation on the RHS is datetime.fromtimestamp().  However,
>>> it didn't pass a tzinfo, so it creates a naive datetime.  Assuming dt
>>> was aware to begin with, the attempt to compare will always (gap or
>>> not) raise an exception.

[Tim]
>> Oops!  In current Python, comparing naive and aware via `==` just
>> returns False.  That's even more confusing ;-)

[Guido]
> Hm, but that's in general how == is *supposed* to work between objects of
> incompatible types. < and > are supposed to fail but == is supposed to
> return False (the __eq__ should return NotImplemented). If == ever raises an
> exception, having two different objects as dict keys can cause random,
> hard-to-debug failures.

Sure - no complaint.  I was just saying that in the specific,
complicated, contrived expression Nick presented, that it always
returns False (no matter which aware datetime he starts with) would be
more of a head-scratcher than if it raised a "can't compare naive and
aware datetimes" exception instead.

That's why, whenever anyone is confused by anything they see in a
Python program, they should post all their code verbatim to
Python-Dev, prefaced with a "Doesn't work!  Fix it." comment ;-)

From guido at python.org  Tue Sep 22 18:55:35 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Sep 2015 09:55:35 -0700
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
Message-ID: <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>

On Tue, Sep 22, 2015 at 9:47 AM, Tim Peters <tim.peters at gmail.com> wrote:

> [Tim]
> >>> ...
> >>> The
> >>> top-level operation on the RHS is datetime.fromtimestamp().  However,
> >>> it didn't pass a tzinfo, so it creates a naive datetime.  Assuming dt
> >>> was aware to begin with, the attempt to compare will always (gap or
> >>> not) raise an exception.
>
> [Tim]
> >> Oops!  In current Python, comparing naive and aware via `==` just
> >> returns False.  That's even more confusing ;-)
>
> [Guido]
> > Hm, but that's in general how == is *supposed* to work between objects of
> > incompatible types. < and > are supposed to fail but == is supposed to
> > return False (the __eq__ should return NotImplemented). If == ever
> raises an
> > exception, having two different objects as dict keys can cause random,
> > hard-to-debug failures.
>
> Sure - no complaint.  I was just saying that in the specific,
> complicated, contrived expression Nick presented, that it always
> returns False (no matter which aware datetime he starts with) would be
> more of a head-scratcher than if it raised a "can't compare naive and
> aware datetimes" exception instead.
>

And yet I think the desired behavior of == requires us to return False. I
think we should change this in the PEP, except I can't find where the PEP
says == should raise an exception in this case.


> That's why, whenever anyone is confused by anything they see in a
> Python program, they should post all their code verbatim to
> Python-Dev, prefaced with a "Doesn't work!  Fix it." comment ;-)
>

Oh, it would be so much better if they posted their code!

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/254f5801/attachment.html>

From alexander.belopolsky at gmail.com  Tue Sep 22 19:31:03 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Sep 2015 13:31:03 -0400
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
Message-ID: <CAP7h-xZHnSzEzV343zMiZJzK-ot_Evdn0QanaxY_-S9_KnWghg@mail.gmail.com>

On Tue, Sep 22, 2015 at 12:47 PM, Tim Peters <tim.peters at gmail.com> wrote:
>
> I was just saying that in the specific,
> complicated, contrived expression Nick presented, that it always
> returns False (no matter which aware datetime he starts with) would be
> more of a head-scratcher than if it raised a "can't compare naive and
> aware datetimes" exception instead.

The current behavior is no fault of yours.  Guido, Antoine and I share all
the blame and credit for it. [1,2]

[1]: http://bugs.python.org/issue15006
[2]: https://mail.python.org/pipermail/python-dev/2012-June/119933.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/99a9fc39/attachment.html>

From tim.peters at gmail.com  Tue Sep 22 19:34:19 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 22 Sep 2015 12:34:19 -0500
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
 <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>
Message-ID: <CAExdVNnbRfWTxiZCkM7Y7FVct-zoBMgdzg5OAs=_wANujzdxXA@mail.gmail.com>

[Tim]
>> Sure - no complaint.  I was just saying that in the specific,
>> complicated, contrived expression Nick presented, that it always
>> returns False (no matter which aware datetime he starts with) would be
>> more of a head-scratcher than if it raised a "can't compare naive and
>> aware datetimes" exception instead.

[Guido]
> And yet I think the desired behavior of == requires us to return False.

Yes - we remain in violent agreement on all points here.


> I think we should change this in the PEP, except I can't find where
> the PEP says == should raise an exception in this case.

It doesn't - the only comparison behavior changed by the PEP is in
case of interzone comparison when at least one comparand is a "problem
time" (which can only happen with a post-495 tzinfo).  Then "==" is
always False.  That hack is the ugliest part of the PEP, but was
needed to preserve the hash invariant (d1 == d2 implies hash(d1) ==
hash(d2)).

BTW, while the PEP doesn't spell this out, trichotomy can fail in some
such cases (those where "==" would have returned True had it not been
forced to return False - then "<" and ">" will also be False).

In any case, nothing changes for any case of aware-vs-naive comparison.

From guido at python.org  Tue Sep 22 19:57:37 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Sep 2015 10:57:37 -0700
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAExdVNnbRfWTxiZCkM7Y7FVct-zoBMgdzg5OAs=_wANujzdxXA@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
 <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>
 <CAExdVNnbRfWTxiZCkM7Y7FVct-zoBMgdzg5OAs=_wANujzdxXA@mail.gmail.com>
Message-ID: <CAP7+vJLhAB9LNHVUj1y1WpXydS5y0_P1n-hrN_6RzUtoKbGD1g@mail.gmail.com>

On Tue, Sep 22, 2015 at 10:34 AM, Tim Peters <tim.peters at gmail.com> wrote:

> [Tim]
> >> Sure - no complaint.  I was just saying that in the specific,
> >> complicated, contrived expression Nick presented, that it always
> >> returns False (no matter which aware datetime he starts with) would be
> >> more of a head-scratcher than if it raised a "can't compare naive and
> >> aware datetimes" exception instead.
>
> [Guido]
> > And yet I think the desired behavior of == requires us to return False.
>
> Yes - we remain in violent agreement on all points here.
>
>
> > I think we should change this in the PEP, except I can't find where
> > the PEP says == should raise an exception in this case.
>
> It doesn't - the only comparison behavior changed by the PEP is in
> case of interzone comparison when at least one comparand is a "problem
> time" (which can only happen with a post-495 tzinfo).  Then "==" is
> always False.  That hack is the ugliest part of the PEP, but was
> needed to preserve the hash invariant (d1 == d2 implies hash(d1) ==
> hash(d2)).
>
> BTW, while the PEP doesn't spell this out, trichotomy can fail in some
> such cases (those where "==" would have returned True had it not been
> forced to return False - then "<" and ">" will also be False).
>
> In any case, nothing changes for any case of aware-vs-naive comparison.
>

And I guess we can't make < and > raise an exception for backward
compatibility reasons. :-(

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/513ad16e/attachment.html>

From alexander.belopolsky at gmail.com  Tue Sep 22 20:26:16 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Sep 2015 14:26:16 -0400
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7+vJLhAB9LNHVUj1y1WpXydS5y0_P1n-hrN_6RzUtoKbGD1g@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
 <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>
 <CAExdVNnbRfWTxiZCkM7Y7FVct-zoBMgdzg5OAs=_wANujzdxXA@mail.gmail.com>
 <CAP7+vJLhAB9LNHVUj1y1WpXydS5y0_P1n-hrN_6RzUtoKbGD1g@mail.gmail.com>
Message-ID: <CAP7h-xYhWgWmXpX7avqwgUz3_+G=oiTfBbj-U0YSqrS3Y4WuBg@mail.gmail.com>

On Tue, Sep 22, 2015 at 1:57 PM, Guido van Rossum <guido at python.org> wrote:

> BTW, while the PEP doesn't spell this out, trichotomy can fail in some
>> such cases (those where "==" would have returned True had it not been
>> forced to return False - then "<" and ">" will also be False).
>>
>> In any case, nothing changes for any case of aware-vs-naive comparison.
>>
>
> And I guess we can't make < and > raise an exception for backward
> compatibility reasons. :-(
>

Just to make it clear, naive to aware comparison is an error now and will
still be an error:

>>> from datetime import *
>>> datetime.now() > datetime.now(timezone.utc)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare offset-naive and offset-aware datetimes

What would be nice, was if  datetime.now(tz1) > datetime.now(tz2) was an
error whenever tz1 is not tz2, but this is not possible for backward
compatibility reasons.

I was toying with an idea to make t > s an error whenever the result
depends on the value of t.fold or s.fold, but the resulting rules were even
uglier than the hash invariant compromise.

At the end of the day, this is the case of practicality beating purity.  We
overload > and - in datetime for convenience of interzone operations.
 (Want to know number of microseconds since epoch?  Easy: (t -
datetime(1970, 1, 1, tzinfo=timezone.utc))//timedelta.resolution).  We pay
for this convenience  by a loss of some properties that we expect from
mathematical operations (e.g. s - t != (s - u) - (t - u) is possible.)  I
think this is a fair price to pay for convenience of s > t and s - t over
s.is_later(t) and s.timediff(t).  Arguably, requiring s.timezone(utc) >
t.astimezone(utc) would be "explicit is better than implicit," but you
cannot deny the convenience of plain s > t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/fce117ce/attachment.html>

From tim.peters at gmail.com  Tue Sep 22 20:48:54 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 22 Sep 2015 13:48:54 -0500
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7+vJLhAB9LNHVUj1y1WpXydS5y0_P1n-hrN_6RzUtoKbGD1g@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
 <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>
 <CAExdVNnbRfWTxiZCkM7Y7FVct-zoBMgdzg5OAs=_wANujzdxXA@mail.gmail.com>
 <CAP7+vJLhAB9LNHVUj1y1WpXydS5y0_P1n-hrN_6RzUtoKbGD1g@mail.gmail.com>
Message-ID: <CAExdVNnLNXDyZq+558XjvKt6FZuKw=TV4PPEk9Zd4T2e0hnaPA@mail.gmail.com>

[Guido]
>>> I think we should change this in the PEP, except I can't find where
>>> the PEP says == should raise an exception in this case.

[Tim]
>> It doesn't - the only comparison behavior changed by the PEP is in
>> case of interzone comparison when at least one comparand is a "problem
>> time" (which can only happen with a post-495 tzinfo).  Then "==" is
>> always False.  That hack is the ugliest part of the PEP,

Correction:  that's _only_ "ugly part" of the PEP.  Except for that,
it's quite elegant :-)


>> but was needed to preserve the hash invariant (d1 == d2 implies
>> hash(d1) == hash(d2)).
>>
>> BTW, while the PEP doesn't spell this out, trichotomy can fail in some
>> such cases (those where "==" would have returned True had it not been
>> forced to return False - then "<" and ">" will also be False).

[Guido]
> And I guess we can't make < and > raise an exception for backward
> compatibility reasons. :-(

Bingo.  But, in its favor, that would be less incompatible than
removing hash() and dicts from the language ;-)

Another oddity is that interzone subtraction always gets "the right"
result, even in interzone cases where "x == y" is forced to return
False despite that "x - y == timedelta(0)".  cmp-like comparison still
enjoys trichotomy in all cases.

Note that, for a week or two, we _tried_ to get around all that by
making x != y for intrazone x and y differing only in `fold`.  But
that was so at odds with the naive time model that worse kinds of
incompatibility snuck in.

So we can make intrazone "naive time" work as expected in all cases,
or we can make by-magic interzone subtraction and comparison work as
expected in all cases.  We started and ended with the former, with a
painful abandoned attempt at the latter in between.  If there's a
sane(*) way to do both simultaneously, in a backward-compatible way,
it eluded everyone.


(*) An "insane" way would be to partition all aware datetimes into
equivalence classes based on lumping together all possible spellings
of a "problem time" in all zones, so that hash() could treat them all
the same.  But that requires knowing all possible tzinfos that can
ever be used before the first time hash() is called.  Even then it
would be messy to do.

From guido at python.org  Tue Sep 22 21:32:27 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Sep 2015 12:32:27 -0700
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7h-xYhWgWmXpX7avqwgUz3_+G=oiTfBbj-U0YSqrS3Y4WuBg@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
 <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>
 <CAExdVNnbRfWTxiZCkM7Y7FVct-zoBMgdzg5OAs=_wANujzdxXA@mail.gmail.com>
 <CAP7+vJLhAB9LNHVUj1y1WpXydS5y0_P1n-hrN_6RzUtoKbGD1g@mail.gmail.com>
 <CAP7h-xYhWgWmXpX7avqwgUz3_+G=oiTfBbj-U0YSqrS3Y4WuBg@mail.gmail.com>
Message-ID: <CAP7+vJKWW=we0HQFpXZakoC0Pquj-KX-yZf-rW7oLkyRs0+P7Q@mail.gmail.com>

On Tue, Sep 22, 2015 at 11:26 AM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

>
> On Tue, Sep 22, 2015 at 1:57 PM, Guido van Rossum <guido at python.org>
> wrote:
>
>> BTW, while the PEP doesn't spell this out, trichotomy can fail in some
>>> such cases (those where "==" would have returned True had it not been
>>> forced to return False - then "<" and ">" will also be False).
>>>
>>> In any case, nothing changes for any case of aware-vs-naive comparison.
>>>
>>
>> And I guess we can't make < and > raise an exception for backward
>> compatibility reasons. :-(
>>
>
> Just to make it clear, naive to aware comparison is an error now and will
> still be an error:
>

Ah, I just realized one of the confusions here is the use of the word
"comparison", since it could refer to == or to < and >.


> >>> from datetime import *
> >>> datetime.now() > datetime.now(timezone.utc)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: can't compare offset-naive and offset-aware datetimes
>

IIUC the < and > operators raise here, and == returns False -- which is
exactly as it should be.


> What would be nice, was if  datetime.now(tz1) > datetime.now(tz2) was an
> error whenever tz1 is not tz2, but this is not possible for backward
> compatibility reasons.
>
> I was toying with an idea to make t > s an error whenever the result
> depends on the value of t.fold or s.fold, but the resulting rules were even
> uglier than the hash invariant compromise.
>
> At the end of the day, this is the case of practicality beating purity.
> We overload > and - in datetime for convenience of interzone operations.
>  (Want to know number of microseconds since epoch?  Easy: (t -
> datetime(1970, 1, 1, tzinfo=timezone.utc))//timedelta.resolution).  We pay
> for this convenience  by a loss of some properties that we expect from
> mathematical operations (e.g. s - t != (s - u) - (t - u) is possible.)  I
> think this is a fair price to pay for convenience of s > t and s - t over
> s.is_later(t) and s.timediff(t).  Arguably, requiring s.timezone(utc) >
> t.astimezone(utc) would be "explicit is better than implicit," but you
> cannot deny the convenience of plain s > t.
>

But the convenience is false -- it papers over important details. And it is
broken, due to the confusion about classic vs. timeline arithmetic -- these
have different needs but there's only one > operator.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/532c9067/attachment-0001.html>

From alexander.belopolsky at gmail.com  Tue Sep 22 22:08:29 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Sep 2015 16:08:29 -0400
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7+vJKWW=we0HQFpXZakoC0Pquj-KX-yZf-rW7oLkyRs0+P7Q@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
 <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>
 <CAExdVNnbRfWTxiZCkM7Y7FVct-zoBMgdzg5OAs=_wANujzdxXA@mail.gmail.com>
 <CAP7+vJLhAB9LNHVUj1y1WpXydS5y0_P1n-hrN_6RzUtoKbGD1g@mail.gmail.com>
 <CAP7h-xYhWgWmXpX7avqwgUz3_+G=oiTfBbj-U0YSqrS3Y4WuBg@mail.gmail.com>
 <CAP7+vJKWW=we0HQFpXZakoC0Pquj-KX-yZf-rW7oLkyRs0+P7Q@mail.gmail.com>
Message-ID: <CAP7h-xbj47qPCYLncqWS7SLOTS=3HtEzJzy=eA8Y-QfbN95tcA@mail.gmail.com>

On Tue, Sep 22, 2015 at 3:32 PM, Guido van Rossum <guido at python.org> wrote:

> it is broken, due to the confusion about classic vs. timeline arithmetic
> -- these have different needs but there's only one > operator.


I feel silly trying to defend a design against its author. :-)  Yes, a
language with more than one > symbol would not have some of these
problems.  Similarly a language with a special symbol for string catenation
would not have a non-commutative + and non-distributive *.  All I am saying
is that I can live with the choices made in datetime.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/d18730e5/attachment.html>

From njs at pobox.com  Tue Sep 22 22:14:58 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Tue, 22 Sep 2015 13:14:58 -0700
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7h-xbj47qPCYLncqWS7SLOTS=3HtEzJzy=eA8Y-QfbN95tcA@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
 <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>
 <CAExdVNnbRfWTxiZCkM7Y7FVct-zoBMgdzg5OAs=_wANujzdxXA@mail.gmail.com>
 <CAP7+vJLhAB9LNHVUj1y1WpXydS5y0_P1n-hrN_6RzUtoKbGD1g@mail.gmail.com>
 <CAP7h-xYhWgWmXpX7avqwgUz3_+G=oiTfBbj-U0YSqrS3Y4WuBg@mail.gmail.com>
 <CAP7+vJKWW=we0HQFpXZakoC0Pquj-KX-yZf-rW7oLkyRs0+P7Q@mail.gmail.com>
 <CAP7h-xbj47qPCYLncqWS7SLOTS=3HtEzJzy=eA8Y-QfbN95tcA@mail.gmail.com>
Message-ID: <CAPJVwBnC7mmfFBy9b4cF6+Pn9Nm0tRX+O1pA-ikbMWfKcepG8w@mail.gmail.com>

On Sep 22, 2015 1:09 PM, "Alexander Belopolsky" <
alexander.belopolsky at gmail.com> wrote:
>
>
> On Tue, Sep 22, 2015 at 3:32 PM, Guido van Rossum <guido at python.org>
wrote:
>>
>> it is broken, due to the confusion about classic vs. timeline arithmetic
-- these have different needs but there's only one > operator.
>
>
> I feel silly trying to defend a design against its author. :-)  Yes, a
language with more than one > symbol would not have some of these
problems.  Similarly a language with a special symbol for string catenation
would not have a non-commutative + and non-distributive *.  All I am saying
is that I can live with the choices made in datetime.

Is there a good argument against at least deprecating inequality
comparisons and subtraction between mixed timezone datetimes? It seems like
a warning that would be likely to catch real bugs.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/7d1acd24/attachment.html>

From alexander.belopolsky at gmail.com  Tue Sep 22 22:24:03 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Sep 2015 16:24:03 -0400
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAPJVwBnC7mmfFBy9b4cF6+Pn9Nm0tRX+O1pA-ikbMWfKcepG8w@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
 <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>
 <CAExdVNnbRfWTxiZCkM7Y7FVct-zoBMgdzg5OAs=_wANujzdxXA@mail.gmail.com>
 <CAP7+vJLhAB9LNHVUj1y1WpXydS5y0_P1n-hrN_6RzUtoKbGD1g@mail.gmail.com>
 <CAP7h-xYhWgWmXpX7avqwgUz3_+G=oiTfBbj-U0YSqrS3Y4WuBg@mail.gmail.com>
 <CAP7+vJKWW=we0HQFpXZakoC0Pquj-KX-yZf-rW7oLkyRs0+P7Q@mail.gmail.com>
 <CAP7h-xbj47qPCYLncqWS7SLOTS=3HtEzJzy=eA8Y-QfbN95tcA@mail.gmail.com>
 <CAPJVwBnC7mmfFBy9b4cF6+Pn9Nm0tRX+O1pA-ikbMWfKcepG8w@mail.gmail.com>
Message-ID: <CAP7h-xZkpt7AtVOCJ7A1WfM7tca54vH6MjY9zQZSXR4vyb7jyQ@mail.gmail.com>

On Tue, Sep 22, 2015 at 4:14 PM, Nathaniel Smith <njs at pobox.com> wrote:

> Is there a good argument against at least deprecating inequality
> comparisons and subtraction between mixed timezone datetimes?


That's a wrong question.  The right question is: "Is current behavior
sufficiently broken to justify a backward incompatible change?"

We've historically been very conservative with datetime.  I would say a
proposal to change the way binary operators work with datetimes should face
a similar scrutiny as a proposal to change that for a bultin type.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/2b31beb5/attachment.html>

From tim.peters at gmail.com  Tue Sep 22 22:25:31 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 22 Sep 2015 15:25:31 -0500
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7h-xbj47qPCYLncqWS7SLOTS=3HtEzJzy=eA8Y-QfbN95tcA@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
 <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>
 <CAExdVNnbRfWTxiZCkM7Y7FVct-zoBMgdzg5OAs=_wANujzdxXA@mail.gmail.com>
 <CAP7+vJLhAB9LNHVUj1y1WpXydS5y0_P1n-hrN_6RzUtoKbGD1g@mail.gmail.com>
 <CAP7h-xYhWgWmXpX7avqwgUz3_+G=oiTfBbj-U0YSqrS3Y4WuBg@mail.gmail.com>
 <CAP7+vJKWW=we0HQFpXZakoC0Pquj-KX-yZf-rW7oLkyRs0+P7Q@mail.gmail.com>
 <CAP7h-xbj47qPCYLncqWS7SLOTS=3HtEzJzy=eA8Y-QfbN95tcA@mail.gmail.com>
Message-ID: <CAExdVNkFheQUzv4tfE8sbXxnEHOmVB1iqt8Nfr8vct9WKQZjMw@mail.gmail.com>

[Guido]
>> it is broken, due to the confusion about classic vs. timeline arithmetic
>> -- these have different needs but there's only one > operator.

[Alex]
> I feel silly trying to defend a design against its author. :-)

"Design" may be an overstatement in this specific case ;-)

I remember implementing this stuff, getting to the comparison
operators, and noting that the spec was silent about what to do in
case the tzinfos differed.  I looked at Guido and explained that, and
asked "so whaddya wanna do?".

One of us (I don't recall which) said "well, we could convert to UTC
first - that would make sense".  "Ya, sure," said the other.  And I
said "and then, of course, interzone subtraction should do the same."
"Of course," said Guido, now annoyed that I was bothering him with the
obvious ;-)

Note that, near that time, Python blithely compared _any_ two objects,
even if of wildly different types.  Compared to that, doing _anything_
arguably sane with datetime objects seemed wildly desirable.
Ironically, the datetime implementation was Python's first library
type to _refuse_ to compare its objects to others of wildly different
types.

So, in all, I'd say well under a minute's thought - between us - went
into this decision.  And we've been living in Paradise ever since :-)


> Yes, a language with more than one > symbol would not have some
> of these problems. Similarly a language with a special symbol for
> string catenation would not have a non-commutative + and non-
> distributive *.  All I am saying is that I can live with the choices made
> in datetime.

Given that the alternative is suicide, I approve of that life decision.

From guido at python.org  Tue Sep 22 22:29:37 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Sep 2015 13:29:37 -0700
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAExdVNkFheQUzv4tfE8sbXxnEHOmVB1iqt8Nfr8vct9WKQZjMw@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAExdVNnT2gWNW1DnwqwMQUzS3fQyhEQVfTijjEG3eOubpqm6_w@mail.gmail.com>
 <CAExdVNkThspQ6aPO09D2B2OkmvhTAPdzZ9+=JRTUg9-sEK-2KQ@mail.gmail.com>
 <CAP7+vJKhMi6DXYp1XG6JXiCyN2=sK3Kn31jPw-nTpzLn0QuHNw@mail.gmail.com>
 <CAExdVNkWhNiNEmNEeyn4Z+HQQa=TUKEkX=5JprPVam0=dnF=QA@mail.gmail.com>
 <CAP7+vJL1eUTDc2y4j0XQjK5M=T8Rb2bFHTHoAETk0gA0FCnjTw@mail.gmail.com>
 <CAExdVNnbRfWTxiZCkM7Y7FVct-zoBMgdzg5OAs=_wANujzdxXA@mail.gmail.com>
 <CAP7+vJLhAB9LNHVUj1y1WpXydS5y0_P1n-hrN_6RzUtoKbGD1g@mail.gmail.com>
 <CAP7h-xYhWgWmXpX7avqwgUz3_+G=oiTfBbj-U0YSqrS3Y4WuBg@mail.gmail.com>
 <CAP7+vJKWW=we0HQFpXZakoC0Pquj-KX-yZf-rW7oLkyRs0+P7Q@mail.gmail.com>
 <CAP7h-xbj47qPCYLncqWS7SLOTS=3HtEzJzy=eA8Y-QfbN95tcA@mail.gmail.com>
 <CAExdVNkFheQUzv4tfE8sbXxnEHOmVB1iqt8Nfr8vct9WKQZjMw@mail.gmail.com>
Message-ID: <CAP7+vJLV3hXG_GFGSJ=Ms+g6tQTYTWsSaq2XVM6DX7T2q21R1w@mail.gmail.com>

Yeah, sadly the point where we *should* have made this clean break was in
3.0. That's where e.g. inequalities between a string and a number, or
between either type and None, were changed from returning something
"arbitrary but stable" into raising TypeError. It's much harder to break it
now, even with endless deprecation warnings. We might want to try again in
4.0. :-)

On Tue, Sep 22, 2015 at 1:25 PM, Tim Peters <tim.peters at gmail.com> wrote:

> [Guido]
> >> it is broken, due to the confusion about classic vs. timeline arithmetic
> >> -- these have different needs but there's only one > operator.
>
> [Alex]
> > I feel silly trying to defend a design against its author. :-)
>
> "Design" may be an overstatement in this specific case ;-)
>
> I remember implementing this stuff, getting to the comparison
> operators, and noting that the spec was silent about what to do in
> case the tzinfos differed.  I looked at Guido and explained that, and
> asked "so whaddya wanna do?".
>
> One of us (I don't recall which) said "well, we could convert to UTC
> first - that would make sense".  "Ya, sure," said the other.  And I
> said "and then, of course, interzone subtraction should do the same."
> "Of course," said Guido, now annoyed that I was bothering him with the
> obvious ;-)
>
> Note that, near that time, Python blithely compared _any_ two objects,
> even if of wildly different types.  Compared to that, doing _anything_
> arguably sane with datetime objects seemed wildly desirable.
> Ironically, the datetime implementation was Python's first library
> type to _refuse_ to compare its objects to others of wildly different
> types.
>
> So, in all, I'd say well under a minute's thought - between us - went
> into this decision.  And we've been living in Paradise ever since :-)
>
>
> > Yes, a language with more than one > symbol would not have some
> > of these problems. Similarly a language with a special symbol for
> > string catenation would not have a non-commutative + and non-
> > distributive *.  All I am saying is that I can live with the choices made
> > in datetime.
>
> Given that the alternative is suicide, I approve of that life decision.
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/d542f5b0/attachment.html>

From ncoghlan at gmail.com  Wed Sep 23 07:56:32 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Sep 2015 15:56:32 +1000
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAP7h-xbnhoOgu48jCrFev3OV6z+EqpDq3ds1K9LrPkZzy8Vd+A@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAP7h-xbnhoOgu48jCrFev3OV6z+EqpDq3ds1K9LrPkZzy8Vd+A@mail.gmail.com>
Message-ID: <CADiSq7cKW1F1_usfkqPYJPeGLA85MhjJShO-No1yopaB3anGrA@mail.gmail.com>

On 23 September 2015 at 01:09, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
>
> On Tue, Sep 22, 2015 at 10:55 AM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
>>
>> On Tue, Sep 22, 2015 at 10:43 AM, Guido van Rossum <guido at python.org>
>> wrote:
>>>>
>>>> Based on the UTC/local diagram from the "Mind the Gap" section, am I
>>>> correct in thinking that the modified invariant that also covers times
>>>> in a gap is:
>>>>
>>>>     dt ==
>>>> datetime.fromtimestamp(dt.astimezone(utc).astimezone(dt.tzinfo).timestamp())
>>>>
>>>> That is, for local times that exist, the invariant "dt ==
>>>> dt.astimezone(utc).astimezone(dt.tzinfo)" holds, but for times that
>>>> don't exist, "dt.astimezone(utc).astimezone(dt.tzinfo)" will normalise
>>>> them to be a time that actually exists in the original time zone, and
>>>> that normalisation also effectively happens when calling
>>>> "dt.timestamp()".
>>>
>>>
>>> That can't be right -- There is no way any fromtimestamp() call can
>>> return a time in the gap.
>>
>>
>> I don't think Nick said that.
>
> On the second reading, it looks like Nick's second sentence contradicts his
> first.  Guido is right.  Moreover, there is no way to get a time in the gap
> as a result of any conversion including astimezone() and fromutc() in
> addition to fromtimestamp().   Such datetimes may appear if you construct
> them explicitly, use .replace() to transplant a datetime to another timezone
> (or modify other components) and in the result of datetime + timedelta
> operation.

Sorry, what I wrote in the code wasn't what I wrote in the text, but I
didn't notice until Guido pointed out the discrepancy. To get the
right universal invariant, I should have normalised the LHS, not the
RHS:

    dt.astimezone(utc).astimezone(dt.tzinfo) ==
datetime.fromtimestamp(dt.timestamp())

For unambiguous times and times in the fold, that's a subset of the
stronger invariant:

    dt == dt.astimezone(utc).astimezone(dt.tzinfo) ==
datetime.fromtimestamp(dt.timestamp())

That stronger invariant is the one that *doesn't* hold for times in
the gap, as with fold=0 they'll get normalised to use the right UTC
offset (same UTC time, nominally an hour later local time), while with
fold=1 they get mapped to an hour earlier in both UTC and local time.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From tim.peters at gmail.com  Wed Sep 23 17:21:36 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Wed, 23 Sep 2015 10:21:36 -0500
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CADiSq7cKW1F1_usfkqPYJPeGLA85MhjJShO-No1yopaB3anGrA@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAP7h-xbnhoOgu48jCrFev3OV6z+EqpDq3ds1K9LrPkZzy8Vd+A@mail.gmail.com>
 <CADiSq7cKW1F1_usfkqPYJPeGLA85MhjJShO-No1yopaB3anGrA@mail.gmail.com>
Message-ID: <CAExdVNkezgNaQRUMLyDhp+X8Xc=TR+FYtj=tfsK0hG-8RNSarw@mail.gmail.com>

[Nick Coghlan <ncoghlan at gmail.com>]
> ...
> Sorry, what I wrote in the code wasn't what I wrote in the text, but I
> didn't notice until Guido pointed out the discrepancy. To get the
> right universal invariant, I should have normalised the LHS, not the
> RHS:
>
>     dt.astimezone(utc).astimezone(dt.tzinfo) ==
>     datetime.fromtimestamp(dt.timestamp())

That's always False, since it's comparing an aware datetime (on the
left) with a naive datetime (on the right).  There's also that,
without a tzinfo argument, .fromtimestamp() creates a naive datetime
via converting to the current system zone (which may have nothing to
do with dt.tzinfo).

So add a dt.tzinfo argument to the .fromtimestamp() call, and then it
will work as intended.

But then it's just saying that two ways of _spelling_ "convert to UTC
and back" are equivalent, which isn't saying much ;-)

Guido's reply gave a clearer invariant:

    dt.timestamp() ==
    dt.astimezone(utc).timestamp() ==
    dt.astimezone(<any other tz>).timestamp()

That's the key point.  If the timestamps are equivalent, then it
follows that conversions to UTC are equivalent (UTC calendar notation
is just another way to spell a POSIX timestamp), and so also that
conversions back from UTC are equivalent.


> For unambiguous times and times in the fold, that's a subset of the

You meant "ambiguous" there?


> stronger invariant:
>
>     dt == dt.astimezone(utc).astimezone(dt.tzinfo) ==
> datetime.fromtimestamp(dt.timestamp())

Same notes as above (always False because ...).


> That stronger invariant is the one that *doesn't* hold for times in
> the gap, as with fold=0 they'll get normalised to use the right UTC
> offset (same UTC time,

Same UTC time as what?  There is no UTC time corresponding to a local
gap time, since the latter "doesn't really exist".  We're making one
up, in the fold=0 case acting as if the user had remembered to move
their clock hands forward when the gap started.  "Garbage in, good
guess out" ;-)

> nominally an hour later local time),

Bingo.

> while with fold=1 they get mapped to an hour earlier in both UTC
> and local time.

Yup.

All obvious to the most casual observer ;-)

From ncoghlan at gmail.com  Thu Sep 24 04:47:11 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 24 Sep 2015 12:47:11 +1000
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CAExdVNkezgNaQRUMLyDhp+X8Xc=TR+FYtj=tfsK0hG-8RNSarw@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAP7h-xbnhoOgu48jCrFev3OV6z+EqpDq3ds1K9LrPkZzy8Vd+A@mail.gmail.com>
 <CADiSq7cKW1F1_usfkqPYJPeGLA85MhjJShO-No1yopaB3anGrA@mail.gmail.com>
 <CAExdVNkezgNaQRUMLyDhp+X8Xc=TR+FYtj=tfsK0hG-8RNSarw@mail.gmail.com>
Message-ID: <CADiSq7fWzZJ9Rrouh-aJa-D1nt5CgQEHNn5pVKgvL5rojq3Dng@mail.gmail.com>

On 24 Sep 2015 01:21, "Tim Peters" <tim.peters at gmail.com> wrote:

>
> Guido's reply gave a clearer invariant:
>
>     dt.timestamp() ==
>     dt.astimezone(utc).timestamp() ==
>     dt.astimezone(<any other tz>).timestamp()
>
> That's the key point.  If the timestamps are equivalent, then it
> follows that conversions to UTC are equivalent (UTC calendar notation
> is just another way to spell a POSIX timestamp), and so also that
> conversions back from UTC are equivalent.

Thanks for the additional clarifications all, I'm confident I understand
now :)

Might it be worth mentioning Guido's invariant in the section of the PEP
about the timestamp method?

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150924/77f592db/attachment.html>

From alexander.belopolsky at gmail.com  Thu Sep 24 05:07:27 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 23 Sep 2015 23:07:27 -0400
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CADiSq7fWzZJ9Rrouh-aJa-D1nt5CgQEHNn5pVKgvL5rojq3Dng@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAP7h-xbnhoOgu48jCrFev3OV6z+EqpDq3ds1K9LrPkZzy8Vd+A@mail.gmail.com>
 <CADiSq7cKW1F1_usfkqPYJPeGLA85MhjJShO-No1yopaB3anGrA@mail.gmail.com>
 <CAExdVNkezgNaQRUMLyDhp+X8Xc=TR+FYtj=tfsK0hG-8RNSarw@mail.gmail.com>
 <CADiSq7fWzZJ9Rrouh-aJa-D1nt5CgQEHNn5pVKgvL5rojq3Dng@mail.gmail.com>
Message-ID: <CAP7h-xY1CJOS-Vg+DfcMPrs+XivfXO+Cy8UfW5nM3aoYSSsPiA@mail.gmail.com>

>
> [Tim Peters]
>
> >
> > Guido's reply gave a clearer invariant:
> >
> >     dt.timestamp() ==
> >     dt.astimezone(utc).timestamp() ==
> >     dt.astimezone(<any other tz>).timestamp()
>
> [ Nick Coghlan]

> Might it be worth mentioning Guido's invariant in the section of the PEP
> about the timestamp method?
>
The case of missing time in Guido's invariant is rather subtle.  What is
happening is that .timestamp()  and .astimezone(..) methods use the same
"normalization" to interpret what dt means.  This is not obvious in the
expression above.  Particularly in dt.astimezone(<any other
tz>).timestamp().  Here, if instead of <any other tz> we pass dt.tzinfo,
then .astimezone(..) becomes a noop and "normalization" happens in
.timestamp().  I don't think exposing all this in the PEP will help.  Let's
return to this when it is time to write the reference documentation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150923/35c9935d/attachment.html>

From francismb at email.de  Thu Sep 24 22:13:17 2015
From: francismb at email.de (francismb)
Date: Thu, 24 Sep 2015 22:13:17 +0200
Subject: [Python-Dev] PEP 495 accepted
In-Reply-To: <CADiSq7fWzZJ9Rrouh-aJa-D1nt5CgQEHNn5pVKgvL5rojq3Dng@mail.gmail.com>
References: <CAP7+vJLSRL-g6Gd9+tZ5dOePEt3OHUJHcFuQeq6-c84kTSttpg@mail.gmail.com>
 <CADiSq7dC3C1i_8dXLhFdG2RTN7un3-uY=i_vmM1JXVGi39CVeQ@mail.gmail.com>
 <CADiSq7c19hhFMM_y7NDjrUqn7obT-6z10fV60-Lni1JRcXR_pQ@mail.gmail.com>
 <CAP7+vJKfRdPv-uePr0xRsHHvzzOJ6eYcR6tT0EFbjbwQx0Ujjg@mail.gmail.com>
 <CAP7h-xY2jmqUc5Z5KZir+SCa9UOfzwp_vRKkpGN0C6S8AW5-4g@mail.gmail.com>
 <CAP7h-xbnhoOgu48jCrFev3OV6z+EqpDq3ds1K9LrPkZzy8Vd+A@mail.gmail.com>
 <CADiSq7cKW1F1_usfkqPYJPeGLA85MhjJShO-No1yopaB3anGrA@mail.gmail.com>
 <CAExdVNkezgNaQRUMLyDhp+X8Xc=TR+FYtj=tfsK0hG-8RNSarw@mail.gmail.com>
 <CADiSq7fWzZJ9Rrouh-aJa-D1nt5CgQEHNn5pVKgvL5rojq3Dng@mail.gmail.com>
Message-ID: <5604595D.6030902@email.de>



On 09/24/2015 04:47 AM, Nick Coghlan wrote:
> On 24 Sep 2015 01:21, "Tim Peters" <tim.peters at gmail.com> wrote:
> 
>>
>> Guido's reply gave a clearer invariant:
>>
>>     dt.timestamp() ==
>>     dt.astimezone(utc).timestamp() ==
>>     dt.astimezone(<any other tz>).timestamp()
>>

> Might it be worth mentioning Guido's invariant in the section of the PEP
> about the timestamp method?
> 

Or maybe worth adding it as unittest?

Regards,
francis



From chris.barker at noaa.gov  Fri Sep 25 17:24:42 2015
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Fri, 25 Sep 2015 08:24:42 -0700
Subject: [Python-Dev] VS 2010 compiler
Message-ID: <-2386876371239912889@unknownmsgid>

As I understand it, the MS VS2010 compiler is required (or at least
best practice) for compiling Python extensions for the python.org
Windows builds of py 3.4 and ?[1]

However, MS now makes it very hard (impossible?) to download VS2010
Express ( or Community, or whatever the free as in beer version is
called).

I realize that this is not python-dev's responsibility, but if there
is any way to either document where it can be found, or put a bit of
pressure on MS to make it available, as they have for VS2008 and
py2.7, that would be great.

Sorry to bug this list, I didn't know where else to reach out to.

-Chris

[1] it's actually prefer hard to find out which compiler version is
used for which python version. And has been for years. Would a patch
to the docs, probably here:

https://docs.python.org/3.4/using/windows.html#compiling-python-on-windows

Be considered?

From songofacandy at gmail.com  Fri Sep 25 17:35:50 2015
From: songofacandy at gmail.com (INADA Naoki)
Date: Sat, 26 Sep 2015 00:35:50 +0900
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <-2386876371239912889@unknownmsgid>
References: <-2386876371239912889@unknownmsgid>
Message-ID: <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>

You can use "Windows SDK for Windows 7 and .NET Framework 4".

http://www.microsoft.com/en-us/download/details.aspx?id=8279

On Sat, Sep 26, 2015 at 12:24 AM, Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:

> As I understand it, the MS VS2010 compiler is required (or at least
> best practice) for compiling Python extensions for the python.org
> Windows builds of py 3.4 and ?[1]
>
> However, MS now makes it very hard (impossible?) to download VS2010
> Express ( or Community, or whatever the free as in beer version is
> called).
>
> I realize that this is not python-dev's responsibility, but if there
> is any way to either document where it can be found, or put a bit of
> pressure on MS to make it available, as they have for VS2008 and
> py2.7, that would be great.
>
> Sorry to bug this list, I didn't know where else to reach out to.
>
> -Chris
>
> [1] it's actually prefer hard to find out which compiler version is
> used for which python version. And has been for years. Would a patch
> to the docs, probably here:
>
> https://docs.python.org/3.4/using/windows.html#compiling-python-on-windows
>
> Be considered?
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>



-- 
INADA Naoki  <songofacandy at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150926/915bc534/attachment.html>

From status at bugs.python.org  Fri Sep 25 18:08:31 2015
From: status at bugs.python.org (Python tracker)
Date: Fri, 25 Sep 2015 18:08:31 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20150925160831.930AF56915@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2015-09-18 - 2015-09-25)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    5142 (+12)
  closed 31849 (+51)
  total  36991 (+63)

Open issues with patches: 2286 


Issues opened (47)
==================

#23329: _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5)
http://bugs.python.org/issue23329  reopened by haypo

#24915: Profile Guided Optimization improvements (better training, llv
http://bugs.python.org/issue24915  reopened by haypo

#25170: 3.5.0 documentation archives missing
http://bugs.python.org/issue25170  opened by Arfrever

#25171: does not build on OpenBSD with no value defined for PY_GETENTR
http://bugs.python.org/issue25171  opened by rpointel

#25172: Unix-only crypt should not be present on Windows.
http://bugs.python.org/issue25172  opened by terry.reedy

#25173: IDLE - several common dialogs don't have correct parent set
http://bugs.python.org/issue25173  opened by markroseman

#25175: Documentation-Tkinter Clarify module spelling change in Python
http://bugs.python.org/issue25175  opened by Rishit Bansal

#25177: OverflowError in statistics.mean when summing large floats
http://bugs.python.org/issue25177  opened by David MacIver

#25178: IDLE: search regex errors should be in/attached to search dial
http://bugs.python.org/issue25178  opened by markroseman

#25179: PEP 498 f-strings need to be documented
http://bugs.python.org/issue25179  opened by eric.smith

#25181: Tests failed in nondecodable directory
http://bugs.python.org/issue25181  opened by serhiy.storchaka

#25182: python -v crashes in nonencodable directory
http://bugs.python.org/issue25182  opened by serhiy.storchaka

#25183: python -m inspect --details fails in nondecodable directory
http://bugs.python.org/issue25183  opened by serhiy.storchaka

#25184: "python -m pydoc -w" fails in nondecodable directory
http://bugs.python.org/issue25184  opened by serhiy.storchaka

#25185: Inconsistency between venv and site
http://bugs.python.org/issue25185  opened by serhiy.storchaka

#25186: Don't duplicate _verbose_message in importlib._bootstrap and _
http://bugs.python.org/issue25186  opened by brett.cannon

#25187: bdist_rpm fails due to wrong hardcoded assumption about RPM fi
http://bugs.python.org/issue25187  opened by dpward

#25188: regrtest.py improvement for Profile Guided Optimization builds
http://bugs.python.org/issue25188  opened by alecsandru.patrascu

#25190: Define StringIO seek offset as code point offset
http://bugs.python.org/issue25190  opened by martin.panter

#25191: test_getsetlocale_issue1813 failed on OpenBSD
http://bugs.python.org/issue25191  opened by rpointel

#25193: itertools.accumulate should have an optional initializer argum
http://bugs.python.org/issue25193  opened by Alun Champion

#25194: Register of Financial Interests for core contributors
http://bugs.python.org/issue25194  opened by ncoghlan

#25195: mock.ANY doesn't match mock.MagicMock() object
http://bugs.python.org/issue25195  opened by felixonmars

#25196: Installer>Install in user folder by default when you check: fo
http://bugs.python.org/issue25196  opened by Abdullah Hilson

#25197: Allow documentation switcher to change url to /3/ and /dev/
http://bugs.python.org/issue25197  opened by mbussonn

#25198: Idle: improve idle.html help viewer.
http://bugs.python.org/issue25198  opened by terry.reedy

#25203: Incorrect handling MemoryError in readline.set_completer_delim
http://bugs.python.org/issue25203  opened by serhiy.storchaka

#25204: Confusing (?) warning when run deprecated module as script
http://bugs.python.org/issue25204  opened by serhiy.storchaka

#25205: setattr accepts invalid identifiers
http://bugs.python.org/issue25205  opened by W deW

#25207: ICC compiler warnings
http://bugs.python.org/issue25207  opened by haypo

#25209: Append space after completed keywords
http://bugs.python.org/issue25209  opened by serhiy.storchaka

#25210: Special-case NoneType() in do_richcompare()
http://bugs.python.org/issue25210  opened by ezio.melotti

#25211: Error message formatting errors in int object unit-test script
http://bugs.python.org/issue25211  opened by s-wakaba

#25216: Warnings stacklevel frames to skip
http://bugs.python.org/issue25216  opened by Jim.Jewett

#25217: Method cache can crash at shutdown in _PyType_Lookup
http://bugs.python.org/issue25217  opened by pitrou

#25218: Automate creation of idlelib/help.html from Doc/.../idle.html
http://bugs.python.org/issue25218  opened by terry.reedy

#25219: Update doc for Idle command line options.
http://bugs.python.org/issue25219  opened by terry.reedy

#25220: Enhance and refactor test.regrtest (convert regrtest.py to a p
http://bugs.python.org/issue25220  opened by haypo

#25221: PyLong_FromLong() potentially returns irregular object when sm
http://bugs.python.org/issue25221  opened by s-wakaba

#25222: 3.5.0 regression - Fatal Python error: Cannot recover from sta
http://bugs.python.org/issue25222  opened by behackett

#25224: Replace Idle's README.txt with annotated file list
http://bugs.python.org/issue25224  opened by terry.reedy

#25226: "suffix" attribute not documented in logging.TimedRotatingFile
http://bugs.python.org/issue25226  opened by NobilisVir

#25227: Optimize ASCII/latin1 encoder with surrogateescape error handl
http://bugs.python.org/issue25227  opened by haypo

#25228: Regression in cookie parsing with brackets and quotes
http://bugs.python.org/issue25228  opened by Tim.Graham

#25229: distutils doesn't add "-Wl," prefix to "-R" on Linux if the C 
http://bugs.python.org/issue25229  opened by Calvin Walton

#25230: Unix datagram sockets not supported
http://bugs.python.org/issue25230  opened by rb

#25232: CGIRequestHandler behave incorrectly with query component cons
http://bugs.python.org/issue25232  opened by xiang.zhang



Most recent 15 issues with no replies (15)
==========================================

#25232: CGIRequestHandler behave incorrectly with query component cons
http://bugs.python.org/issue25232

#25229: distutils doesn't add "-Wl," prefix to "-R" on Linux if the C 
http://bugs.python.org/issue25229

#25228: Regression in cookie parsing with brackets and quotes
http://bugs.python.org/issue25228

#25226: "suffix" attribute not documented in logging.TimedRotatingFile
http://bugs.python.org/issue25226

#25221: PyLong_FromLong() potentially returns irregular object when sm
http://bugs.python.org/issue25221

#25218: Automate creation of idlelib/help.html from Doc/.../idle.html
http://bugs.python.org/issue25218

#25217: Method cache can crash at shutdown in _PyType_Lookup
http://bugs.python.org/issue25217

#25216: Warnings stacklevel frames to skip
http://bugs.python.org/issue25216

#25204: Confusing (?) warning when run deprecated module as script
http://bugs.python.org/issue25204

#25203: Incorrect handling MemoryError in readline.set_completer_delim
http://bugs.python.org/issue25203

#25197: Allow documentation switcher to change url to /3/ and /dev/
http://bugs.python.org/issue25197

#25195: mock.ANY doesn't match mock.MagicMock() object
http://bugs.python.org/issue25195

#25191: test_getsetlocale_issue1813 failed on OpenBSD
http://bugs.python.org/issue25191

#25187: bdist_rpm fails due to wrong hardcoded assumption about RPM fi
http://bugs.python.org/issue25187

#25183: python -m inspect --details fails in nondecodable directory
http://bugs.python.org/issue25183



Most recent 15 issues waiting for review (15)
=============================================

#25232: CGIRequestHandler behave incorrectly with query component cons
http://bugs.python.org/issue25232

#25229: distutils doesn't add "-Wl," prefix to "-R" on Linux if the C 
http://bugs.python.org/issue25229

#25228: Regression in cookie parsing with brackets and quotes
http://bugs.python.org/issue25228

#25227: Optimize ASCII/latin1 encoder with surrogateescape error handl
http://bugs.python.org/issue25227

#25221: PyLong_FromLong() potentially returns irregular object when sm
http://bugs.python.org/issue25221

#25220: Enhance and refactor test.regrtest (convert regrtest.py to a p
http://bugs.python.org/issue25220

#25211: Error message formatting errors in int object unit-test script
http://bugs.python.org/issue25211

#25209: Append space after completed keywords
http://bugs.python.org/issue25209

#25204: Confusing (?) warning when run deprecated module as script
http://bugs.python.org/issue25204

#25203: Incorrect handling MemoryError in readline.set_completer_delim
http://bugs.python.org/issue25203

#25198: Idle: improve idle.html help viewer.
http://bugs.python.org/issue25198

#25197: Allow documentation switcher to change url to /3/ and /dev/
http://bugs.python.org/issue25197

#25194: Register of Financial Interests for core contributors
http://bugs.python.org/issue25194

#25188: regrtest.py improvement for Profile Guided Optimization builds
http://bugs.python.org/issue25188

#25187: bdist_rpm fails due to wrong hardcoded assumption about RPM fi
http://bugs.python.org/issue25187



Top 10 most discussed issues (10)
=================================

#25210: Special-case NoneType() in do_richcompare()
http://bugs.python.org/issue25210  17 msgs

#24915: Profile Guided Optimization improvements (better training, llv
http://bugs.python.org/issue24915  15 msgs

#18967: Find a less conflict prone approach to Misc/NEWS
http://bugs.python.org/issue18967  12 msgs

#25194: Register of Financial Interests for core contributors
http://bugs.python.org/issue25194  12 msgs

#25220: Enhance and refactor test.regrtest (convert regrtest.py to a p
http://bugs.python.org/issue25220  12 msgs

#25222: 3.5.0 regression - Fatal Python error: Cannot recover from sta
http://bugs.python.org/issue25222  12 msgs

#24870: Optimize ascii and latin1 decoder with surrogateescape and sur
http://bugs.python.org/issue24870  10 msgs

#25205: setattr accepts invalid identifiers
http://bugs.python.org/issue25205  10 msgs

#16701: Docs missing the behavior of += (in-place add) for lists.
http://bugs.python.org/issue16701   8 msgs

#25177: OverflowError in statistics.mean when summing large floats
http://bugs.python.org/issue25177   8 msgs



Issues closed (50)
==================

#4918: Windows installer created with Python X.Y does not work with P
http://bugs.python.org/issue4918  closed by eryksun

#16893: Generate Idle help from Doc/library/idle.rst
http://bugs.python.org/issue16893  closed by terry.reedy

#19143: Finding the Windows version getting messier (detect windows 8.
http://bugs.python.org/issue19143  closed by steve.dower

#22820: RESTART line with no output
http://bugs.python.org/issue22820  closed by terry.reedy

#23484: SemLock acquire() keyword arg 'blocking' is invalid
http://bugs.python.org/issue23484  closed by berker.peksag

#23630: support multiple hosts in create_server/start_server
http://bugs.python.org/issue23630  closed by haypo

#23979: Multiprocessing Pool.map pickles arguments passed to workers
http://bugs.python.org/issue23979  closed by davin

#24779: Python/ast.c: decode_unicode is never called with rawmode=True
http://bugs.python.org/issue24779  closed by eric.smith

#24801: right-mouse click in IDLE on Mac doesn't work
http://bugs.python.org/issue24801  closed by terry.reedy

#24861: deprecate importing components of IDLE
http://bugs.python.org/issue24861  closed by terry.reedy

#24894: iso-8859-11 missing from codecs table
http://bugs.python.org/issue24894  closed by ezio.melotti

#24965: Implement PEP 498: Literal String Formatting
http://bugs.python.org/issue24965  closed by eric.smith

#25047: xml.etree.ElementTree encoding declaration should be capital (
http://bugs.python.org/issue25047  closed by martin.panter

#25057: Make parameter of io.base to be positional and keyword
http://bugs.python.org/issue25057  closed by martin.panter

#25081: Windows installer Upgrade->Customize->Back goes to Install pag
http://bugs.python.org/issue25081  closed by steve.dower

#25084: remove semi-busy loop in py2.7 threading.Condition.wait(timeou
http://bugs.python.org/issue25084  closed by pitrou

#25085: Windows x86-64 embeddable zip file contains test directorys
http://bugs.python.org/issue25085  closed by python-dev

#25086: Windows x86-64 embeddable zip file, lot of big EXE files in di
http://bugs.python.org/issue25086  closed by steve.dower

#25092: Regression: test_datetime fails on 3.5, Win 7, works on 3.4
http://bugs.python.org/issue25092  closed by steve.dower

#25101: test_zipfile failure when run by unprivileged user with instal
http://bugs.python.org/issue25101  closed by serhiy.storchaka

#25102: Windows installer: 'precompile standard library' option should
http://bugs.python.org/issue25102  closed by steve.dower

#25103: 3.5.0 installed standard library on Windows has LF line ending
http://bugs.python.org/issue25103  closed by steve.dower

#25112: Windows installer assigns non-existent icons to Python file ty
http://bugs.python.org/issue25112  closed by steve.dower

#25114: asyncio: add ssl_object extra info
http://bugs.python.org/issue25114  closed by haypo

#25124: No single .msi available for 3.5 release
http://bugs.python.org/issue25124  closed by steve.dower

#25126: Non-web installer fails without a connection when doing debug 
http://bugs.python.org/issue25126  closed by steve.dower

#25133: Clarify that the constants in selectors are module-level
http://bugs.python.org/issue25133  closed by brett.cannon

#25138: test_socket: socket.EAI_NODATA doesn't exist on FreeBSD
http://bugs.python.org/issue25138  closed by haypo

#25145: urllib how-to should be updated to remove PyGoogle
http://bugs.python.org/issue25145  closed by benjamin.peterson

#25148: Windows registry PythonCore key changed inconsistent with othe
http://bugs.python.org/issue25148  closed by steve.dower

#25162: Windows installation does not appear in list of installed appl
http://bugs.python.org/issue25162  closed by steve.dower

#25169: multiprocessing docs example still refs os.getppid as unix-onl
http://bugs.python.org/issue25169  closed by berker.peksag

#25174: Backspace Escape Character at End of String
http://bugs.python.org/issue25174  closed by martin.panter

#25176: Link to urllib.parse.parse_qsl, not parse_qs, from cgi.parse_q
http://bugs.python.org/issue25176  closed by martin.panter

#25180: Tools/parser/unparse.py needs to be updated for f-strings
http://bugs.python.org/issue25180  closed by eric.smith

#25189: An issue about os.access
http://bugs.python.org/issue25189  closed by serhiy.storchaka

#25192: deque append and appendleft should return value if maxlen set
http://bugs.python.org/issue25192  closed by rhettinger

#25199: Idle: add cross-references from and to macosxSupport
http://bugs.python.org/issue25199  closed by terry.reedy

#25200: bug on re.search using the char ,-:
http://bugs.python.org/issue25200  closed by serhiy.storchaka

#25201: lock of multiprocessing.Value is not a keyword-only argument
http://bugs.python.org/issue25201  closed by berker.peksag

#25202: Windows: with-statement doesn't release file handle after exce
http://bugs.python.org/issue25202  closed by eryksun

#25206: PEP 498: Minor mistakes/outdateness
http://bugs.python.org/issue25206  closed by eric.smith

#25208: improvements to the asyncio documentation
http://bugs.python.org/issue25208  closed by asvetlov

#25212: Remove the double spaces in the C-API Intro
http://bugs.python.org/issue25212  closed by ezio.melotti

#25213: Regression: Python 3.5.0 shutil.copy2 doesn't raise Permission
http://bugs.python.org/issue25213  closed by steve.dower

#25214: asyncio ssl transport regression
http://bugs.python.org/issue25214  closed by haypo

#25215: Simple extension to iter(): iter() returns empty generator
http://bugs.python.org/issue25215  closed by brett.cannon

#25223: Statically or dynamically linked  to the VC++runtime ? or how 
http://bugs.python.org/issue25223  closed by acx01bc

#25225: Idle doc: redo Syntax Colors section
http://bugs.python.org/issue25225  closed by terry.reedy

#25231: Argparse module and escape sequence (special symbols) in argum
http://bugs.python.org/issue25231  closed by martin.panter

From steve.dower at python.org  Fri Sep 25 19:03:57 2015
From: steve.dower at python.org (Steve Dower)
Date: Fri, 25 Sep 2015 10:03:57 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <-2386876371239912889@unknownmsgid>
References: <-2386876371239912889@unknownmsgid>
Message-ID: <56057E7D.6070207@python.org>

On 25Sep2015 0824, Chris Barker - NOAA Federal wrote:
> As I understand it, the MS VS2010 compiler is required (or at least
> best practice) for compiling Python extensions for the python.org
> Windows builds of py 3.4 and ?[1]
>
> However, MS now makes it very hard (impossible?) to download VS2010
> Express ( or Community, or whatever the free as in beer version is
> called).

This is the main motivation for moving to VS 2015 for Python 3.5. See 
https://docs.python.org/3.5/using/windows.html#compiling-python-on-windows 
(same link as [1] with the version changed) and also 
https://docs.python.org/3.5/whatsnew/3.5.html

> I realize that this is not python-dev's responsibility, but if there
> is any way to either document where it can be found, or put a bit of
> pressure on MS to make it available, as they have for VS2008 and
> py2.7, that would be great.

I've applied that pressure already and it's not going to happen :(

The best "solution" is to move to Py 3.5 asap. If you're writing an 
extension and are being careful, you can use a later compiler to build 
for 3.4 with Py_LIMITED_API set and a lot of care (did I mention you 
need to be careful? It's not just FILE* that will break...).

Cheers,
Steve

> Sorry to bug this list, I didn't know where else to reach out to.
>
> -Chris
>
> [1] it's actually prefer hard to find out which compiler version is
> used for which python version. And has been for years. Would a patch
> to the docs, probably here:
>
> https://docs.python.org/3.4/using/windows.html#compiling-python-on-windows
>
> Be considered?


From chris.barker at noaa.gov  Sat Sep 26 00:24:33 2015
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Fri, 25 Sep 2015 15:24:33 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <56057E7D.6070207@python.org>
References: <-2386876371239912889@unknownmsgid> <56057E7D.6070207@python.org>
Message-ID: <2676212691016314813@unknownmsgid>

> This is the main motivation for moving to VS 2015 for Python 3.5.

Yes,I've followed that work to the degree I understand it, and it
looks like a great move. Thanks so much for your (continuing) efforts
with this.

> put a bit of
>>
>> pressure on MS to make it available, as they have for VS2008 and
>> py2.7, that would be great.
>
> I've applied that pressure already and it's not going to happen :(

Darn. Makes no sense, but I work for almost as big a  bureaucracy as
MS, so I know how that goes... :-)

> The best "solution" is to move to Py 3.5 asap.

Really not a solution at all, I'm afraid, and there are still growing
pains with compiling for it as well (see Numpy/SciPy).

But thanks.

-Chris

From chris.barker at noaa.gov  Sat Sep 26 00:27:22 2015
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Fri, 25 Sep 2015 15:27:22 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
Message-ID: <4655937719415280861@unknownmsgid>

You can use "Windows SDK for Windows 7 and .NET Framework 4".

http://www.microsoft.com/en-us/download/details.aspx?id=8279


Thanks. Last time I tried that route, it was for 64 bit py2.7. And it
required some kludging of environment variables, and registry acces I don't
have permission for.

But it still may be the best bet. I'll give it a try when I have a chance.

And this should be in the "official" docs...

-CHB



On Sat, Sep 26, 2015 at 12:24 AM, Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:

> As I understand it, the MS VS2010 compiler is required (or at least
> best practice) for compiling Python extensions for the python.org
> Windows builds of py 3.4 and ?[1]
>
> However, MS now makes it very hard (impossible?) to download VS2010
> Express ( or Community, or whatever the free as in beer version is
> called).
>
> I realize that this is not python-dev's responsibility, but if there
> is any way to either document where it can be found, or put a bit of
> pressure on MS to make it available, as they have for VS2008 and
> py2.7, that would be great.
>
> Sorry to bug this list, I didn't know where else to reach out to.
>
> -Chris
>
> [1] it's actually prefer hard to find out which compiler version is
> used for which python version. And has been for years. Would a patch
> to the docs, probably here:
>
> https://docs.python.org/3.4/using/windows.html#compiling-python-on-windows
>
> Be considered?
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>



-- 
INADA Naoki  <songofacandy at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150925/a5096900/attachment.html>

From vijayram.gopu at gmail.com  Sat Sep 26 19:26:39 2015
From: vijayram.gopu at gmail.com (vijayram)
Date: Sat, 26 Sep 2015 10:26:39 -0700
Subject: [Python-Dev] xunit unittest.TestSuite
Message-ID: <0327B62A-372D-44FE-BC6C-957878DEC545@gmail.com>

 Hi All,

I am facing this same issue described here: https://github.com/nose-devs/nose/issues/542 <https://github.com/nose-devs/nose/issues/542>

any alternative or solution to this issue that anyone is aware of... please kindly suggest...

Thank you,
VJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150926/33f5dc41/attachment.html>

From rdmurray at bitdance.com  Sat Sep 26 20:53:03 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 26 Sep 2015 14:53:03 -0400
Subject: [Python-Dev] xunit unittest.TestSuite
In-Reply-To: <0327B62A-372D-44FE-BC6C-957878DEC545@gmail.com>
References: <0327B62A-372D-44FE-BC6C-957878DEC545@gmail.com>
Message-ID: <20150926185304.64C71B1408F@webabinitio.net>

On Sat, 26 Sep 2015 10:26:39 -0700, vijayram <vijayram.gopu at gmail.com> wrote:
> I am facing this same issue described here: https://github.com/nose-devs/nose/issues/542 <https://github.com/nose-devs/nose/issues/542>
> 
> any alternative or solution to this issue that anyone is aware of... please kindly suggest...

This is a forum for the development of the CPython interpreter and
standard library.  For issues involving nose, you want a nose-specific
forum.

--David

From alexander.belopolsky at gmail.com  Mon Sep 28 03:08:02 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Sun, 27 Sep 2015 21:08:02 -0400
Subject: [Python-Dev] Committing a bug fix
Message-ID: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>

Can someone remind me which branches regular (non-security) bug fixes go to
these days?  See <http://bugs.python.org/issue23600> for context.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150927/a6a784ad/attachment.html>

From rdmurray at bitdance.com  Mon Sep 28 03:12:50 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 27 Sep 2015 21:12:50 -0400
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
Message-ID: <20150928011254.09D7125104A@webabinitio.net>

On Sun, 27 Sep 2015 21:08:02 -0400, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> Can someone remind me which branches regular (non-security) bug fixes go to
> these days?  See <http://bugs.python.org/issue23600> for context.

3.4, 3.5, and default.

(3.4 for only another few weeks.)

--David

From alexander.belopolsky at gmail.com  Mon Sep 28 04:05:06 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Sun, 27 Sep 2015 22:05:06 -0400
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <20150928011254.09D7125104A@webabinitio.net>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
 <20150928011254.09D7125104A@webabinitio.net>
Message-ID: <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>

On Sun, Sep 27, 2015 at 9:12 PM, R. David Murray <rdmurray at bitdance.com>
wrote:

> ..
>
> 3.4, 3.5, and default.
>
> Thanks.  Maybe you can help me to make hg cooperate.  I made commits to
 3.4, 3.5, and default and tried to push, but hg complains:

remote has heads on branch '3.4' that are not known locally: 46aaff5e8945
remote has heads on branch '3.5' that are not known locally: 0d3b64bbc82c
remote has heads on branch 'default' that are not known locally:
48943533965e
abort: push creates new remote head ff68705c56a8 on branch '3.4'!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150927/78d8adc4/attachment.html>

From tjreedy at udel.edu  Mon Sep 28 05:40:16 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 27 Sep 2015 23:40:16 -0400
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
 <20150928011254.09D7125104A@webabinitio.net>
 <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>
Message-ID: <muacr2$jb3$1@ger.gmane.org>

On 9/27/2015 10:05 PM, Alexander Belopolsky wrote:
>
>
> On Sun, Sep 27, 2015 at 9:12 PM, R. David Murray <rdmurray at bitdance.com
> <mailto:rdmurray at bitdance.com>> wrote:
>
>     ..
>
>     3.4, 3.5, and default.

3.4.4rc1 is due out next Sunday.  Only emergency patches after that.

> Thanks.  Maybe you can help me to make hg cooperate.  I made commits to
>   3.4, 3.5, and default and tried to push, but hg complains:

See the python-checking list, which you should be reading.
You neglected to forward merge a 3.4-3.4 merge and a 3.5-3.5 merge.  I 
failed to notice the first and added a commit, and then backed it out, 
when I could not merge forward due to merge conflicts with your commits. 
  Perhaps you just need to null-merge the 3.4 commits into 3.5, but I do 
not really know how to make the repository usable again.

> remote has heads on branch '3.4' that are not known locally: 46aaff5e8945
> remote has heads on branch '3.5' that are not known locally: 0d3b64bbc82c
> remote has heads on branch 'default' that are not known locally:
> 48943533965e
> abort: push creates new remote head ff68705c56a8 on branch '3.4'!
>
>


-- 
Terry Jan Reedy


From vadmium+py at gmail.com  Mon Sep 28 08:56:43 2015
From: vadmium+py at gmail.com (Martin Panter)
Date: Mon, 28 Sep 2015 06:56:43 +0000
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <muacr2$jb3$1@ger.gmane.org>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
 <20150928011254.09D7125104A@webabinitio.net>
 <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>
 <muacr2$jb3$1@ger.gmane.org>
Message-ID: <CA+eR4cFPNf=ahdj4K4H2aaP8w2QC60c1=PUYCR3dbEVTMrsxwQ@mail.gmail.com>

On 28/09/2015, Terry Reedy <tjreedy at udel.edu> wrote:
> You neglected to forward merge a 3.4-3.4 merge and a 3.5-3.5 merge.  I
> failed to notice the first and added a commit, and then backed it out,
> when I could not merge forward due to merge conflicts with your commits.
>   Perhaps you just need to null-merge the 3.4 commits into 3.5, but I do
> not really know how to make the repository usable again.

Hopefully I have fixed this for you. My technique is below. I first
tried with Mercurial 2.7, but updated to 3.5 which apparently grew
some support for ?criss-cross? merges, and this helped a lot with the
second merge.

hg update 3.5
hg merge 3.4  # NEWS and Argument Clinic files conflict
hg revert -r . Misc/NEWS Modules/clinic/_datetimemodule.c.h
python Tools/clinic/clinic.py --make
# Verify both Alexander and Serhiy?s entries already in NEWS
hg diff -p  # No file changes to 3.5 branch
hg resolve -m
hg commit -m "Merge from 3.4 into 3.5; no file changes"
hg update default
hg merge 3.5  # No conflicts; 3 ? ?ambiguous merge - picked m action?
hg diff -p  # Duplicate NEWS entry
hg revert -r . Misc/NEWS
hg diff -p  # No changes
hg commit -m "Merge from 3.5; no file changes"

Summary of what I think was going on: Serhiy made some changes quite a
few hours ago to do with readline.set_completer_delims(). Meanwhile,
Alexander made some tzinfo.fromutc() commits based on revisions before
Serhiy?s changes. A couple comments on Alexander?s commits:

ff68705c56a8: Initial 3.4 patch has a trailing space in NEWS
c706c062f545: Initial merge into 3.5 removes this trailing space
cbcf82f92c25: Looks like a second version of the original patch
(ff68705c56a8), except without the extra space. I guess you got
confused, but it would have been better to not push this commit :)

Also @Terry, not sure on your workflow, but you might have been able
to avoid pushing your 3.4 commits. You might have been able to remove
it locally by using ?hg strip? or deleting your local repository. Or
just leave it locally until the other branches got sorted out. Notice
that the 3.4 branch still has your backout commit at the top.

For what it?s worth, I have more faith in Git for merging stuff like
this smoothly. But today I learnt that the newer Mercurial version
does behave a bit better than it used to.

From tjreedy at udel.edu  Mon Sep 28 10:13:59 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 28 Sep 2015 04:13:59 -0400
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <CA+eR4cFPNf=ahdj4K4H2aaP8w2QC60c1=PUYCR3dbEVTMrsxwQ@mail.gmail.com>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
 <20150928011254.09D7125104A@webabinitio.net>
 <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>
 <muacr2$jb3$1@ger.gmane.org>
 <CA+eR4cFPNf=ahdj4K4H2aaP8w2QC60c1=PUYCR3dbEVTMrsxwQ@mail.gmail.com>
Message-ID: <muass9$pu8$1@ger.gmane.org>

On 9/28/2015 2:56 AM, Martin Panter wrote:

> Also @Terry, not sure on your workflow,

Normal one specified in devguide: commit 3.4, merge 3.5, merge 3.6,
except I do it with TortoiseHG Workbench GUI.

 >  but you might have been able
> to avoid pushing your 3.4 commits. You might have been able to remove
> it locally by using ?hg strip?

I need to look into that.

> or deleting your local repository.

I have 1 clone for default/3.6 and 3 shares with working directory only 
for 3.5, 3.4, and 2.7.  I believe that deleting 3.4 working directory 
would have no effect as it would be regenerated from default clone.

> Or just leave it locally until the other branches got sorted out.

Then I risked having to do a head merge in 2.7 or head merge + forward 
merges in 3.4,5,6 is someone else pushed before I got back to this, 
which I know was going to be several hours, after returning from rushing 
off to work on another project.

> Notice that the 3.4 branch still has your backout commit at the top.

Your merges merged my commit and revert forward.  I could have left just 
the commit, but they whoever would have had to decide what to do with 
it.  I though it easier for me to just start over, which I will try now.

-- 
Terry Jan Reedy



From barry at python.org  Mon Sep 28 16:32:04 2015
From: barry at python.org (Barry Warsaw)
Date: Mon, 28 Sep 2015 10:32:04 -0400
Subject: [Python-Dev] Washington DC Python sprint report
Message-ID: <20150928103204.3f4d5217@limelight.wooz.org>

Yesterday (27-Sep-2015), four Washington DC area Python developers got
together for a local Python hacking sprint.  Andrew, Eric, Jason, and I were
joined remotely by the esteemed R. David Murray.  We did stuff and had fun!
We hope to do stuff and have fun again!  If you want to join us for stuff and
fun next time, please get in touch.

Here's a write-up of the sprint:

https://gitlab.com/python-smtpd-hackers/aiosmtpd/wikis/2015-09-27-hackfest

Special thanks to the PSF and Brian Curtin for sponsoring the sprint.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150928/d1d274f2/attachment.sig>

From guido at python.org  Mon Sep 28 17:22:46 2015
From: guido at python.org (Guido van Rossum)
Date: Mon, 28 Sep 2015 08:22:46 -0700
Subject: [Python-Dev] Washington DC Python sprint report
In-Reply-To: <20150928103204.3f4d5217@limelight.wooz.org>
References: <20150928103204.3f4d5217@limelight.wooz.org>
Message-ID: <CAP7+vJ+Evp8ZidMut+wwMDtz3jfCypjipA1ZsK33M4j-ux6qGw@mail.gmail.com>

Cool! Glad to see that the idea of local core-dev sprints hasn't totally
been forgotten.

I saw that you had a need for an asyncio tutorial. I wonder if the "500
lines" chapter on asyncio would help? I didn't write it; I only write the
500 lines of code, A. Jesse Jiryu Davis wrote the text, and it's wonderful:
http://aosabook.org/en/500L/a-web-crawler-with-asyncio-coroutines.html

On Mon, Sep 28, 2015 at 7:32 AM, Barry Warsaw <barry at python.org> wrote:

> Yesterday (27-Sep-2015), four Washington DC area Python developers got
> together for a local Python hacking sprint.  Andrew, Eric, Jason, and I
> were
> joined remotely by the esteemed R. David Murray.  We did stuff and had fun!
> We hope to do stuff and have fun again!  If you want to join us for stuff
> and
> fun next time, please get in touch.
>
> Here's a write-up of the sprint:
>
> https://gitlab.com/python-smtpd-hackers/aiosmtpd/wikis/2015-09-27-hackfest
>
> Special thanks to the PSF and Brian Curtin for sponsoring the sprint.
>
> Cheers,
> -Barry
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150928/c643d8a3/attachment.html>

From brianhray at gmail.com  Mon Sep 28 18:14:04 2015
From: brianhray at gmail.com (Brian Ray)
Date: Mon, 28 Sep 2015 12:14:04 -0400
Subject: [Python-Dev] Washington DC Python sprint report
In-Reply-To: <CAP7+vJ+Evp8ZidMut+wwMDtz3jfCypjipA1ZsK33M4j-ux6qGw@mail.gmail.com>
References: <20150928103204.3f4d5217@limelight.wooz.org>
 <CAP7+vJ+Evp8ZidMut+wwMDtz3jfCypjipA1ZsK33M4j-ux6qGw@mail.gmail.com>
Message-ID: <CANKg38uM8FQrjCrN7M4mLYBLzGG-qKDfhXvj5p5umFi7Kh0b_Q@mail.gmail.com>

I would like to propose a mixed core-dev none-core-dev sprint to occur in
Chicago within the next couple months. ChiPy (http://chipy.org) can help
sponsor. I am going to share my thoughts on this with the group-organizers <
group-organizers at python.org> list first in order to get some feedback. Post
found here:
https://mail.python.org/pipermail/group-organizers/2015-September/000441.htm


Regards,

Brian Ray
ChiPy organizer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150928/b61a6806/attachment.html>

From brianhray at gmail.com  Mon Sep 28 18:15:06 2015
From: brianhray at gmail.com (Brian Ray)
Date: Mon, 28 Sep 2015 12:15:06 -0400
Subject: [Python-Dev] Washington DC Python sprint report
In-Reply-To: <CANKg38uM8FQrjCrN7M4mLYBLzGG-qKDfhXvj5p5umFi7Kh0b_Q@mail.gmail.com>
References: <20150928103204.3f4d5217@limelight.wooz.org>
 <CAP7+vJ+Evp8ZidMut+wwMDtz3jfCypjipA1ZsK33M4j-ux6qGw@mail.gmail.com>
 <CANKg38uM8FQrjCrN7M4mLYBLzGG-qKDfhXvj5p5umFi7Kh0b_Q@mail.gmail.com>
Message-ID: <CANKg38uDGtyUhgShuWdNCrc=E=BqsuEcvS9wLe62McH5zc7U4w@mail.gmail.com>

meant:
https://mail.python.org/pipermail/group-organizers/2015-September/000441.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150928/e609813c/attachment.html>

From alexander.belopolsky at gmail.com  Mon Sep 28 19:12:01 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 28 Sep 2015 13:12:01 -0400
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <muass9$pu8$1@ger.gmane.org>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
 <20150928011254.09D7125104A@webabinitio.net>
 <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>
 <muacr2$jb3$1@ger.gmane.org>
 <CA+eR4cFPNf=ahdj4K4H2aaP8w2QC60c1=PUYCR3dbEVTMrsxwQ@mail.gmail.com>
 <muass9$pu8$1@ger.gmane.org>
Message-ID: <CAP7h-xazpGw2AMuXvhZXx93ybJyMoQZk9BVuAUYBaDVGwzxnmQ@mail.gmail.com>

On Mon, Sep 28, 2015 at 4:13 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> Normal one specified in devguide: commit 3.4, merge 3.5, merge 3.6,


That's exactly what I did at fist, but apparently while I was doing this,
another commit was pushed to all three branches.   To recover, I did a
series of hg update 3.x; hg merge dances fighting with Misc/NEWS on every
turn.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150928/be34070f/attachment.html>

From brett at python.org  Mon Sep 28 19:23:44 2015
From: brett at python.org (Brett Cannon)
Date: Mon, 28 Sep 2015 17:23:44 +0000
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <CAP7h-xazpGw2AMuXvhZXx93ybJyMoQZk9BVuAUYBaDVGwzxnmQ@mail.gmail.com>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
 <20150928011254.09D7125104A@webabinitio.net>
 <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>
 <muacr2$jb3$1@ger.gmane.org>
 <CA+eR4cFPNf=ahdj4K4H2aaP8w2QC60c1=PUYCR3dbEVTMrsxwQ@mail.gmail.com>
 <muass9$pu8$1@ger.gmane.org>
 <CAP7h-xazpGw2AMuXvhZXx93ybJyMoQZk9BVuAUYBaDVGwzxnmQ@mail.gmail.com>
Message-ID: <CAP1=2W49Gb-x+bxbTDidQ_=ToHwfNuSMMV4YuAtKtc73F2d_ew@mail.gmail.com>

See http://bugs.python.org/issue18967 if you want to join the discussion on
how to solve Misc/NEWS potentially in the short term (long term we have a
plan once someone has time to hack on the issue tracker).

On Mon, 28 Sep 2015 at 10:12 Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

>
> On Mon, Sep 28, 2015 at 4:13 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>
>> Normal one specified in devguide: commit 3.4, merge 3.5, merge 3.6,
>
>
> That's exactly what I did at fist, but apparently while I was doing this,
> another commit was pushed to all three branches.   To recover, I did a
> series of hg update 3.x; hg merge dances fighting with Misc/NEWS on every
> turn.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150928/8ce33be1/attachment.html>

From erik.m.bray at gmail.com  Mon Sep 28 20:00:09 2015
From: erik.m.bray at gmail.com (Erik Bray)
Date: Mon, 28 Sep 2015 14:00:09 -0400
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <4655937719415280861@unknownmsgid>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
Message-ID: <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>

On Fri, Sep 25, 2015 at 6:27 PM, Chris Barker - NOAA Federal
<chris.barker at noaa.gov> wrote:
>
> You can use "Windows SDK for Windows 7 and .NET Framework 4".
>
> http://www.microsoft.com/en-us/download/details.aspx?id=8279
>
>
> Thanks. Last time I tried that route, it was for 64 bit py2.7. And it
> required some kludging of environment variables, and registry acces I don't
> have permission for.
>
> But it still may be the best bet. I'll give it a try when I have a chance.
>
> And this should be in the "official" docs...

For what it's worth, I've had good luck compiling *most* extension
modules on Windows using the gcc from MinGW-w64.

The big notable exception was that last time I tried compiling Numpy
with it I got a segfaulting Numpy.  But I never had a chance to
investigate why or if it's fixable.  My own extension modules work
fine on Windows when compiled in MinGW though.

Erik B.


> On Sat, Sep 26, 2015 at 12:24 AM, Chris Barker - NOAA Federal
> <chris.barker at noaa.gov> wrote:
>>
>> As I understand it, the MS VS2010 compiler is required (or at least
>> best practice) for compiling Python extensions for the python.org
>> Windows builds of py 3.4 and ?[1]
>>
>> However, MS now makes it very hard (impossible?) to download VS2010
>> Express ( or Community, or whatever the free as in beer version is
>> called).
>>
>> I realize that this is not python-dev's responsibility, but if there
>> is any way to either document where it can be found, or put a bit of
>> pressure on MS to make it available, as they have for VS2008 and
>> py2.7, that would be great.
>>
>> Sorry to bug this list, I didn't know where else to reach out to.
>>
>> -Chris
>>
>> [1] it's actually prefer hard to find out which compiler version is
>> used for which python version. And has been for years. Would a patch
>> to the docs, probably here:
>>
>> https://docs.python.org/3.4/using/windows.html#compiling-python-on-windows
>>
>> Be considered?
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>
>
>
>
> --
> INADA Naoki  <songofacandy at gmail.com>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/erik.m.bray%40gmail.com
>

From python at mrabarnett.plus.com  Mon Sep 28 22:18:24 2015
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 28 Sep 2015 21:18:24 +0100
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
Message-ID: <5609A090.7050003@mrabarnett.plus.com>

On 2015-09-28 19:00, Erik Bray wrote:
> On Fri, Sep 25, 2015 at 6:27 PM, Chris Barker - NOAA Federal
> <chris.barker at noaa.gov> wrote:
>>
>> You can use "Windows SDK for Windows 7 and .NET Framework 4".
>>
>> http://www.microsoft.com/en-us/download/details.aspx?id=8279
>>
>>
>> Thanks. Last time I tried that route, it was for 64 bit py2.7. And it
>> required some kludging of environment variables, and registry acces I don't
>> have permission for.
>>
>> But it still may be the best bet. I'll give it a try when I have a chance.
>>
>> And this should be in the "official" docs...
>
> For what it's worth, I've had good luck compiling *most* extension
> modules on Windows using the gcc from MinGW-w64.
>
> The big notable exception was that last time I tried compiling Numpy
> with it I got a segfaulting Numpy.  But I never had a chance to
> investigate why or if it's fixable.  My own extension modules work
> fine on Windows when compiled in MinGW though.
>
> Erik B.
>
Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5,
both 32-bit and 64-bit, using MinGW-w64, and I haven't had a problem yet
that wasn't due to a bug in the source code.
>
>> On Sat, Sep 26, 2015 at 12:24 AM, Chris Barker - NOAA Federal
>> <chris.barker at noaa.gov> wrote:
>>>
>>> As I understand it, the MS VS2010 compiler is required (or at least
>>> best practice) for compiling Python extensions for the python.org
>>> Windows builds of py 3.4 and ?[1]
>>>
>>> However, MS now makes it very hard (impossible?) to download VS2010
>>> Express ( or Community, or whatever the free as in beer version is
>>> called).
>>>
>>> I realize that this is not python-dev's responsibility, but if there
>>> is any way to either document where it can be found, or put a bit of
>>> pressure on MS to make it available, as they have for VS2008 and
>>> py2.7, that would be great.
>>>
>>> Sorry to bug this list, I didn't know where else to reach out to.
>>>
>>> -Chris
>>>
>>> [1] it's actually prefer hard to find out which compiler version is
>>> used for which python version. And has been for years. Would a patch
>>> to the docs, probably here:
>>>
>>> https://docs.python.org/3.4/using/windows.html#compiling-python-on-windows
>>>
>>> Be considered?
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>>
>>
>>
>>
>> --
>> INADA Naoki  <songofacandy at gmail.com>
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/erik.m.bray%40gmail.com
>>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/python%40mrabarnett.plus.com
>
>


From p.f.moore at gmail.com  Mon Sep 28 22:38:18 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 28 Sep 2015 21:38:18 +0100
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <5609A090.7050003@mrabarnett.plus.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
Message-ID: <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>

On 28 September 2015 at 21:18, MRAB <python at mrabarnett.plus.com> wrote:
> Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5,
> both 32-bit and 64-bit, using MinGW-w64, and I haven't had a problem yet
> that wasn't due to a bug in the source code.

Interesting. With Python 3.5, what CRT does the module use? With
Python 3.4 and earlier, distutils arranged for mingw builds to link to
the CRT that matched the CPython build, but I don't think that
happened for 3.5 (because mingw doesn't support ucrt yet). So you'd
have a CRT that doesn't match the core. Obviously this isn't causing
you issues, but I'm not sure if it could (CRT problems seem to be
mostly about "might cause issues" type problems...)

Paul

From python at mrabarnett.plus.com  Mon Sep 28 22:53:17 2015
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 28 Sep 2015 21:53:17 +0100
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
 <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
Message-ID: <5609A8BD.3060008@mrabarnett.plus.com>

On 2015-09-28 21:38, Paul Moore wrote:
> On 28 September 2015 at 21:18, MRAB <python at mrabarnett.plus.com> wrote:
> > Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5,
> > both 32-bit and 64-bit, using MinGW-w64, and I haven't had a problem yet
> > that wasn't due to a bug in the source code.
>
> Interesting. With Python 3.5, what CRT does the module use? With
> Python 3.4 and earlier, distutils arranged for mingw builds to link to
> the CRT that matched the CPython build, but I don't think that
> happened for 3.5 (because mingw doesn't support ucrt yet). So you'd
> have a CRT that doesn't match the core. Obviously this isn't causing
> you issues, but I'm not sure if it could (CRT problems seem to be
> mostly about "might cause issues" type problems...)
>
I can't remember the details off-hand, but here's the issue:

http://bugs.python.org/issue24385


From barry at python.org  Mon Sep 28 23:15:20 2015
From: barry at python.org (Barry Warsaw)
Date: Mon, 28 Sep 2015 17:15:20 -0400
Subject: [Python-Dev] Washington DC Python sprint report
In-Reply-To: <CAP7+vJ+Evp8ZidMut+wwMDtz3jfCypjipA1ZsK33M4j-ux6qGw@mail.gmail.com>
References: <20150928103204.3f4d5217@limelight.wooz.org>
 <CAP7+vJ+Evp8ZidMut+wwMDtz3jfCypjipA1ZsK33M4j-ux6qGw@mail.gmail.com>
Message-ID: <20150928171520.1803631a@anarchist.wooz.org>

On Sep 28, 2015, at 08:22 AM, Guido van Rossum wrote:

>I saw that you had a need for an asyncio tutorial. I wonder if the "500
>lines" chapter on asyncio would help? I didn't write it; I only write the
>500 lines of code, A. Jesse Jiryu Davis wrote the text, and it's wonderful:
>http://aosabook.org/en/500L/a-web-crawler-with-asyncio-coroutines.html

It's a great article, and I particularly like how it starts from first
principles and builds essentially the asyncio framework up from them, with
nice explorations on how things like generators work.

But it's not quite what I'm looking for.  When I go to the stdlib asyncio docs
page, I'm immediately thrown into (albeit good) reference documentation.  I
though that the page "Develop with asyncio" might give me what I want, but
it's really not.

What I'm looking for is a gentle introduction, assuming that the reader either
understands the basics of asynchronous i/o or maybe comes from a background in
threaded programming.  It would then explain things like "this is a Future and
this is what you use it for", "this is a Task and this is when you use a Task
and when you use a Future", "this is when you want to define a Protocol, and
this is how it hooks into the framework".  I think that kind of high-level
overview of the classes and how they hang together is what I think is missing.

Take for example 18.5.3 Tasks and coroutines.  Aside from the fact that the
title would imply it would start explaining Tasks, it actually doesn't get to
them until way later on the page!

What's a Future?  The first thing the asyncio page says is that the "class is
almost compatible with concurrent.futures.Future".  Okay, but that still
doesn't tell me what it *is* or what it's used for.  Following the link to
that other class isn't really enlightening. ;)

I hope my comments make sense.  I know that when you already understand the
concepts, it's difficult to distill them into the right documentation for very
different audiences.  What's there seems mostly great for reference, and maybe
the stdlib docs aren't the right place for what I want, but as the 500 Lines
chapter promotes, asyncio is pretty powerful so it would be nice to have
Python documentation for newcomers.

I'm sure I'm not the right person to write it though. ;)

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150928/0b026195/attachment-0001.sig>

From njs at pobox.com  Mon Sep 28 23:18:48 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 28 Sep 2015 14:18:48 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
 <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
Message-ID: <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>

On Sep 28, 2015 1:39 PM, "Paul Moore" <p.f.moore at gmail.com> wrote:
>
> On 28 September 2015 at 21:18, MRAB <python at mrabarnett.plus.com> wrote:
> > Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5,
> > both 32-bit and 64-bit, using MinGW-w64, and I haven't had a problem yet
> > that wasn't due to a bug in the source code.
>
> Interesting. With Python 3.5, what CRT does the module use? With
> Python 3.4 and earlier, distutils arranged for mingw builds to link to
> the CRT that matched the CPython build,

This doesn't sound right to me. Maybe if you're talking about the original
mingw, but that's been abandoned upstream for years. Nowadays everyone uses
the mingw-w64 fork, for both 32 and 64 bits. And in mingw-w64, the only way
to select a non-default CRT is to hack up the toolchain's source tree and
cross your fingers. It's definitely not a supported configuration upstream.
(Source: we've been talking to mingw-w64 upstream and MS about how to
potentially make building free software less painful on Windows.)

> but I don't think that
> happened for 3.5 (because mingw doesn't support ucrt yet). So you'd
> have a CRT that doesn't match the core. Obviously this isn't causing
> you issues, but I'm not sure if it could (CRT problems seem to be
> mostly about "might cause issues" type problems...)

CRT issues are indeed tricky, because they only bite in certain
circumstances -- so long as you never pass a FILE* or a fileno across the
dll boundary, or call malloc in one module and free in the other, or ...
then it works fine. Except when it doesn't :-).

Example of a subtle issue: msvc and mingw-w64 disagree about whether the
x87 fpu should be configured in extended precision mode or not. So simply
loading a mingw-w64-compiled dll can potentially cause math functions in
other dlls to start returning incorrect results. Or maybe not -- it depends
on the details of how MS implemented things, and we can't exactly check. Or
whether you get correct math result in mingw-w64 compiled code can depend
on which runtime was used to spawn the thread that's running the code (!!).
And even if things work today, it could change without warning in any
update, because no one is testing this configuration upstream.

It's totally plausible that the regex module happens to avoid all these
issues. But you can't assume that it's a general solution.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150928/57d85a10/attachment.html>

From guido at python.org  Mon Sep 28 23:38:10 2015
From: guido at python.org (Guido van Rossum)
Date: Mon, 28 Sep 2015 14:38:10 -0700
Subject: [Python-Dev] Washington DC Python sprint report
In-Reply-To: <20150928171520.1803631a@anarchist.wooz.org>
References: <20150928103204.3f4d5217@limelight.wooz.org>
 <CAP7+vJ+Evp8ZidMut+wwMDtz3jfCypjipA1ZsK33M4j-ux6qGw@mail.gmail.com>
 <20150928171520.1803631a@anarchist.wooz.org>
Message-ID: <CAP7+vJK5vjQz2NOfL_CUPXAj-VSVdZNoLs+zKm=Lx_6JObaYAw@mail.gmail.com>

Your comments make total sense -- we're just short on people who can write
that kind of docs. :-(

On Mon, Sep 28, 2015 at 2:15 PM, Barry Warsaw <barry at python.org> wrote:

> On Sep 28, 2015, at 08:22 AM, Guido van Rossum wrote:
>
> >I saw that you had a need for an asyncio tutorial. I wonder if the "500
> >lines" chapter on asyncio would help? I didn't write it; I only write the
> >500 lines of code, A. Jesse Jiryu Davis wrote the text, and it's
> wonderful:
> >http://aosabook.org/en/500L/a-web-crawler-with-asyncio-coroutines.html
>
> It's a great article, and I particularly like how it starts from first
> principles and builds essentially the asyncio framework up from them, with
> nice explorations on how things like generators work.
>
> But it's not quite what I'm looking for.  When I go to the stdlib asyncio
> docs
> page, I'm immediately thrown into (albeit good) reference documentation.  I
> though that the page "Develop with asyncio" might give me what I want, but
> it's really not.
>
> What I'm looking for is a gentle introduction, assuming that the reader
> either
> understands the basics of asynchronous i/o or maybe comes from a
> background in
> threaded programming.  It would then explain things like "this is a Future
> and
> this is what you use it for", "this is a Task and this is when you use a
> Task
> and when you use a Future", "this is when you want to define a Protocol,
> and
> this is how it hooks into the framework".  I think that kind of high-level
> overview of the classes and how they hang together is what I think is
> missing.
>
> Take for example 18.5.3 Tasks and coroutines.  Aside from the fact that the
> title would imply it would start explaining Tasks, it actually doesn't get
> to
> them until way later on the page!
>
> What's a Future?  The first thing the asyncio page says is that the "class
> is
> almost compatible with concurrent.futures.Future".  Okay, but that still
> doesn't tell me what it *is* or what it's used for.  Following the link to
> that other class isn't really enlightening. ;)
>
> I hope my comments make sense.  I know that when you already understand the
> concepts, it's difficult to distill them into the right documentation for
> very
> different audiences.  What's there seems mostly great for reference, and
> maybe
> the stdlib docs aren't the right place for what I want, but as the 500
> Lines
> chapter promotes, asyncio is pretty powerful so it would be nice to have
> Python documentation for newcomers.
>
> I'm sure I'm not the right person to write it though. ;)
>
> Cheers,
> -Barry
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150928/1afc0b0d/attachment.html>

From p.f.moore at gmail.com  Mon Sep 28 23:55:48 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 28 Sep 2015 22:55:48 +0100
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
 <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
 <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>
Message-ID: <CACac1F91R_BaaM6VY1FHhfMN0ZDhwWCxwWF2P1r0neNPvHKJrQ@mail.gmail.com>

On 28 September 2015 at 22:18, Nathaniel Smith <njs at pobox.com> wrote:
> On Sep 28, 2015 1:39 PM, "Paul Moore" <p.f.moore at gmail.com> wrote:
>>
>> On 28 September 2015 at 21:18, MRAB <python at mrabarnett.plus.com> wrote:
>> > Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5,
>> > both 32-bit and 64-bit, using MinGW-w64, and I haven't had a problem yet
>> > that wasn't due to a bug in the source code.
>>
>> Interesting. With Python 3.5, what CRT does the module use? With
>> Python 3.4 and earlier, distutils arranged for mingw builds to link to
>> the CRT that matched the CPython build,
>
> This doesn't sound right to me. Maybe if you're talking about the original
> mingw, but that's been abandoned upstream for years. Nowadays everyone uses
> the mingw-w64 fork, for both 32 and 64 bits. And in mingw-w64, the only way
> to select a non-default CRT is to hack up the toolchain's source tree and
> cross your fingers. It's definitely not a supported configuration upstream.
> (Source: we've been talking to mingw-w64 upstream and MS about how to
> potentially make building free software less painful on Windows.)

Interesting, it's been a long time since I've done work on the mingw
support, so I hadn't realised this had happened.

I guess that means that nowadays all mingw-compiled extensions link to
msvcrt (I assume that's still the CRT that mingw-w64 uses by default)?

>> but I don't think that
>> happened for 3.5 (because mingw doesn't support ucrt yet). So you'd
>> have a CRT that doesn't match the core. Obviously this isn't causing
>> you issues, but I'm not sure if it could (CRT problems seem to be
>> mostly about "might cause issues" type problems...)
>
> CRT issues are indeed tricky, because they only bite in certain
> circumstances -- so long as you never pass a FILE* or a fileno across the
> dll boundary, or call malloc in one module and free in the other, or ...
> then it works fine. Except when it doesn't :-).
>
> Example of a subtle issue: msvc and mingw-w64 disagree about whether the x87
> fpu should be configured in extended precision mode or not. So simply
> loading a mingw-w64-compiled dll can potentially cause math functions in
> other dlls to start returning incorrect results. Or maybe not -- it depends
> on the details of how MS implemented things, and we can't exactly check. Or
> whether you get correct math result in mingw-w64 compiled code can depend on
> which runtime was used to spawn the thread that's running the code (!!). And
> even if things work today, it could change without warning in any update,
> because no one is testing this configuration upstream.
>
> It's totally plausible that the regex module happens to avoid all these
> issues. But you can't assume that it's a general solution.

Agreed. That was essentially what I was asking - has someone found a
solution to the issue of avoiding mixed CRTs when using mingw as a
compiler (or at least, found a better solution than using the original
mingw -lmsvcr100 approach combined with the distutils code that
supports this). Looks like the answer is that nobody has. But it's
certainly (still) true that for straightforward cases things seem
pretty much OK, especially if you avoid the "obvious" issues. (The
non-obvious ones sound terrifying, and I'm glad I don't have to write
code that encounters those!!!)

Cheers,
Paul

From barry at python.org  Mon Sep 28 23:57:56 2015
From: barry at python.org (Barry Warsaw)
Date: Mon, 28 Sep 2015 17:57:56 -0400
Subject: [Python-Dev] Washington DC Python sprint report
In-Reply-To: <CAP7+vJK5vjQz2NOfL_CUPXAj-VSVdZNoLs+zKm=Lx_6JObaYAw@mail.gmail.com>
References: <20150928103204.3f4d5217@limelight.wooz.org>
 <CAP7+vJ+Evp8ZidMut+wwMDtz3jfCypjipA1ZsK33M4j-ux6qGw@mail.gmail.com>
 <20150928171520.1803631a@anarchist.wooz.org>
 <CAP7+vJK5vjQz2NOfL_CUPXAj-VSVdZNoLs+zKm=Lx_6JObaYAw@mail.gmail.com>
Message-ID: <20150928175756.291622b9@anarchist.wooz.org>

On Sep 28, 2015, at 02:38 PM, Guido van Rossum wrote:

>Your comments make total sense -- we're just short on people who can write
>that kind of docs. :-(

Oh well, maybe someday we will! ;)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150928/8b45a425/attachment.sig>

From tjreedy at udel.edu  Tue Sep 29 00:31:33 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 28 Sep 2015 18:31:33 -0400
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <CAP7h-xazpGw2AMuXvhZXx93ybJyMoQZk9BVuAUYBaDVGwzxnmQ@mail.gmail.com>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
 <20150928011254.09D7125104A@webabinitio.net>
 <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>
 <muacr2$jb3$1@ger.gmane.org>
 <CA+eR4cFPNf=ahdj4K4H2aaP8w2QC60c1=PUYCR3dbEVTMrsxwQ@mail.gmail.com>
 <muass9$pu8$1@ger.gmane.org>
 <CAP7h-xazpGw2AMuXvhZXx93ybJyMoQZk9BVuAUYBaDVGwzxnmQ@mail.gmail.com>
Message-ID: <mucf47$us4$1@ger.gmane.org>

On 9/28/2015 1:12 PM, Alexander Belopolsky wrote:
>
> On Mon, Sep 28, 2015 at 4:13 AM, Terry Reedy <tjreedy at udel.edu
> <mailto:tjreedy at udel.edu>> wrote:
>
>     Normal one specified in devguide: commit 3.4, merge 3.5, merge 3.6,
>
>
> That's exactly what I did at fist, but apparently while I was doing
> this, another commit was pushed to all three branches.

You lost a push race.  To minimize to possibility of that, I get 
everything ready so that I can commit and merge with under 15 (or 20) 
mouse clicks, without editing anything, after a final pull that does not 
pull anything.  (Sunday, I left out the 'clean repository' check and the 
the final 'nothing found' pull.  I have a .bat file to pull into default 
and update all 4 working directory branches.)  With everything set up, I 
can commit to 2.7 and 3.4 and merge into 3.5 and 3.6 in under a minute. 
  This means having no merge conflicts or having them 'pre-resolved' -- 
see below.

> To recover, I did a series of hg update 3.x; hg merge dances
 > fighting with Misc/NEWS on every turn.

Hg almost never merges Idle news items correctly, even when there is no 
real conflict, and even when it says there was no conflict.  In the 
latter case, it may have merged in the wrong place, such as putting a 
things into the 3.5.1 section of 3.6 NEWS, which should not be there. 
So I assume that NEWS merges will always be wrong.  After what I hope 
will be the next to last pull, when everything else is done, I open 2.7, 
3.4, 3.5, and 3.6 NEWS on separate tabs (of Notepad++), edit 2.7 and 
save, copy-paste to 3.4 news and save, then copy-paste into 3.5 and 3.6 
WITHOUT saving.  After merging into 3.5, before commiting, I revert NEWS 
to local, switch to Notepad++, being sure to click [No] File changed, 
reload?, save the correct 3.5 NEWS, mark resolved, and commit.  Ditto 
for 3.6.  (I do this in batches, when no one else seems active.)

-- 
Terry Jan Reedy


From vadmium+py at gmail.com  Tue Sep 29 01:05:29 2015
From: vadmium+py at gmail.com (Martin Panter)
Date: Mon, 28 Sep 2015 23:05:29 +0000
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <mucf47$us4$1@ger.gmane.org>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
 <20150928011254.09D7125104A@webabinitio.net>
 <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>
 <muacr2$jb3$1@ger.gmane.org>
 <CA+eR4cFPNf=ahdj4K4H2aaP8w2QC60c1=PUYCR3dbEVTMrsxwQ@mail.gmail.com>
 <muass9$pu8$1@ger.gmane.org>
 <CAP7h-xazpGw2AMuXvhZXx93ybJyMoQZk9BVuAUYBaDVGwzxnmQ@mail.gmail.com>
 <mucf47$us4$1@ger.gmane.org>
Message-ID: <CA+eR4cGnoCuc8-wNexJQ=hQKksoeTOPnN7CodYyMxTYhCJ9exA@mail.gmail.com>

On 28 September 2015 at 22:31, Terry Reedy <tjreedy at udel.edu> wrote:
> . . . it may have merged in the wrong place, such as putting a things into the
> 3.5.1 section of 3.6 NEWS, which should not be there.

Since you mentioned this and I also noticed this, can I ask why the
3.5.1 section is there, if it isn?t meant to be? There are also other
sections, going back to 3.4.0. They have been there for a while. Is it
just that nobody removed it when it was inherited from 3.5 and 3.4?
When I have merged bug fixes into the default 3.6 branch I have
sometimes let the NEWS entries be automatically be merged into the
3.5.1 section, without updating the 3.6.0 section, after I noticed
other people doing this.

Perhaps we should get rid of the old pre-3.6 sections (perhaps after
adding any missing entries to the 3.6 section)? Otherwise I imagine
some release manager might come along and chop them all out without
adding anything to the 3.6 section.

From guido at python.org  Tue Sep 29 01:30:54 2015
From: guido at python.org (Guido van Rossum)
Date: Mon, 28 Sep 2015 16:30:54 -0700
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <CA+eR4cGnoCuc8-wNexJQ=hQKksoeTOPnN7CodYyMxTYhCJ9exA@mail.gmail.com>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
 <20150928011254.09D7125104A@webabinitio.net>
 <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>
 <muacr2$jb3$1@ger.gmane.org>
 <CA+eR4cFPNf=ahdj4K4H2aaP8w2QC60c1=PUYCR3dbEVTMrsxwQ@mail.gmail.com>
 <muass9$pu8$1@ger.gmane.org>
 <CAP7h-xazpGw2AMuXvhZXx93ybJyMoQZk9BVuAUYBaDVGwzxnmQ@mail.gmail.com>
 <mucf47$us4$1@ger.gmane.org>
 <CA+eR4cGnoCuc8-wNexJQ=hQKksoeTOPnN7CodYyMxTYhCJ9exA@mail.gmail.com>
Message-ID: <CAP7+vJJGhne-Y9Z_awQ-eWsCFfKdCVSEjYGr8y9G=CUjgzteQw@mail.gmail.com>

It used to be tradition to keep old news sections. Looks like the last time
we cleared it out was for 3.4.0.

But it's suspicious there's no section for 3.6 at all. Unless... 3.6 has
nothing new yet, it's all just bugfixes ported from 3.5?

On Mon, Sep 28, 2015 at 4:05 PM, Martin Panter <vadmium+py at gmail.com> wrote:

> On 28 September 2015 at 22:31, Terry Reedy <tjreedy at udel.edu> wrote:
> > . . . it may have merged in the wrong place, such as putting a things
> into the
> > 3.5.1 section of 3.6 NEWS, which should not be there.
>
> Since you mentioned this and I also noticed this, can I ask why the
> 3.5.1 section is there, if it isn?t meant to be? There are also other
> sections, going back to 3.4.0. They have been there for a while. Is it
> just that nobody removed it when it was inherited from 3.5 and 3.4?
> When I have merged bug fixes into the default 3.6 branch I have
> sometimes let the NEWS entries be automatically be merged into the
> 3.5.1 section, without updating the 3.6.0 section, after I noticed
> other people doing this.
>
> Perhaps we should get rid of the old pre-3.6 sections (perhaps after
> adding any missing entries to the 3.6 section)? Otherwise I imagine
> some release manager might come along and chop them all out without
> adding anything to the 3.6 section.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150928/fa09e5ec/attachment.html>

From eric at trueblade.com  Tue Sep 29 01:46:13 2015
From: eric at trueblade.com (Eric V. Smith)
Date: Mon, 28 Sep 2015 19:46:13 -0400
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <CAP7+vJJGhne-Y9Z_awQ-eWsCFfKdCVSEjYGr8y9G=CUjgzteQw@mail.gmail.com>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
 <20150928011254.09D7125104A@webabinitio.net>
 <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>
 <muacr2$jb3$1@ger.gmane.org>
 <CA+eR4cFPNf=ahdj4K4H2aaP8w2QC60c1=PUYCR3dbEVTMrsxwQ@mail.gmail.com>
 <muass9$pu8$1@ger.gmane.org>
 <CAP7h-xazpGw2AMuXvhZXx93ybJyMoQZk9BVuAUYBaDVGwzxnmQ@mail.gmail.com>
 <mucf47$us4$1@ger.gmane.org>
 <CA+eR4cGnoCuc8-wNexJQ=hQKksoeTOPnN7CodYyMxTYhCJ9exA@mail.gmail.com>
 <CAP7+vJJGhne-Y9Z_awQ-eWsCFfKdCVSEjYGr8y9G=CUjgzteQw@mail.gmail.com>
Message-ID: <5609D145.1080208@trueblade.com>

At the top of the file in the default branch, I see:

What's New in Python 3.6.0 alpha 1?

Which has a few things in it.

Eric.

On 9/28/2015 7:30 PM, Guido van Rossum wrote:
> It used to be tradition to keep old news sections. Looks like the last
> time we cleared it out was for 3.4.0.
> 
> But it's suspicious there's no section for 3.6 at all. Unless... 3.6 has
> nothing new yet, it's all just bugfixes ported from 3.5?
> 
> On Mon, Sep 28, 2015 at 4:05 PM, Martin Panter <vadmium+py at gmail.com
> <mailto:vadmium+py at gmail.com>> wrote:
> 
>     On 28 September 2015 at 22:31, Terry Reedy <tjreedy at udel.edu
>     <mailto:tjreedy at udel.edu>> wrote:
>     > . . . it may have merged in the wrong place, such as putting a
>     things into the
>     > 3.5.1 section of 3.6 NEWS, which should not be there.
> 
>     Since you mentioned this and I also noticed this, can I ask why the
>     3.5.1 section is there, if it isn?t meant to be? There are also other
>     sections, going back to 3.4.0. They have been there for a while. Is it
>     just that nobody removed it when it was inherited from 3.5 and 3.4?
>     When I have merged bug fixes into the default 3.6 branch I have
>     sometimes let the NEWS entries be automatically be merged into the
>     3.5.1 section, without updating the 3.6.0 section, after I noticed
>     other people doing this.
> 
>     Perhaps we should get rid of the old pre-3.6 sections (perhaps after
>     adding any missing entries to the 3.6 section)? Otherwise I imagine
>     some release manager might come along and chop them all out without
>     adding anything to the 3.6 section.
>     _______________________________________________
>     Python-Dev mailing list
>     Python-Dev at python.org <mailto:Python-Dev at python.org>
>     https://mail.python.org/mailman/listinfo/python-dev
>     Unsubscribe:
>     https://mail.python.org/mailman/options/python-dev/guido%40python.org
> 
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
> 

From njs at pobox.com  Tue Sep 29 01:52:35 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 28 Sep 2015 16:52:35 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CACac1F91R_BaaM6VY1FHhfMN0ZDhwWCxwWF2P1r0neNPvHKJrQ@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
 <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
 <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>
 <CACac1F91R_BaaM6VY1FHhfMN0ZDhwWCxwWF2P1r0neNPvHKJrQ@mail.gmail.com>
Message-ID: <CAPJVwBn71C6no6QKq9eqGmcMuiat0anFh23azyKH=-XY69kd=w@mail.gmail.com>

On Mon, Sep 28, 2015 at 2:55 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 28 September 2015 at 22:18, Nathaniel Smith <njs at pobox.com> wrote:
>> On Sep 28, 2015 1:39 PM, "Paul Moore" <p.f.moore at gmail.com> wrote:
>>>
>>> On 28 September 2015 at 21:18, MRAB <python at mrabarnett.plus.com> wrote:
>>> > Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5,
>>> > both 32-bit and 64-bit, using MinGW-w64, and I haven't had a problem yet
>>> > that wasn't due to a bug in the source code.
>>>
>>> Interesting. With Python 3.5, what CRT does the module use? With
>>> Python 3.4 and earlier, distutils arranged for mingw builds to link to
>>> the CRT that matched the CPython build,
>>
>> This doesn't sound right to me. Maybe if you're talking about the original
>> mingw, but that's been abandoned upstream for years. Nowadays everyone uses
>> the mingw-w64 fork, for both 32 and 64 bits. And in mingw-w64, the only way
>> to select a non-default CRT is to hack up the toolchain's source tree and
>> cross your fingers. It's definitely not a supported configuration upstream.
>> (Source: we've been talking to mingw-w64 upstream and MS about how to
>> potentially make building free software less painful on Windows.)
>
> Interesting, it's been a long time since I've done work on the mingw
> support, so I hadn't realised this had happened.
>
> I guess that means that nowadays all mingw-compiled extensions link to
> msvcrt (I assume that's still the CRT that mingw-w64 uses by default)?

Right, linking to msvcrt.dll is the only standard/supported
configuration for upstream mingw-w64.

>>> but I don't think that
>>> happened for 3.5 (because mingw doesn't support ucrt yet). So you'd
>>> have a CRT that doesn't match the core. Obviously this isn't causing
>>> you issues, but I'm not sure if it could (CRT problems seem to be
>>> mostly about "might cause issues" type problems...)
>>
>> CRT issues are indeed tricky, because they only bite in certain
>> circumstances -- so long as you never pass a FILE* or a fileno across the
>> dll boundary, or call malloc in one module and free in the other, or ...
>> then it works fine. Except when it doesn't :-).
>>
>> Example of a subtle issue: msvc and mingw-w64 disagree about whether the x87
>> fpu should be configured in extended precision mode or not. So simply
>> loading a mingw-w64-compiled dll can potentially cause math functions in
>> other dlls to start returning incorrect results. Or maybe not -- it depends
>> on the details of how MS implemented things, and we can't exactly check. Or
>> whether you get correct math result in mingw-w64 compiled code can depend on
>> which runtime was used to spawn the thread that's running the code (!!). And
>> even if things work today, it could change without warning in any update,
>> because no one is testing this configuration upstream.
>>
>> It's totally plausible that the regex module happens to avoid all these
>> issues. But you can't assume that it's a general solution.
>
> Agreed. That was essentially what I was asking - has someone found a
> solution to the issue of avoiding mixed CRTs when using mingw as a
> compiler (or at least, found a better solution than using the original
> mingw -lmsvcr100 approach combined with the distutils code that
> supports this). Looks like the answer is that nobody has. But it's
> certainly (still) true that for straightforward cases things seem
> pretty much OK, especially if you avoid the "obvious" issues. (The
> non-obvious ones sound terrifying, and I'm glad I don't have to write
> code that encounters those!!!)

It's not *quite* "nobody has". Carl Kleffner has been doing a lot of
work on trying to set up Python-compatible gcc-based toolchains for
Windows. (This is still pretty much the only hope for getting a usable
free fortran compiler on Windows, and there's still lots of fortran
down at the bottom of the scientific/numerical stack). It's still
rather beta and the approach probably isn't sustainable without more
funding, but right now it's probably the closest thing you can get to
what you're asking about. I believe these are the latest builds:

https://binstar.org/carlkl/mingwpy/files

(Yes, those are .whl files that contain compiler toolchains.)

(Also, if making this *actually* work reliably would make a difference
to anyone, then feel free to send me heartfelt testimonials and I'll
forward them on to MS. Or I guess you could just send them to Steve
Dower directly ;-).)

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

From breamoreboy at yahoo.co.uk  Tue Sep 29 02:14:39 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 29 Sep 2015 01:14:39 +0100
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CAPJVwBn71C6no6QKq9eqGmcMuiat0anFh23azyKH=-XY69kd=w@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
 <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
 <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>
 <CACac1F91R_BaaM6VY1FHhfMN0ZDhwWCxwWF2P1r0neNPvHKJrQ@mail.gmail.com>
 <CAPJVwBn71C6no6QKq9eqGmcMuiat0anFh23azyKH=-XY69kd=w@mail.gmail.com>
Message-ID: <mucl63$jtd$1@ger.gmane.org>

On 29/09/2015 00:52, Nathaniel Smith wrote:
> On Mon, Sep 28, 2015 at 2:55 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>> On 28 September 2015 at 22:18, Nathaniel Smith <njs at pobox.com> wrote:
>>> On Sep 28, 2015 1:39 PM, "Paul Moore" <p.f.moore at gmail.com> wrote:
>>>>
>>>> On 28 September 2015 at 21:18, MRAB <python at mrabarnett.plus.com> wrote:
>>>>> Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5,
>>>>> both 32-bit and 64-bit, using MinGW-w64, and I haven't had a problem yet
>>>>> that wasn't due to a bug in the source code.
>>>>
>>>> Interesting. With Python 3.5, what CRT does the module use? With
>>>> Python 3.4 and earlier, distutils arranged for mingw builds to link to
>>>> the CRT that matched the CPython build,
>>>
>>> This doesn't sound right to me. Maybe if you're talking about the original
>>> mingw, but that's been abandoned upstream for years. Nowadays everyone uses
>>> the mingw-w64 fork, for both 32 and 64 bits. And in mingw-w64, the only way
>>> to select a non-default CRT is to hack up the toolchain's source tree and
>>> cross your fingers. It's definitely not a supported configuration upstream.
>>> (Source: we've been talking to mingw-w64 upstream and MS about how to
>>> potentially make building free software less painful on Windows.)
>>
>> Interesting, it's been a long time since I've done work on the mingw
>> support, so I hadn't realised this had happened.
>>
>> I guess that means that nowadays all mingw-compiled extensions link to
>> msvcrt (I assume that's still the CRT that mingw-w64 uses by default)?
>
> Right, linking to msvcrt.dll is the only standard/supported
> configuration for upstream mingw-w64.
>
>>>> but I don't think that
>>>> happened for 3.5 (because mingw doesn't support ucrt yet). So you'd
>>>> have a CRT that doesn't match the core. Obviously this isn't causing
>>>> you issues, but I'm not sure if it could (CRT problems seem to be
>>>> mostly about "might cause issues" type problems...)
>>>
>>> CRT issues are indeed tricky, because they only bite in certain
>>> circumstances -- so long as you never pass a FILE* or a fileno across the
>>> dll boundary, or call malloc in one module and free in the other, or ...
>>> then it works fine. Except when it doesn't :-).
>>>
>>> Example of a subtle issue: msvc and mingw-w64 disagree about whether the x87
>>> fpu should be configured in extended precision mode or not. So simply
>>> loading a mingw-w64-compiled dll can potentially cause math functions in
>>> other dlls to start returning incorrect results. Or maybe not -- it depends
>>> on the details of how MS implemented things, and we can't exactly check. Or
>>> whether you get correct math result in mingw-w64 compiled code can depend on
>>> which runtime was used to spawn the thread that's running the code (!!). And
>>> even if things work today, it could change without warning in any update,
>>> because no one is testing this configuration upstream.
>>>
>>> It's totally plausible that the regex module happens to avoid all these
>>> issues. But you can't assume that it's a general solution.
>>
>> Agreed. That was essentially what I was asking - has someone found a
>> solution to the issue of avoiding mixed CRTs when using mingw as a
>> compiler (or at least, found a better solution than using the original
>> mingw -lmsvcr100 approach combined with the distutils code that
>> supports this). Looks like the answer is that nobody has. But it's
>> certainly (still) true that for straightforward cases things seem
>> pretty much OK, especially if you avoid the "obvious" issues. (The
>> non-obvious ones sound terrifying, and I'm glad I don't have to write
>> code that encounters those!!!)
>
> It's not *quite* "nobody has". Carl Kleffner has been doing a lot of
> work on trying to set up Python-compatible gcc-based toolchains for
> Windows. (This is still pretty much the only hope for getting a usable
> free fortran compiler on Windows, and there's still lots of fortran
> down at the bottom of the scientific/numerical stack). It's still
> rather beta and the approach probably isn't sustainable without more
> funding, but right now it's probably the closest thing you can get to
> what you're asking about. I believe these are the latest builds:
>
> https://binstar.org/carlkl/mingwpy/files
>
> (Yes, those are .whl files that contain compiler toolchains.)
>
> (Also, if making this *actually* work reliably would make a difference
> to anyone, then feel free to send me heartfelt testimonials and I'll
> forward them on to MS. Or I guess you could just send them to Steve
> Dower directly ;-).)
>
> -n
>

For anyone interested although this http://bugs.python.org/issue3871 
mingw issue is closed, it points to four other issues.  In total there 
are around 25 mingw issues open.  Maybe some of the work done on them 
can be tied up with the work that Carl Kleffner has done?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From tjreedy at udel.edu  Tue Sep 29 04:44:11 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 28 Sep 2015 22:44:11 -0400
Subject: [Python-Dev] Committing a bug fix
In-Reply-To: <CA+eR4cGnoCuc8-wNexJQ=hQKksoeTOPnN7CodYyMxTYhCJ9exA@mail.gmail.com>
References: <CAP7h-xYxyzghMwDHy_t0h08ii36-M50Ff5ugZtR3dFHuc1PyUQ@mail.gmail.com>
 <20150928011254.09D7125104A@webabinitio.net>
 <CAP7h-xa3oPbCREexsxxyCj7q70nUYCNKSoFhrDoSiqhmyM5FFA@mail.gmail.com>
 <muacr2$jb3$1@ger.gmane.org>
 <CA+eR4cFPNf=ahdj4K4H2aaP8w2QC60c1=PUYCR3dbEVTMrsxwQ@mail.gmail.com>
 <muass9$pu8$1@ger.gmane.org>
 <CAP7h-xazpGw2AMuXvhZXx93ybJyMoQZk9BVuAUYBaDVGwzxnmQ@mail.gmail.com>
 <mucf47$us4$1@ger.gmane.org>
 <CA+eR4cGnoCuc8-wNexJQ=hQKksoeTOPnN7CodYyMxTYhCJ9exA@mail.gmail.com>
Message-ID: <5609FAFB.9020802@udel.edu>

On 9/28/2015 7:05 PM, Martin Panter wrote:
> On 28 September 2015 at 22:31, Terry Reedy <tjreedy at udel.edu> wrote:
>> . . . it may have merged in the wrong place, such as putting a things into the
>> 3.5.1 section of 3.6 NEWS, which should not be there.
>
> Since you mentioned this and I also noticed this, can I ask why the
> 3.5.1 section is there, if it isn?t meant to be?

I believe it should not be there and that everything in there should be 
moved to the 3.6.0a1 section (if not already there).  (I already did 
that for IDLE.) Every commit* to a particular branch should be in the 
NEWS section for the next release of that branch.  The purpose of the 
M.N.Pa section is to record commits to the M.N branch that will appear 
in the M.N.Pa release. AFAIK, this has always been the policy until this 
bogus 3.5.1 section was added to 3.6 NEWS.

*Multiple commits for what is conceptually the one patch for one issue 
may get folded together into one NEWS entry, but that does not change 
the gist of the claim.

In 3.5 NEWS, the 3.5.0a1 section follows 3.4.0 (final).  There are no 
3.4.1 etc sections.  All the commits to 3.5 that appeared in 3.5.0a1, 
which branched off from 3.4 at the final release or a bit sooner, are in 
the 3.5.0a1 section.

 > There are also other sections, going back to 3.4.0.

There are from before the 3.6 branch was separated from 3.5 (or vice 
versa, if you prefer).  In other words, before there was a 3.6.0a1 to 
commit to.  Whether NEWS should be cumulative or not is a different issue.

> When I have merged bug fixes into the default 3.6 branch I have
> sometimes let the NEWS entries be automatically be merged into the
> 3.5.1 section, without updating the 3.6.0 section, after I noticed
> other people doing this.

If I am correct as to the intent of each section, this is a mistake. I 
always revert NEWS merges and then save the separately edited file for 
the branch, because hg routinely either creates a (incorrect) conflict 
(for Idle items)* or now, with the incorrect 3.5.1 section in 3.6 NEWS, 
puts things in that incorrect place.

*My guess is that this results from hg merge considering both context 
match and offset when picking the 'best' merge.  For items after the 
Library section, the offset of a correct merge can be 100s of lines.

--
Terry Jan Reedy



From njs at pobox.com  Tue Sep 29 04:54:56 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 28 Sep 2015 19:54:56 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <mucl63$jtd$1@ger.gmane.org>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
 <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
 <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>
 <CACac1F91R_BaaM6VY1FHhfMN0ZDhwWCxwWF2P1r0neNPvHKJrQ@mail.gmail.com>
 <CAPJVwBn71C6no6QKq9eqGmcMuiat0anFh23azyKH=-XY69kd=w@mail.gmail.com>
 <mucl63$jtd$1@ger.gmane.org>
Message-ID: <CAPJVwBmVBeaRXGMN0JREz8f+js4cLa90yHes4W_BsQvQRo2o6A@mail.gmail.com>

On Mon, Sep 28, 2015 at 5:14 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
>
> For anyone interested although this http://bugs.python.org/issue3871 mingw
> issue is closed, it points to four other issues.  In total there are around
> 25 mingw issues open.  Maybe some of the work done on them can be tied up
> with the work that Carl Kleffner has done?

There are two different topics here: building extensions with
mingw-w64, and building CPython itself with mingw-w64. That issue is
about the latter, and I think everyone is agreed at this point that
Python.org isn't going to support that so long as there are
incompatible CRT/ABIs between mingw-w64 and MSVC, because that creates
all kinds of problems (e.g. now you have to distinguish between wheels
targeting win32-using-msvc versus win32-using-mingw-w64). So the first
thing to solve is to get the mingw-w64 CRT/ABI incompatibilities
sorted out and extensions working, and then once that's solid we could
think about whether CPython upstream is interested in carrying
mingw-w64 build patches for CPython itself.

(It might not even be that interesting at that point... the main
reason for wanting mingw-w64-built CPython is so that it can
interoperate with the mingw-w64 ecosystem -- e.g. supporting Python
plugins in mingw-w64's gdb. If MSVC and mingw-w64 python become
compatible with each other, then this becomes much less urgent...)

The msys2 folks who are maintaining the CPython-on-mingw-w64 patch set
are definitely aware of Carl's work.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

From chris.barker at noaa.gov  Tue Sep 29 17:02:13 2015
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Tue, 29 Sep 2015 08:02:13 -0700
Subject: [Python-Dev] Washington DC Python sprint report
In-Reply-To: <20150928171520.1803631a@anarchist.wooz.org>
References: <20150928103204.3f4d5217@limelight.wooz.org>
 <CAP7+vJ+Evp8ZidMut+wwMDtz3jfCypjipA1ZsK33M4j-ux6qGw@mail.gmail.com>
 <20150928171520.1803631a@anarchist.wooz.org>
Message-ID: <1716556934870930572@unknownmsgid>

Sent from my iPhone

> On Sep 28, 2015, at 2:18 PM, Barry Warsaw <barry at python.org> wrote:
>
>> On Sep 28, 2015, at 08:22 AM, Guido van Rossum wrote:
>>
>> I saw that you had a need for an asyncio tutorial. I wonder if the "500
>> lines" chapter on asyncio would help? I didn't write it; I only write the
>> asyncio is pretty powerful so it would be nice to have
> Python documentation for newcomers.
>
> I'm sure I'm not the right person to write it though.

I think you'd be a great person to write those docs -- in partnership
with someone that really understands the guts.

The first step to docs is knowing what questions to answer, and in
what order to answer them. You've recently gone through the process of
trying to figure it out for a particular use case -- you know just
what questions you had.

And you even just posted the start of an outline.....

Whether that's what you want to do with your limited time is another question...

CHB



> Cheers,
> -Barry
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov

From chris.barker at noaa.gov  Tue Sep 29 17:20:47 2015
From: chris.barker at noaa.gov (Chris Barker)
Date: Tue, 29 Sep 2015 08:20:47 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
 <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
 <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>
Message-ID: <CALGmxEK2c7te2P08Wfm6-xz85qtd2h7k5odQn6enz-mvt050EA@mail.gmail.com>

 And in mingw-w64, the only way to select a non-default CRT
>
what is a "default" CRT in this case??

> CRT issues are indeed tricky, because they only bite in certain
> circumstances -- so long as you never pass a FILE* or a fileno across the
> dll boundary, or call malloc in one module and free in the other, or ...
>
Which happens to be EXACTLY what I'm needing to do right now....

then it works fine. Except when it doesn't :-).
>
yup -- a new developer on my team spent yesterday bangin his head agaist
this -- then asked "I'm compiling the lib with VS2013, the the python
extension with VS2008, could that be the problem? -- uh, yes?

The Python core developers made the decision a long time ago to use the MS
compilers for the "official" distributions -- as they are the "platform"
compilers. And as far as I know, everyone else has followed that path for
compatibility (Enthought Canopy, Anaconda, ActiveState) (except cygWin, but
that's not really the Windows platform, IFAIC). Given MS decision to both:
tie the compiler tightly to the run-time, AND make it hard to get old
versions of the compiler, that's turned out to be a pain. But I suspect
there have been real advantages over, for instance, building the whole
thing on MinGW.

But in any case, that's what we've got -- and it would be really nice  to
support teh community as best we can, as has been done fro Python2.7 with
updates to setuptools and the MS download of the old VS2008.

It sounds like we don't expect MS t help out in this case, but at least we
can better document what users need to do, and how to do it -- and NOT with
a "kludge together an open-source compiler and cross your fingers" approach.

OK -- I'm going to get off my soap box now -- time to actually suggest doc
patches....

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150929/026310b4/attachment.html>

From steve.dower at python.org  Tue Sep 29 18:17:55 2015
From: steve.dower at python.org (Steve Dower)
Date: Tue, 29 Sep 2015 09:17:55 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CALGmxEK2c7te2P08Wfm6-xz85qtd2h7k5odQn6enz-mvt050EA@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
 <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
 <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>
 <CALGmxEK2c7te2P08Wfm6-xz85qtd2h7k5odQn6enz-mvt050EA@mail.gmail.com>
Message-ID: <560AB9B3.3050408@python.org>

On 29Sep2015 0820, Chris Barker wrote:
> OK -- I'm going to get off my soap box now -- time to actually suggest
> doc patches....

Just bear in mind that you're suggesting patches for Python 3.3 and 3.4, 
which means that 3.4.4 is the only real chance to get them onto people's 
machines. http://docs.python.org/ already points to the 3.5 docs by 
default, which means only people who explicitly look for the earlier 
versions will see the changes.

You don't really have a huge audience, so I wouldn't invest large 
amounts of time in the official docs. A couple of well-publicised blog 
posts will reach more people.

Cheers,
Steve


From njs at vorpus.org  Tue Sep 29 19:30:13 2015
From: njs at vorpus.org (Nathaniel Smith)
Date: Tue, 29 Sep 2015 10:30:13 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CALGmxEK2c7te2P08Wfm6-xz85qtd2h7k5odQn6enz-mvt050EA@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
 <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
 <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>
 <CALGmxEK2c7te2P08Wfm6-xz85qtd2h7k5odQn6enz-mvt050EA@mail.gmail.com>
Message-ID: <CAPJVwB=ayYRcYORrTXOtNmMEFu=rXstPZHPa9tvbh_0av+2UVg@mail.gmail.com>

On Sep 29, 2015 8:22 AM, "Chris Barker" <chris.barker at noaa.gov> wrote:
>
>>  And in mingw-w64, the only way to select a non-default CRT
>
> what is a "default" CRT in this case??

To answer the question: mingw-w64's
standard/default/only-officially-supported CRT is msvcrt.dll (the version
that has no version number in the name). Wikipedia tells me that this is
the runtime used by msvc 4.2 - 6.0 (the later of which was released in
1998). The reason for this decision is that for whatever historical reason,
this particular CRT dll is shipped with Windows by default, and thus using
it avoids certain license issues that can otherwise arise, esp. with GPL
software. (Fortunately not an issue for python extensions, but since it is
an issue for other programs they just made the decision to support a single
configuration that works for everybody. Except when it doesn't ;-).)

In practice mingw-w64 ships its own runtime as a layer on top of msvcrt.dll
-- it gets used as a OS services layer, but mingw-w64 users aren't just
getting dropped directly into a wonderland of 15+ year old code.

(In fact, mingw-w64 upstream would like to make their runtime clever enough
to bind the underlying "OS services layer" at load time rather than compile
time, so that mingw-w64 compiled dll's would be "runtime agile" and could
be safely loaded into any process. The main thing we care about is just
that this would give upstream a way to officially support targeting newer
CRTs, but it would have a number of other benefits too: one modern
toolchain that could build extension modules for all versions of python,
the ability when combined with Python's "stable abi" to target 3.2+ with a
single binary distribution, better interoperability between python and
other windows ecosystems that went the mingw-w64 route like R... but, this
all requires funding someone to do the work.)

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150929/3f999adc/attachment.html>

From p.f.moore at gmail.com  Tue Sep 29 20:38:27 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 29 Sep 2015 19:38:27 +0100
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
Message-ID: <CACac1F8WE7V4yL1RxYWc+Z-bMNEWO03sdEycc2ERN6U=Zb_3Ug@mail.gmail.com>

On 25 September 2015 at 16:35, INADA Naoki <songofacandy at gmail.com> wrote:
> You can use "Windows SDK for Windows 7 and .NET Framework 4".
>
> http://www.microsoft.com/en-us/download/details.aspx?id=8279
>
> On Sat, Sep 26, 2015 at 12:24 AM, Chris Barker - NOAA Federal
> <chris.barker at noaa.gov> wrote:
>>
>> As I understand it, the MS VS2010 compiler is required (or at least
>> best practice) for compiling Python extensions for the python.org
>> Windows builds of py 3.4 and ?[1]
>>
>> However, MS now makes it very hard (impossible?) to download VS2010
>> Express ( or Community, or whatever the free as in beer version is
>> called).
>>
>> I realize that this is not python-dev's responsibility, but if there
>> is any way to either document where it can be found, or put a bit of
>> pressure on MS to make it available, as they have for VS2008 and
>> py2.7, that would be great.
>>
>> Sorry to bug this list, I didn't know where else to reach out to.

On 29 September 2015 at 16:20, Chris Barker <chris.barker at noaa.gov> wrote:
> It sounds like we don't expect MS t help out in this case, but at least we
> can better document what users need to do, and how to do it -- and NOT with
> a "kludge together an open-source compiler and cross your fingers" approach.

I'm not sure why INADA Naoki's answer above wasn't sufficient for you?
You need to have the SDK compilers on your PATH (by running the
relevant environment setting command) and you need to set the
environment variable DISTUTILS_USE_SDK=1 (this latter bit of
information is hard to find documented, admittedly, but pretty well
known).

That basically gives you a Visual Studio 2010 equivalent environment.
You'll still have all sorts of *other* problems building extensions on
Windows, but unless I'm missing something important in what you were
saying, getting a compiler isn't the issue.

Paul

From oscar.j.benjamin at gmail.com  Tue Sep 29 23:01:49 2015
From: oscar.j.benjamin at gmail.com (Oscar Benjamin)
Date: Tue, 29 Sep 2015 21:01:49 +0000
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <560AB9B3.3050408@python.org>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
 <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
 <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>
 <CALGmxEK2c7te2P08Wfm6-xz85qtd2h7k5odQn6enz-mvt050EA@mail.gmail.com>
 <560AB9B3.3050408@python.org>
Message-ID: <CAHVvXxRYsA8msL1eopKAfYt8EvV+wjNyAYFcR5TV4NdgEnfVZQ@mail.gmail.com>

On Tue, 29 Sep 2015 17:20 Steve Dower <steve.dower at python.org> wrote:

On 29Sep2015 0820, Chris Barker wrote:
> OK -- I'm going to get off my soap box now -- time to actually suggest
> doc patches....

Just bear in mind that you're suggesting patches for Python 3.3 and 3.4,
which means that 3.4.4 is the only real chance to get them onto people's
machines. http://docs.python.org/ already points to the 3.5 docs by
default, which means only people who explicitly look for the earlier
versions will see the changes.

You don't really have a huge audience, so I wouldn't invest large
amounts of time in the official docs. A couple of well-publicised blog
posts will reach more people.

Maybe but I think it would be good to have some documentation somewhere
(perhaps under the pypa banner) that can advise extension module authors
who want to provide Windows binaries for multiple CPython versions. It's
not obvious how to go about setting things up to make python.org compatible
binaries for say Python 2.7 and 3.2-3.5. Before 3.5 the simplest solution
was to use MinGW but that doesn't work for 3.5 (hence numpy are currently
uploading rcs without 3.5 binaries for Windows).

Just an explanation of what it takes in terms of MS compilers and which
free as in beer ones are available where would be helpful which could go in
a blog post as you say. IMO It would be more helpful though if it were a
continuously improved document that will be updated as new CPython releases
come out and the availability of MS compilers changes.

--
Oscar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150929/3ee701af/attachment.html>

From chris.barker at noaa.gov  Wed Sep 30 02:31:25 2015
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Tue, 29 Sep 2015 17:31:25 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CACac1F8WE7V4yL1RxYWc+Z-bMNEWO03sdEycc2ERN6U=Zb_3Ug@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <CACac1F8WE7V4yL1RxYWc+Z-bMNEWO03sdEycc2ERN6U=Zb_3Ug@mail.gmail.com>
Message-ID: <853517484730244188@unknownmsgid>

> I'm not sure why INADA Naoki's answer above wasn't sufficient for you?

It may be -- I've still have to test. Neither Windows nor py3 are my
primary production versions.

But the last time I tried the SDK approach was for py2.7 on Win64, and
it was both a pain, and impossible to set up to "just work" in my
highly secure environment.

So at best, it needs some serious documentation. And no, it shouldn't
be just a blog post somewhere (unless maybe Steve Dowers's blog).

Thus whole issue has been dogging python on windows for many years --
it never has been easy to find out what to do.

In fact, there are all sorts of Blog posts out there, with various
levels of out of date, conflicting, or just plain wrong advice.

A definitive version in the official docs would be a very good thing.

BTW, I think this is a good discussion:

https://github.com/cython/cython/wiki/CythonExtensionsOnWindows

But not everyone is going to think to look at the Cython Wiki...

-Chris


> You need to have the SDK compilers on your PATH (by running the
> relevant environment setting command) and you need to set the
> environment variable DISTUTILS_USE_SDK=1 (this latter bit of
> information is hard to find documented, admittedly, but pretty well
> known).
>
> That basically gives you a Visual Studio 2010 equivalent environment.
> You'll still have all sorts of *other* problems building extensions on
> Windows, but unless I'm missing something important in what you were
> saying, getting a compiler isn't the issue.
>
> Paul

From chris.barker at noaa.gov  Wed Sep 30 02:36:02 2015
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Tue, 29 Sep 2015 17:36:02 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <560AB9B3.3050408@python.org>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <4655937719415280861@unknownmsgid>
 <CAOTD34Zp7w0NWBVsX5vA3OmEQ8xE=OhPLi2axfK6r1vLpx_mOg@mail.gmail.com>
 <5609A090.7050003@mrabarnett.plus.com>
 <CACac1F9yvS7HvhQBjvObCAR022RT5GF1JYDuOsezd4kVEHOFKA@mail.gmail.com>
 <CAPJVwB=9i0ODBGwojbOZkOtC-piv24ebgzCgZ47+KMSkoxVqWA@mail.gmail.com>
 <CALGmxEK2c7te2P08Wfm6-xz85qtd2h7k5odQn6enz-mvt050EA@mail.gmail.com>
 <560AB9B3.3050408@python.org>
Message-ID: <-10899511336938356@unknownmsgid>

> On Sep 29, 2015, at 9:20 AM, Steve Dower <steve.dower at python.org> wrote:
>
>> On 29Sep2015 0820, Chris Barker wrote:
>> OK -- I'm going to get off my soap box now -- time to actually suggest
>> doc patches....
>
> Just bear in mind that you're suggesting patches for Python 3.3 and 3.4, which means that 3.4.4 is the only real chance to get them onto people's machines.

I don't expect to get it onto anyone's machine -- does anyone download
docs anymore?

> http://docs.python.org/ already points to the 3.5 docs by default, which means only people who explicitly look for the earlier versions will see the changes.

Well, if your trying to build an extension for 3.4, hopefully you'll
think to look at 3.4 docs.

But good point -- the 3.5 docs should have a note saying that the
requirements are different than older releases.

> You don't really have a huge audience, so I wouldn't invest large amounts of time in the official docs. A couple of well-publicised blog posts will reach more people.

Not on my blog.....

At this point, I think the Cython Wiki us the best place to point
people, but really, less than ideal.

-CHB


>
> Cheers,
> Steve
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov

From p.f.moore at gmail.com  Wed Sep 30 11:31:15 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 30 Sep 2015 10:31:15 +0100
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <853517484730244188@unknownmsgid>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <CACac1F8WE7V4yL1RxYWc+Z-bMNEWO03sdEycc2ERN6U=Zb_3Ug@mail.gmail.com>
 <853517484730244188@unknownmsgid>
Message-ID: <CACac1F-WrnOX4XZZQJDAP-7vEN17SaXpsroR2sfvdpELaR3jOg@mail.gmail.com>

On 30 September 2015 at 01:31, Chris Barker - NOAA Federal
<chris.barker at noaa.gov> wrote:
> It may be -- I've still have to test. Neither Windows nor py3 are my
> primary production versions.

Part of the problem here is that people put up postings saying "do
this" having checked that it works for them, and then others say "but
it doesn't work", without giving any information as to why or
providing any means to improve the instructions.

I'm not suggesting here that you're going to do this - but those
instructions are in essence the "official" (not well documented,
conceded) advice at present, and they have been tested by a number of
people for whom they work. They have also been reported to fail, but
(as noted above) never in a way that allows us to improve them :-(
They will remain the official advice, I suspect, until we get better
feedback.

> But the last time I tried the SDK approach was for py2.7 on Win64, and
> it was both a pain, and impossible to set up to "just work" in my
> highly secure environment.

Well, I'd need more explanation of the issues. Was "install the SDK" a
problem? Or was "set the environment variable DISTUTILS_USE_SDK"? Or
did the instructions to do those two things not work? (I appreciate
we're talking about 2 different things here, and I think Python 3 is a
much less painful case than 2.7 on win64 was prior to the Visual C for
Python 2.7 package).

I suspect (from your mention of a highly secure environment) that
installing the SDK was the main pain point. That's been the case for a
number of people, I believe. But I don't think advice on how to
install the Windows SDK in various environments is something we'd want
to maintain in the Python documentation...

This of course is another aspect of the problem - the official answer
is "use a supported version of Windows, ensure you have the necessary
permissions to install the needed software, and off you go". But in
real life people want to build on an old laptop they had lying around,
or on a VM they created on Linux, or on their Linux box using Wine, or
on the box they use for a load of other development that has more SDKs
than you want to imagine already installed, some of which got broken
in the past, ... Or they need to use mingw, because a key library
can't be compiled with Visual Studio. These are all real problems, and
the people fighting them are doing a huge amount of good work building
binary distributions for the community. They document what they are
doing to solve their issues and those documents show up on Google,
causing people who just want to build a simple extension to find them
and get hopelessly confused.

> So at best, it needs some serious documentation. And no, it shouldn't
> be just a blog post somewhere (unless maybe Steve Dowers's blog).

OK, without wishing to minimise what I fully agree is a serious
problem, at a very high level the instructions are:

For Python 2.7:

1. Install "Visual C++ Compiler Package for Python 2.7"
2. Use (a recent version of) setuptools in your setup.py (pip will do
this for you, in any case).
3. Done.

For Python 3.4

1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1)
2. Work from an SDK command prompt (with the environment variables
set, and the SDK on PATH).
3. Set DISTUTILS_USE_SDK=1
4. Done.

For Python 3.5

1. Install Visual Studio 2015 Community Edition (or any later version,
when these are released).
2. Done.

> Thus whole issue has been dogging python on windows for many years --
> it never has been easy to find out what to do.
>
> In fact, there are all sorts of Blog posts out there, with various
> levels of out of date, conflicting, or just plain wrong advice.

And this is why it's hard to fix the problem - people don't look at
the documentation, they don't try to find "official" advice, they
simply google and get a load of confusing advice. See above as to why
some of those documents are there, and are more complex than the
average user needs.

> A definitive version in the official docs would be a very good thing.

Well, I'd happily put the above instructions in the packaging user
guide (packaging.python.org). Would that be sufficient for you?

Paul

From chris.barker at noaa.gov  Wed Sep 30 17:57:08 2015
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Wed, 30 Sep 2015 08:57:08 -0700
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CACac1F-WrnOX4XZZQJDAP-7vEN17SaXpsroR2sfvdpELaR3jOg@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <CACac1F8WE7V4yL1RxYWc+Z-bMNEWO03sdEycc2ERN6U=Zb_3Ug@mail.gmail.com>
 <853517484730244188@unknownmsgid>
 <CACac1F-WrnOX4XZZQJDAP-7vEN17SaXpsroR2sfvdpELaR3jOg@mail.gmail.com>
Message-ID: <3651291780988629080@unknownmsgid>

TL;DR -- yes, documenting this in packaging.python.org would be great!

> Part of the problem here is that people put up postings saying "do
> this" having checked that it works for them, and then others say "but
> it doesn't work", without giving any information as to why or
> providing any means to improve the instructions.

Exactly. Which is why a Blog post is not the answer. If I find a blog
post, I have no idea how well vetted and tested it is.

If you look at the history of the Cython Wiki page about this, it
becomes very clear how much confusion there is. (Though I think it's
in pretty god shape now-- wikis have the advantage of being able to
evolve and getter better).

> I'm not suggesting here that you're going to do this -

Absolutely not -- I would not post anything anywhere without review --
this's kind of the point. If I find it in an official source, I know
it's been reviewed.

> us to improve them :-(
> They will remain the official advice, I suspect, until we get better
> feedback.

Which is my point -- how do I currently know what the official advise
is? (Yes, I know now -- thanks!) But posting to python-dev is exactly
the wrong way to find out!

>> But the last time I tried the SDK approach was for py2.7 on Win64, and
>> it was both a pain, and impossible to set up to "just work" in my
>> highly secure environment.
>
> Well, I'd need more explanation of the issues. Was "install the SDK" a
> problem? Or was "set the environment variable DISTUTILS_USE_SDK"? Or
> did the instructions to do those two things not work?

The issue was not having permissions to alter the registry the way we
wanted. But again, I'll need to do some proper testing with up to date
everything and see what happens.

>  I think Python 3 is a
> much less painful case than 2.7 on win64 was prior to the Visual C for
> Python 2.7 package).

Good to know.

>  But I don't think advice on how to
> install the Windows SDK in various environments is something we'd want
> to maintain in the Python documentation...

Agreed -- if you can't install it you can't install it. And if it
can't be installed in user-space, that's between MS and your
sysadmins...

> This of course is another aspect of the problem - the official answer
> is "use a supported version of Windows, ensure you have the necessary
> permissions to install the needed software, and off you go".

Well, I for one think that's fine. Supporting open source software on
a closed-source OS is going to have these pain points.

> OK, without wishing to minimise what I fully agree is a serious
> problem, at a very high level the instructions are:
>
> For Python 2.7:
>
> 1. Install "Visual C++ Compiler Package for Python 2.7"
> 2. Use (a recent version of) setuptools in your setup.py (pip will do
> this for you, in any case).
> 3. Done.

That new MS installer is really really great.

> For Python 3.4
>
> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1)
> 2. Work from an SDK command prompt (with the environment variables
> set, and the SDK on PATH).
> 3. Set DISTUTILS_USE_SDK=1
> 4. Done.

This, unfortunately is non-trivial, and really a pain if you want to
automate builds.

Apparently, conda-build has got this automated under the hood. Maybe
that could be kludge do into setuptools?

>  - people don't look at
> the documentation, they don't try to find "official" advice, they
> simply google and get a load of confusing advice.

Well, yes, but when there is no official advice, looking for it doesn't help....

I, for one, have looked for docs and official advise over and over
again for many years ( back when kept trying to remember if py2.6 was
built with VS2003 or VS2008, or ??

> Well, I'd happily put the above instructions in the packaging user
> guide (packaging.python.org). Would that be sufficient for you?

That would be great, thanks! An "official" source, but easier to
update that the regular docs.

Thanks,

-Chris

From p.f.moore at gmail.com  Wed Sep 30 21:15:54 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 30 Sep 2015 20:15:54 +0100
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <3651291780988629080@unknownmsgid>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <CACac1F8WE7V4yL1RxYWc+Z-bMNEWO03sdEycc2ERN6U=Zb_3Ug@mail.gmail.com>
 <853517484730244188@unknownmsgid>
 <CACac1F-WrnOX4XZZQJDAP-7vEN17SaXpsroR2sfvdpELaR3jOg@mail.gmail.com>
 <3651291780988629080@unknownmsgid>
Message-ID: <CACac1F-XPGcywPV9Fo1tB7u0ERN5Zz0epEJ-=P6EOU9uhK=uqQ@mail.gmail.com>

On 30 September 2015 at 16:57, Chris Barker - NOAA Federal
<chris.barker at noaa.gov> wrote:
>> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1)
>> 2. Work from an SDK command prompt (with the environment variables
>> set, and the SDK on PATH).
>> 3. Set DISTUTILS_USE_SDK=1
>> 4. Done.
>
> This, unfortunately is non-trivial, and really a pain if you want to
> automate builds.

Please clarify. What is non-trivial? Installing the SDK? I know, but
we said that's out of scope. Using an SDK command prompt? It is, sort
of, particularly if (like me) you use powershell. But again, not our
issue. I assume setting the environment variable isn't an issue - you
can do it for the session rather than globally, so even restrictive
permissions aren't a problem.

I appreciate you mightn't be intending this as criticism of the
instructions, but many people do criticise in exactly this sort of
way. Unix developers, in particular, who have limited Windows
knowledge, find this level of instruction really frustrating to deal
with. That's not a complaint - I have *huge* appreciation for
non-Windows users who bother to make builds for Windows users - but it
is an acknowledgement that often the audience for this sort of
instruction are stumped by Microsoft's less than intuitive install
processes...

For context, installing mingw is just as messy, complicated and error
prone (I speak from experience :-)) so it's unfair to complain that
the above is a non-trivial pain. I know of no install option that's
*less* straightforward than this (except of course for "install any
version of Visual Studio 2010, even the free ones" - if you have
access to those, use them!)

For automation, why not use Appveyor? See
https://packaging.python.org/en/latest/appveyor/ Unless you meant
setting up a local build machine. If you want a simple "install a
Python build environment" process, you could look at
https://github.com/pfmoore/pybuild - I haven't used it in a while (as
it's of no relevance to me, because I have VS2010) but it does work. I
never publicised or distributed it, because I got too much pushback in
terms of "but it doesn't work right on my system" (typically because
the system in question usually *wasn't* a clean build of Windows) that
I didn't have time or energy to address. But if it works for you, go
for it.

I'll push an addition to packaging.python.org, probably tomorrow.

Paul

From cmkleffner at gmail.com  Wed Sep 30 21:57:58 2015
From: cmkleffner at gmail.com (Carl Kleffner)
Date: Wed, 30 Sep 2015 21:57:58 +0200
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CACac1F-XPGcywPV9Fo1tB7u0ERN5Zz0epEJ-=P6EOU9uhK=uqQ@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <CACac1F8WE7V4yL1RxYWc+Z-bMNEWO03sdEycc2ERN6U=Zb_3Ug@mail.gmail.com>
 <853517484730244188@unknownmsgid>
 <CACac1F-WrnOX4XZZQJDAP-7vEN17SaXpsroR2sfvdpELaR3jOg@mail.gmail.com>
 <3651291780988629080@unknownmsgid>
 <CACac1F-XPGcywPV9Fo1tB7u0ERN5Zz0epEJ-=P6EOU9uhK=uqQ@mail.gmail.com>
Message-ID: <CAGGsPMxsuAW7ii=5VwY2HEJCO1rMKXf9MCps+0EfFGuSaDEa7A@mail.gmail.com>

Concerning the claims that mingw is difficult:

The mingwpy package is a sligthly modified mingw-w64 based gcc toolchain,
that is in development. It is designed for simple use and for much better
compatibility to the standard MSVC python builds. It should work out of the
box, as long as the <Python>\Scripts folder is in the PATH.

It is not 'officially' released and announced, due to the fact that some
features are missing, the documentation has to be written and the build
scripts for the toolchain are not (yet) published.

Install a prerelease of mingwpy with pip:

  pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy

or with conda: (thanks to omnia-md)

  conda install -c https://conda.anaconda.org/omnia mingwpy

and use it at usual with pip install or python setup.py

You may need to configure %USERPROFILE%\pydistutils.cfg to use mingwpy if
you have an MSVC compiler installed:

[config]
compiler=mingw32
[build]
compiler=mingw32
[build_ext]
compiler=mingw32

Or you install the latest portable winpython distribution
https://winpython.github.io that contains the toolchain as well and works
out of the box.

Future releases of mingwpy will be deployed on Pypi.

That has to be said: the main emphasis of the toolchain is building python
binary extension (C, C++, GFORTRAN) on windows, not building python itself.

Carl

2015-09-30 21:15 GMT+02:00 Paul Moore <p.f.moore at gmail.com>:

> On 30 September 2015 at 16:57, Chris Barker - NOAA Federal
> <chris.barker at noaa.gov> wrote:
> >> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1)
> >> 2. Work from an SDK command prompt (with the environment variables
> >> set, and the SDK on PATH).
> >> 3. Set DISTUTILS_USE_SDK=1
> >> 4. Done.
> >
> > This, unfortunately is non-trivial, and really a pain if you want to
> > automate builds.
>
> Please clarify. What is non-trivial? Installing the SDK? I know, but
> we said that's out of scope. Using an SDK command prompt? It is, sort
> of, particularly if (like me) you use powershell. But again, not our
> issue. I assume setting the environment variable isn't an issue - you
> can do it for the session rather than globally, so even restrictive
> permissions aren't a problem.
>
> I appreciate you mightn't be intending this as criticism of the
> instructions, but many people do criticise in exactly this sort of
> way. Unix developers, in particular, who have limited Windows
> knowledge, find this level of instruction really frustrating to deal
> with. That's not a complaint - I have *huge* appreciation for
> non-Windows users who bother to make builds for Windows users - but it
> is an acknowledgement that often the audience for this sort of
> instruction are stumped by Microsoft's less than intuitive install
> processes...
>
> For context, installing mingw is just as messy, complicated and error
> prone (I speak from experience :-)) so it's unfair to complain that
> the above is a non-trivial pain. I know of no install option that's
> *less* straightforward than this (except of course for "install any
> version of Visual Studio 2010, even the free ones" - if you have
> access to those, use them!)
>
> For automation, why not use Appveyor? See
> https://packaging.python.org/en/latest/appveyor/ Unless you meant
> setting up a local build machine. If you want a simple "install a
> Python build environment" process, you could look at
> https://github.com/pfmoore/pybuild - I haven't used it in a while (as
> it's of no relevance to me, because I have VS2010) but it does work. I
> never publicised or distributed it, because I got too much pushback in
> terms of "but it doesn't work right on my system" (typically because
> the system in question usually *wasn't* a clean build of Windows) that
> I didn't have time or energy to address. But if it works for you, go
> for it.
>
> I'll push an addition to packaging.python.org, probably tomorrow.
>
> Paul
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150930/9c7f3bfd/attachment.html>

From lgautier at gmail.com  Wed Sep 30 22:50:08 2015
From: lgautier at gmail.com (Laurent Gautier)
Date: Wed, 30 Sep 2015 20:50:08 +0000
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CAGGsPMxsuAW7ii=5VwY2HEJCO1rMKXf9MCps+0EfFGuSaDEa7A@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <CACac1F8WE7V4yL1RxYWc+Z-bMNEWO03sdEycc2ERN6U=Zb_3Ug@mail.gmail.com>
 <853517484730244188@unknownmsgid>
 <CACac1F-WrnOX4XZZQJDAP-7vEN17SaXpsroR2sfvdpELaR3jOg@mail.gmail.com>
 <3651291780988629080@unknownmsgid>
 <CACac1F-XPGcywPV9Fo1tB7u0ERN5Zz0epEJ-=P6EOU9uhK=uqQ@mail.gmail.com>
 <CAGGsPMxsuAW7ii=5VwY2HEJCO1rMKXf9MCps+0EfFGuSaDEa7A@mail.gmail.com>
Message-ID: <CA+JCgN2tg9K6Bx=1bE-TJN+oCDkBgvq-iNjUtLsyjPLsMyvtpA@mail.gmail.com>

Hi Carl,

Looks promising.

Any chance the effort would consider cross-compiling (from Linux) as a
possible objective ?

Best,

Laurent

On Wed, Sep 30, 2015, 3:58 PM Carl Kleffner <cmkleffner at gmail.com> wrote:

> Concerning the claims that mingw is difficult:
>
> The mingwpy package is a sligthly modified mingw-w64 based gcc toolchain,
> that is in development. It is designed for simple use and for much better
> compatibility to the standard MSVC python builds. It should work out of the
> box, as long as the <Python>\Scripts folder is in the PATH.
>
> It is not 'officially' released and announced, due to the fact that some
> features are missing, the documentation has to be written and the build
> scripts for the toolchain are not (yet) published.
>
> Install a prerelease of mingwpy with pip:
>
>   pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy
>
> or with conda: (thanks to omnia-md)
>
>   conda install -c https://conda.anaconda.org/omnia mingwpy
>
> and use it at usual with pip install or python setup.py
>
> You may need to configure %USERPROFILE%\pydistutils.cfg to use mingwpy if
> you have an MSVC compiler installed:
>
> [config]
> compiler=mingw32
> [build]
> compiler=mingw32
> [build_ext]
> compiler=mingw32
>
> Or you install the latest portable winpython distribution
> https://winpython.github.io that contains the toolchain as well and works
> out of the box.
>
> Future releases of mingwpy will be deployed on Pypi.
>
> That has to be said: the main emphasis of the toolchain is building python
> binary extension (C, C++, GFORTRAN) on windows, not building python itself.
>
> Carl
>
> 2015-09-30 21:15 GMT+02:00 Paul Moore <p.f.moore at gmail.com>:
>
>> On 30 September 2015 at 16:57, Chris Barker - NOAA Federal
>> <chris.barker at noaa.gov> wrote:
>> >> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1)
>> >> 2. Work from an SDK command prompt (with the environment variables
>> >> set, and the SDK on PATH).
>> >> 3. Set DISTUTILS_USE_SDK=1
>> >> 4. Done.
>> >
>> > This, unfortunately is non-trivial, and really a pain if you want to
>> > automate builds.
>>
>> Please clarify. What is non-trivial? Installing the SDK? I know, but
>> we said that's out of scope. Using an SDK command prompt? It is, sort
>> of, particularly if (like me) you use powershell. But again, not our
>> issue. I assume setting the environment variable isn't an issue - you
>> can do it for the session rather than globally, so even restrictive
>> permissions aren't a problem.
>>
>> I appreciate you mightn't be intending this as criticism of the
>> instructions, but many people do criticise in exactly this sort of
>> way. Unix developers, in particular, who have limited Windows
>> knowledge, find this level of instruction really frustrating to deal
>> with. That's not a complaint - I have *huge* appreciation for
>> non-Windows users who bother to make builds for Windows users - but it
>> is an acknowledgement that often the audience for this sort of
>> instruction are stumped by Microsoft's less than intuitive install
>> processes...
>>
>> For context, installing mingw is just as messy, complicated and error
>> prone (I speak from experience :-)) so it's unfair to complain that
>> the above is a non-trivial pain. I know of no install option that's
>> *less* straightforward than this (except of course for "install any
>> version of Visual Studio 2010, even the free ones" - if you have
>> access to those, use them!)
>>
>> For automation, why not use Appveyor? See
>> https://packaging.python.org/en/latest/appveyor/ Unless you meant
>> setting up a local build machine. If you want a simple "install a
>> Python build environment" process, you could look at
>> https://github.com/pfmoore/pybuild - I haven't used it in a while (as
>> it's of no relevance to me, because I have VS2010) but it does work. I
>> never publicised or distributed it, because I got too much pushback in
>> terms of "but it doesn't work right on my system" (typically because
>> the system in question usually *wasn't* a clean build of Windows) that
>> I didn't have time or energy to address. But if it works for you, go
>> for it.
>>
>> I'll push an addition to packaging.python.org, probably tomorrow.
>>
>> Paul
>>
> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>>
> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com
>>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/lgautier%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150930/0f0fa719/attachment.html>

From cmkleffner at gmail.com  Wed Sep 30 23:08:46 2015
From: cmkleffner at gmail.com (Carl Kleffner)
Date: Wed, 30 Sep 2015 23:08:46 +0200
Subject: [Python-Dev] VS 2010 compiler
In-Reply-To: <CA+JCgN2tg9K6Bx=1bE-TJN+oCDkBgvq-iNjUtLsyjPLsMyvtpA@mail.gmail.com>
References: <-2386876371239912889@unknownmsgid>
 <CAEfz+Ty=rH34s_P7odwx-1tsd8JNzNCpO_iZYEjTeLtE3_GuLw@mail.gmail.com>
 <CACac1F8WE7V4yL1RxYWc+Z-bMNEWO03sdEycc2ERN6U=Zb_3Ug@mail.gmail.com>
 <853517484730244188@unknownmsgid>
 <CACac1F-WrnOX4XZZQJDAP-7vEN17SaXpsroR2sfvdpELaR3jOg@mail.gmail.com>
 <3651291780988629080@unknownmsgid>
 <CACac1F-XPGcywPV9Fo1tB7u0ERN5Zz0epEJ-=P6EOU9uhK=uqQ@mail.gmail.com>
 <CAGGsPMxsuAW7ii=5VwY2HEJCO1rMKXf9MCps+0EfFGuSaDEa7A@mail.gmail.com>
 <CA+JCgN2tg9K6Bx=1bE-TJN+oCDkBgvq-iNjUtLsyjPLsMyvtpA@mail.gmail.com>
Message-ID: <CAGGsPMz-6AEPTyRJa71YDgmr2w-CKruAXsjDeqSGQtUH+u8ktg@mail.gmail.com>

It should be possible with Wine.
Am 30.09.2015 22:50 schrieb "Laurent Gautier" <lgautier at gmail.com>:

> Hi Carl,
>
> Looks promising.
>
> Any chance the effort would consider cross-compiling (from Linux) as a
> possible objective ?
>
> Best,
>
> Laurent
>
> On Wed, Sep 30, 2015, 3:58 PM Carl Kleffner <cmkleffner at gmail.com> wrote:
>
>> Concerning the claims that mingw is difficult:
>>
>> The mingwpy package is a sligthly modified mingw-w64 based gcc toolchain,
>> that is in development. It is designed for simple use and for much better
>> compatibility to the standard MSVC python builds. It should work out of the
>> box, as long as the <Python>\Scripts folder is in the PATH.
>>
>> It is not 'officially' released and announced, due to the fact that some
>> features are missing, the documentation has to be written and the build
>> scripts for the toolchain are not (yet) published.
>>
>> Install a prerelease of mingwpy with pip:
>>
>>   pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy
>>
>> or with conda: (thanks to omnia-md)
>>
>>   conda install -c https://conda.anaconda.org/omnia mingwpy
>>
>> and use it at usual with pip install or python setup.py
>>
>> You may need to configure %USERPROFILE%\pydistutils.cfg to use mingwpy
>> if you have an MSVC compiler installed:
>>
>> [config]
>> compiler=mingw32
>> [build]
>> compiler=mingw32
>> [build_ext]
>> compiler=mingw32
>>
>> Or you install the latest portable winpython distribution
>> https://winpython.github.io that contains the toolchain as well and
>> works out of the box.
>>
>> Future releases of mingwpy will be deployed on Pypi.
>>
>> That has to be said: the main emphasis of the toolchain is building
>> python binary extension (C, C++, GFORTRAN) on windows, not building python
>> itself.
>>
>> Carl
>>
>> 2015-09-30 21:15 GMT+02:00 Paul Moore <p.f.moore at gmail.com>:
>>
>>> On 30 September 2015 at 16:57, Chris Barker - NOAA Federal
>>> <chris.barker at noaa.gov> wrote:
>>> >> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1)
>>> >> 2. Work from an SDK command prompt (with the environment variables
>>> >> set, and the SDK on PATH).
>>> >> 3. Set DISTUTILS_USE_SDK=1
>>> >> 4. Done.
>>> >
>>> > This, unfortunately is non-trivial, and really a pain if you want to
>>> > automate builds.
>>>
>>> Please clarify. What is non-trivial? Installing the SDK? I know, but
>>> we said that's out of scope. Using an SDK command prompt? It is, sort
>>> of, particularly if (like me) you use powershell. But again, not our
>>> issue. I assume setting the environment variable isn't an issue - you
>>> can do it for the session rather than globally, so even restrictive
>>> permissions aren't a problem.
>>>
>>> I appreciate you mightn't be intending this as criticism of the
>>> instructions, but many people do criticise in exactly this sort of
>>> way. Unix developers, in particular, who have limited Windows
>>> knowledge, find this level of instruction really frustrating to deal
>>> with. That's not a complaint - I have *huge* appreciation for
>>> non-Windows users who bother to make builds for Windows users - but it
>>> is an acknowledgement that often the audience for this sort of
>>> instruction are stumped by Microsoft's less than intuitive install
>>> processes...
>>>
>>> For context, installing mingw is just as messy, complicated and error
>>> prone (I speak from experience :-)) so it's unfair to complain that
>>> the above is a non-trivial pain. I know of no install option that's
>>> *less* straightforward than this (except of course for "install any
>>> version of Visual Studio 2010, even the free ones" - if you have
>>> access to those, use them!)
>>>
>>> For automation, why not use Appveyor? See
>>> https://packaging.python.org/en/latest/appveyor/ Unless you meant
>>> setting up a local build machine. If you want a simple "install a
>>> Python build environment" process, you could look at
>>> https://github.com/pfmoore/pybuild - I haven't used it in a while (as
>>> it's of no relevance to me, because I have VS2010) but it does work. I
>>> never publicised or distributed it, because I got too much pushback in
>>> terms of "but it doesn't work right on my system" (typically because
>>> the system in question usually *wasn't* a clean build of Windows) that
>>> I didn't have time or energy to address. But if it works for you, go
>>> for it.
>>>
>>> I'll push an addition to packaging.python.org, probably tomorrow.
>>>
>>> Paul
>>>
>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>>
>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com
>>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/lgautier%40gmail.com
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150930/f24b619e/attachment-0001.html>