[Python-Dev] 3.7.0b1 status

[Ned Deily]

Just a quick update: thanks to all of you who worked long hours to get features 
completed and merged in for the 3.7 feature code cutoff yesterday.  We release 
elves have been busy behind the scenes baking goodies.  So far everything looks 
OK.  But we're taking a little longer than usual: this is, in many ways, the 
most complicated milestone of the release cycle, since it involves creating a 
new release branch and other munging, and this is the first time we are doing 
this since we moved to our new git-based workflow last year and we want to get 
it right.  We will have everything done and announced in not more than 24 hours 
from now.  If you wish, feel free to merge new commits into the master branch 
for release in 3.8, with the understanding that any also destined for 3.7.0 
will need to be cherrypicked after the 3.7 branch is available.  Other branches 
(3.6, 2.7) are unaffected.

Thanks for your patience!

--
  Ned Deily
  n...@python.org -- []

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

Re: [Python-Dev] OS-X builds for 3.7.0

[Ray Donnelly]

On Jan 30, 2018 6:47 PM, "Joni Orponen"  wrote:

On Tue, Jan 30, 2018 at 6:50 PM, Ray Donnelly 
wrote:

> While we're making such macOS-build requests, any chance of building a
> static interpreter too? We've been doing that on the Anaconda
> Distribution since the 5.0 release in September and it seems to be
> working well.
>

PyPy is also currently eyeing doing their macOS builds better:
https://bitbucket.org/pypy/pypy/issues/2734/establish-a-build-and-release-
pipeline-for

What do the Anaconda static builds get built on?


We have our own clang pseudo cross-compilers and use a macOS 10.9 SDK for
all of our package compilation to achieve compatibility (this means we can
compile on newer macOS just fine). We see a 1.1 to 1.2 times performance
benefit over official releases as measured using 'python performance'.

Apart from a static interpreter we also enable LTO and PGO and only build
for 64-bit so I'm not sure how much each bit continues. Our recipe for
python 3.6 can be found at:

https://github.com/AnacondaRecipes/python-feedstock/tree/master/recipe


-- 
Joni Orponen

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

Re: [Python-Dev] OS-X builds for 3.7.0

[Ray Donnelly]

On Jan 31, 2018 8:31 AM, "Ray Donnelly"  wrote:



On Jan 30, 2018 6:47 PM, "Joni Orponen"  wrote:

On Tue, Jan 30, 2018 at 6:50 PM, Ray Donnelly 
wrote:

> While we're making such macOS-build requests, any chance of building a
> static interpreter too? We've been doing that on the Anaconda
> Distribution since the 5.0 release in September and it seems to be
> working well.
>

PyPy is also currently eyeing doing their macOS builds better:
https://bitbucket.org/pypy/pypy/issues/2734/establis
h-a-build-and-release-pipeline-for

What do the Anaconda static builds get built on?


We have our own clang pseudo cross-compilers and use a macOS 10.9 SDK for
all of our package compilation to achieve compatibility (this means we can
compile on newer macOS just fine). We see a 1.1 to 1.2 times performance
benefit over official releases as measured using 'python performance'.

Apart from a static interpreter we also enable LTO and PGO and only build
for 64-bit so I'm not sure how much each bit continues. Our recipe for
python 3.6 can be found at:


s/continues/contributes/


https://github.com/AnacondaRecipes/python-feedstock/tree/master/recipe


-- 
Joni Orponen

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

Re: [Python-Dev] Making "-j0" the default setting for the test suite?

[Victor Stinner]

2018-01-31 3:23 GMT+01:00 Nick Coghlan :
> Something like:
>
> Total duration: 16 minutes 33 seconds (serial execution, pass
> '-j0' for parallel execution)
>
> Such a change would be a safe way to nudge new contributors towards
> "./python -m test -j0" for faster local testing, without risking
> backwards compatibility issues with existing test suite invocations in
> other contexts.

I have no strong opinion on using -j0 by default, but repeating
parallel vs serial execution in the summary is an excellent idea :-)

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

Re: [Python-Dev] OS-X builds for 3.7.0

[Joni Orponen]

On Wed, Jan 31, 2018 at 12:43 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> And maybe we could even get rid of the "Framework" builds..
>>
>
> Please do not. These make life easier for doing things the Apple way for
> signed sandboxed applications.
>
> Thanks — good to hear there is a good reason for them. I’ve always thought
> that Frameworks were designed with other use-casss, and didn’t really help
> with Python.
>
> For the record, are you re-distributing the python.org builds, or
> re-building yourself?
>

We are re-building ourselves. Seems we've cooked up something not too
unsimilar to what Anaconda is doing, but less generic and covering less
corner cases.

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

Re: [Python-Dev] OS-X builds for 3.7.0

[Joni Orponen]

On Wed, Jan 31, 2018 at 9:31 AM, Ray Donnelly 
wrote:

> We see a 1.1 to 1.2 times performance benefit over official releases as
> measured using 'python performance'.
>
> Apart from a static interpreter we also enable LTO and PGO and only build
> for 64-bit so I'm not sure how much each bit continues. Our recipe for
> python 3.6 can be found at:
>

Do you metrify LTO and PGO independent of each other as well or only the
"enable everything" combo? I've had mixed results with LTO so far, but this
is probably hardware / compiler combination specific.

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

Re: [Python-Dev] OS-X builds for 3.7.0

[Ray Donnelly]

On Wed, Jan 31, 2018 at 11:16 AM, Joni Orponen  wrote:
> On Wed, Jan 31, 2018 at 9:31 AM, Ray Donnelly 
> wrote:
>>
>> We see a 1.1 to 1.2 times performance benefit over official releases as
>> measured using 'python performance'.
>>
>> Apart from a static interpreter we also enable LTO and PGO and only build
>> for 64-bit so I'm not sure how much each bit continues. Our recipe for
>> python 3.6 can be found at:
>
>
> Do you metrify LTO and PGO independent of each other as well or only the
> "enable everything" combo? I've had mixed results with LTO so far, but this
> is probably hardware / compiler combination specific.

I've never found enough time to take detailed metrics, sorry. Maybe
one day? Looking at my performance graphs again:

Against the official CPython 3.6 (probably .3 or .4) release I see:
1 that is 2.01x faster (python-startup, 24.6ms down to 12.2ms)
5 that are >=1.5x,<1.6x faster.
13 that are >=1.4x,<1.5x faster.
21 that are >=1.3x,<1.4x faster.
14 that are >=1.2x,<1.3x faster.
5 that are >=1.1x,<1.2x faster.
0 that are < 1.1x faster/slower.

Pretty good numbers overall I think.




>
> --
> Joni Orponen
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mingw.android%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[INADA Naoki]

>
> Against the official CPython 3.6 (probably .3 or .4) release I see:
> 1 that is 2.01x faster (python-startup, 24.6ms down to 12.2ms)
> 5 that are >=1.5x,<1.6x faster.
> 13 that are >=1.4x,<1.5x faster.
> 21 that are >=1.3x,<1.4x faster.
> 14 that are >=1.2x,<1.3x faster.
> 5 that are >=1.1x,<1.2x faster.
> 0 that are < 1.1x faster/slower.
>
> Pretty good numbers overall I think.
>
>

Yay!!  Congrats for all of us!

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

Re: [Python-Dev] OS-X builds for 3.7.0

[Victor Stinner]

There is https://speed.python.org/comparison/ to compare Python 2.7, 3.5,
3.6 and master (future 3.7).

Victor

Le 31 janv. 2018 13:14, "Ray Donnelly"  a écrit :

> On Wed, Jan 31, 2018 at 11:16 AM, Joni Orponen 
> wrote:
> > On Wed, Jan 31, 2018 at 9:31 AM, Ray Donnelly 
> > wrote:
> >>
> >> We see a 1.1 to 1.2 times performance benefit over official releases as
> >> measured using 'python performance'.
> >>
> >> Apart from a static interpreter we also enable LTO and PGO and only
> build
> >> for 64-bit so I'm not sure how much each bit continues. Our recipe for
> >> python 3.6 can be found at:
> >
> >
> > Do you metrify LTO and PGO independent of each other as well or only the
> > "enable everything" combo? I've had mixed results with LTO so far, but
> this
> > is probably hardware / compiler combination specific.
>
> I've never found enough time to take detailed metrics, sorry. Maybe
> one day? Looking at my performance graphs again:
>
> Against the official CPython 3.6 (probably .3 or .4) release I see:
> 1 that is 2.01x faster (python-startup, 24.6ms down to 12.2ms)
> 5 that are >=1.5x,<1.6x faster.
> 13 that are >=1.4x,<1.5x faster.
> 21 that are >=1.3x,<1.4x faster.
> 14 that are >=1.2x,<1.3x faster.
> 5 that are >=1.1x,<1.2x faster.
> 0 that are < 1.1x faster/slower.
>
> Pretty good numbers overall I think.
>
>
>
>
> >
> > --
> > Joni Orponen
> >
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > https://mail.python.org/mailman/options/python-dev/
> mingw.android%40gmail.com
> >
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> victor.stinner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Steve Holden]

The horizontal axis labelling in that graph is useless with so many tests
included!

Would a graphic with hover labels over the bars be more useful?

Steve Holden

On Wed, Jan 31, 2018 at 1:06 PM, Victor Stinner 
wrote:

> There is https://speed.python.org/comparison/ to compare Python 2.7, 3.5,
> 3.6 and master (future 3.7).
>
> Victor
>
> Le 31 janv. 2018 13:14, "Ray Donnelly"  a écrit :
>
>> On Wed, Jan 31, 2018 at 11:16 AM, Joni Orponen 
>> wrote:
>> > On Wed, Jan 31, 2018 at 9:31 AM, Ray Donnelly 
>> > wrote:
>> >>
>> >> We see a 1.1 to 1.2 times performance benefit over official releases as
>> >> measured using 'python performance'.
>> >>
>> >> Apart from a static interpreter we also enable LTO and PGO and only
>> build
>> >> for 64-bit so I'm not sure how much each bit continues. Our recipe for
>> >> python 3.6 can be found at:
>> >
>> >
>> > Do you metrify LTO and PGO independent of each other as well or only the
>> > "enable everything" combo? I've had mixed results with LTO so far, but
>> this
>> > is probably hardware / compiler combination specific.
>>
>> I've never found enough time to take detailed metrics, sorry. Maybe
>> one day? Looking at my performance graphs again:
>>
>> Against the official CPython 3.6 (probably .3 or .4) release I see:
>> 1 that is 2.01x faster (python-startup, 24.6ms down to 12.2ms)
>> 5 that are >=1.5x,<1.6x faster.
>> 13 that are >=1.4x,<1.5x faster.
>> 21 that are >=1.3x,<1.4x faster.
>> 14 that are >=1.2x,<1.3x faster.
>> 5 that are >=1.1x,<1.2x faster.
>> 0 that are < 1.1x faster/slower.
>>
>> Pretty good numbers overall I think.
>>
>>
>>
>>
>> >
>> > --
>> > Joni Orponen
>> >
>> > ___
>> > Python-Dev mailing list
>> > Python-Dev@python.org
>> > https://mail.python.org/mailman/listinfo/python-dev
>> > Unsubscribe:
>> > https://mail.python.org/mailman/options/python-dev/mingw.
>> android%40gmail.com
>> >
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.
>> stinner%40gmail.com
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> steve%40holdenweb.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Victor Stinner]

Click on "[x] horizontal" to exchange the two axis ;-)

Victor

2018-01-31 16:08 GMT+01:00 Steve Holden :
> The horizontal axis labelling in that graph is useless with so many tests
> included!
>
> Would a graphic with hover labels over the bars be more useful?
>
> Steve Holden
>
> On Wed, Jan 31, 2018 at 1:06 PM, Victor Stinner 
> wrote:
>>
>> There is https://speed.python.org/comparison/ to compare Python 2.7, 3.5,
>> 3.6 and master (future 3.7).
>>
>> Victor
>>
>> Le 31 janv. 2018 13:14, "Ray Donnelly"  a écrit :
>>>
>>> On Wed, Jan 31, 2018 at 11:16 AM, Joni Orponen 
>>> wrote:
>>> > On Wed, Jan 31, 2018 at 9:31 AM, Ray Donnelly 
>>> > wrote:
>>> >>
>>> >> We see a 1.1 to 1.2 times performance benefit over official releases
>>> >> as
>>> >> measured using 'python performance'.
>>> >>
>>> >> Apart from a static interpreter we also enable LTO and PGO and only
>>> >> build
>>> >> for 64-bit so I'm not sure how much each bit continues. Our recipe for
>>> >> python 3.6 can be found at:
>>> >
>>> >
>>> > Do you metrify LTO and PGO independent of each other as well or only
>>> > the
>>> > "enable everything" combo? I've had mixed results with LTO so far, but
>>> > this
>>> > is probably hardware / compiler combination specific.
>>>
>>> I've never found enough time to take detailed metrics, sorry. Maybe
>>> one day? Looking at my performance graphs again:
>>>
>>> Against the official CPython 3.6 (probably .3 or .4) release I see:
>>> 1 that is 2.01x faster (python-startup, 24.6ms down to 12.2ms)
>>> 5 that are >=1.5x,<1.6x faster.
>>> 13 that are >=1.4x,<1.5x faster.
>>> 21 that are >=1.3x,<1.4x faster.
>>> 14 that are >=1.2x,<1.3x faster.
>>> 5 that are >=1.1x,<1.2x faster.
>>> 0 that are < 1.1x faster/slower.
>>>
>>> Pretty good numbers overall I think.
>>>
>>>
>>>
>>>
>>> >
>>> > --
>>> > Joni Orponen
>>> >
>>> > ___
>>> > Python-Dev mailing list
>>> > Python-Dev@python.org
>>> > https://mail.python.org/mailman/listinfo/python-dev
>>> > Unsubscribe:
>>> >
>>> > https://mail.python.org/mailman/options/python-dev/mingw.android%40gmail.com
>>> >
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Steve Holden]

Doh! Thank you.

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

[Python-Dev] Why is Python for Windows compiled with MSVC?

[Oleg Sivokon]

Hello list.

I'll give some background before asking my question in more detail.

I've been tasked with writing some infrastructure code that needs to talk to 
Kubernetes.  (Kubernetes is a popular software for managing and automating 
virtualization / containerization of cloud services).  One of the requirements 
was that the code be written in Python 3.X.

The tasks my code was supposed to perform on Kubernetes would be something like 
cluster creation from specification, deletion of all or parts of the cluster, 
providing realtime statistics of cluster usage etc.  There were few prototype 
scripts written in Bash using kubectl (official client written in Go).

My first reaction was to look for an official client for Kubernetes written in 
Python. There is one official client for Kubernetes, with a single maintainer, 
impossible to parse documentation, containing mostly generated code.  It is 
nigh impossible to use.  Here I need to explain that for whatever reason 
Kubernetes team decided to write their HTTP API in such a way that the server 
is "dumb" and the client must be "smart" in order to do anything useful.  For 
instance, if you have a description of your cluster, you cannot just send this 
description to the server and hope that it will know how to create the cluster 
from description.  You need to make multiple API calls (perhaps hundreds of 
them) to arrange for the server to create the cluster from description.

Since the official client is no help (it really only mirrors the HTTP API), I 
searched for other clients.  There are two more.  None is in good shape, and 
none comes even close to being able to do what kubectl can.

There is one more client that shells out calls to kubectl.  It implements only 
a small subset of kubectl commands, and... it's a lot of parsing of standard 
output with regular expressions and magic.

Well... I was given a lot of time to investigate other options for dealing with 
this project, so I decided, what if I can compile kubectl into a shared library 
and write a Python extension that links against that library.  And, indeed, 
after few days I came up with such an extension.  It worked!..  On Linux...

Now all I had to do was to re-create my success on Windows (most of the 
employees in my company use Windows).  At first I thought that I'd 
cross-compile on Linux using MinGW.  I compiled Go shared library into a DLL, 
then tried to compile my Python extension and... it didn't work.  I downloaded 
VirtualBox and some Windows images, etc... tried to compile on Windows.  It 
didn't work.  I started asking around, and was told that even though for some 
earlier versions of Python this was kind of possible, for Python 3.5, 3.6 it is 
not.  You must use MSVC to compile Python extensions.  No way around it.
Now, since Go won't compile with MSVC, I'll have to scrap my project and spend 
many weeks re-implementing kubectl.

Here's my question: Why?

Why did you choose to use non-free compiler, which also makes cross-compilation 
impossible?  There wasn't really a reason not to choose MinGW as a way to 
compile extensions on Windows (Ruby does that, Go uses MinGW, perhaps some 
others too).  It would've made things like CI and packaging so much easier...  
What do Python users / developers get from using MSVC instead?

Thank you.

Oleg
This communication and all information contained in or attached to it is 
confidential, intended solely for the addressee, may be legally privileged and 
is the intellectual property of one of the companies of NEX Group plc ("NEX") 
or third parties. If you are not the intended addressee or receive this message 
in error, please immediately delete all copies of it and notify the sender. We 
have taken precautions to minimise the risk of transmitting software viruses, 
but we advise you to carry out your own virus checks on any attachments. We do 
not accept liability for any loss or damage caused by software viruses. NEX 
reserves the right to monitor all communications. We do not accept any legal 
responsibility for the content of communications, and no communication shall be 
considered legally binding. Furthermore, if the content of this communication 
is personal or unconnected with our business, we accept no liability or 
responsibility for it. NEX Group plc is a public limited company regi
 stered in England and Wales under number 10013770 and certain of its 
affiliates are authorised and regulated by regulatory authorities. For further 
regulatory information please see www.NEX.com.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why is Python for Windows compiled with MSVC?

[Ray Donnelly]

On Wed, Jan 31, 2018 at 3:04 PM, Oleg Sivokon  wrote:
> Hello list.
>
> I'll give some background before asking my question in more detail.
>
> I've been tasked with writing some infrastructure code that needs to talk to 
> Kubernetes.  (Kubernetes is a popular software for managing and automating 
> virtualization / containerization of cloud services).  One of the 
> requirements was that the code be written in Python 3.X.
>
> The tasks my code was supposed to perform on Kubernetes would be something 
> like cluster creation from specification, deletion of all or parts of the 
> cluster, providing realtime statistics of cluster usage etc.  There were few 
> prototype scripts written in Bash using kubectl (official client written in 
> Go).
>
> My first reaction was to look for an official client for Kubernetes written 
> in Python. There is one official client for Kubernetes, with a single 
> maintainer, impossible to parse documentation, containing mostly generated 
> code.  It is nigh impossible to use.  Here I need to explain that for 
> whatever reason Kubernetes team decided to write their HTTP API in such a way 
> that the server is "dumb" and the client must be "smart" in order to do 
> anything useful.  For instance, if you have a description of your cluster, 
> you cannot just send this description to the server and hope that it will 
> know how to create the cluster from description.  You need to make multiple 
> API calls (perhaps hundreds of them) to arrange for the server to create the 
> cluster from description.
>
> Since the official client is no help (it really only mirrors the HTTP API), I 
> searched for other clients.  There are two more.  None is in good shape, and 
> none comes even close to being able to do what kubectl can.
>
> There is one more client that shells out calls to kubectl.  It implements 
> only a small subset of kubectl commands, and... it's a lot of parsing of 
> standard output with regular expressions and magic.
>
> Well... I was given a lot of time to investigate other options for dealing 
> with this project, so I decided, what if I can compile kubectl into a shared 
> library and write a Python extension that links against that library.  And, 
> indeed, after few days I came up with such an extension.  It worked!..  On 
> Linux...
>
> Now all I had to do was to re-create my success on Windows (most of the 
> employees in my company use Windows).  At first I thought that I'd 
> cross-compile on Linux using MinGW.  I compiled Go shared library into a DLL, 
> then tried to compile my Python extension and... it didn't work.  I 
> downloaded VirtualBox and some Windows images, etc... tried to compile on 
> Windows.  It didn't work.  I started asking around, and was told that even 
> though for some earlier versions of Python this was kind of possible, for 
> Python 3.5, 3.6 it is not.  You must use MSVC to compile Python extensions.  
> No way around it.
> Now, since Go won't compile with MSVC, I'll have to scrap my project and 
> spend many weeks re-implementing kubectl.
>
> Here's my question: Why?
>
> Why did you choose to use non-free compiler, which also makes 
> cross-compilation impossible?  There wasn't really a reason not to choose 
> MinGW as a way to compile extensions on Windows (Ruby does that, Go uses 
> MinGW, perhaps some others too).  It would've made things like CI and 
> packaging so much easier...  What do Python users / developers get from using 
> MSVC instead?

You can compile extension modules with mingw-w64 just fine (modulus a
few gotchas). The Anaconda Distribution we do this for a few packages,
for example rpy2. You can see the build script used here:
https://github.com/AnacondaRecipes/rpy2-feedstock/blob/master/recipe/bld.bat
(disclaimer: I work for Anaconda Inc on this stuff).

MSYS2 also have mingw-w64 builds of Python that might meet your needs.
It is pretty popular in some parts of the open source on Windows world
(disclaimer: I did a lot of the work for this stuff on MSYS2).

>
> Thank you.
>
> Oleg
> This communication and all information contained in or attached to it is 
> confidential, intended solely for the addressee, may be legally privileged 
> and is the intellectual property of one of the companies of NEX Group plc 
> ("NEX") or third parties. If you are not the intended addressee or receive 
> this message in error, please immediately delete all copies of it and notify 
> the sender. We have taken precautions to minimise the risk of transmitting 
> software viruses, but we advise you to carry out your own virus checks on any 
> attachments. We do not accept liability for any loss or damage caused by 
> software viruses. NEX reserves the right to monitor all communications. We do 
> not accept any legal responsibility for the content of communications, and no 
> communication shall be considered legally binding. Furthermore, if the 
> content of this communication is personal or unconnected with our business, 
> we accept n

Re: [Python-Dev] Why is Python for Windows compiled with MSVC?

[Terry Reedy]

On 1/31/2018 10:04 AM, Oleg Sivokon wrote:


Why did you choose to use non-free compiler, which also makes cross-compilation 
impossible?  There wasn't really a reason not to choose MinGW as


Python was ported to DOS years before the initial 1998 release of the 
mingw32 predecessor.  There has been some work to make Python also 
compile with MinGW, but AFAIK, no one has volunteered to persist in 
doing complete patch for MinGW.  You can look at the tracker to get some 
idea of what is missing.  I presume contributions are still allowed and 
welcome.



a way to compile extensions on Windows (Ruby does that, Go uses MinGW, perhaps 
some others too).  It would've made things like CI and packaging so much 
easier...  What do Python users / developers get from using MSVC instead?


Timely access to all features added to Windows, such as 64 bit binaries. 
 Access to everything compiled with the compiler nearly everyone else 
uses.  Help to make Python work on DOS, now Windows, from people who 
only know and use Microsoft tools.



communication and all information contained in or attached to it 
isconfidential, intended solely for the addressee,


Please omit this noise.  Posting to pydev is posting to the world, 
including multiple mirrors and repositories.


--
Terry Jan Reedy

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

[Python-Dev] Backfilling 'awaiting' labels

[Brett Cannon]

I have written a script that will go through and backfill the 'awaiting'
label on older pull requests based on the review state as it stands today.
A comment will be left if an "awaiting changes" label is set explaining
that we're backfilling and if you're ready for a change review then leave
the magical comment to trigger Bedevere.

My plan is to limit this to only 20 total comments within a day so at to
not overwhelm any single person with notifications. I will also run this
script manually so there's no guarantee this will even occur every day.

Assuming that 20 comment/day limit seems reasonable to people I will
probably do the inaugural run tomorrow which will add an 'awaiting label'
to 158 issues (which should be more than half of the issues lacking an
'awaiting' label).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why is Python for Windows compiled with MSVC?

[MRAB]

On 2018-01-31 19:07, Ray Donnelly wrote:

On Wed, Jan 31, 2018 at 3:04 PM, Oleg Sivokon  wrote:

Hello list.

I'll give some background before asking my question in more detail.


[snip]


Now all I had to do was to re-create my success on Windows (most of the 
employees in my company use Windows).  At first I thought that I'd 
cross-compile on Linux using MinGW.  I compiled Go shared library into a DLL, 
then tried to compile my Python extension and... it didn't work.  I downloaded 
VirtualBox and some Windows images, etc... tried to compile on Windows.  It 
didn't work.  I started asking around, and was told that even though for some 
earlier versions of Python this was kind of possible, for Python 3.5, 3.6 it is 
not.  You must use MSVC to compile Python extensions.  No way around it.
Now, since Go won't compile with MSVC, I'll have to scrap my project and spend 
many weeks re-implementing kubectl.

Here's my question: Why?

Why did you choose to use non-free compiler, which also makes cross-compilation 
impossible?  There wasn't really a reason not to choose MinGW as a way to 
compile extensions on Windows (Ruby does that, Go uses MinGW, perhaps some 
others too).  It would've made things like CI and packaging so much easier...  
What do Python users / developers get from using MSVC instead?


You can compile extension modules with mingw-w64 just fine (modulus a
few gotchas). The Anaconda Distribution we do this for a few packages,
for example rpy2. You can see the build script used here:
https://github.com/AnacondaRecipes/rpy2-feedstock/blob/master/recipe/bld.bat
(disclaimer: I work for Anaconda Inc on this stuff).

MSYS2 also have mingw-w64 builds of Python that might meet your needs.
It is pretty popular in some parts of the open source on Windows world
(disclaimer: I did a lot of the work for this stuff on MSYS2).
I build the wheels (binaries for Windows) for the regex module using 

mingw-w64 and they also work just fine.

I can also build using Microsoft Visual Studio Community 2017 (which is 
free) and they work.


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

Re: [Python-Dev] Why is Python for Windows compiled with MSVC?

[Steve Dower]

Because every other supported platform builds using the native tools, so why 
shouldn’t the one with the most users?

I’m likely biased because I work there and I’m the main intermediary with 
python-dev, but these days Microsoft is one of the strongest supporters of 
CPython. We employ the most core developers of any private company and we all 
are allowed work time to contribute, we provide full access to our development 
tools and platforms to all core developers and some prominent projects, we’ve 
made fixes, enhancements and releases or core products such as the CRT, MSVC, 
Visual Studio, Visual Studio Code, and Azure SPECIFICALLY to support CPython 
development and users. As far as I know, ALL the Windows buildbots are running 
on Azure subscriptions that Microsoft provides (though managed by some awesome 
volunteers). You’ll see us at PyCon US under the biggest banner and we’ll have 
a booth filled with engineers and not recruiters. Crash reports from thousands 
of opted-in users come into our systems and have directly lead to both CPython 
and Windows bug fixes.

Meanwhile, most of the MinGW contributions have been complaints and drive-by 
patches. We (python-dev) are not opposed to supporting a second compiler for 
Windows, and honestly I’d love for extensions built with other compilers to be 
fully compatible with our main binary release, but the sacrifice involved in 
switching is significant and there’s no apparent commitment from the 
alternative options.

(Note that I’m not saying Microsoft’s support is conditional on our compiler 
being used. But our ability to contribute technically would be greatly reduced 
if we didn’t have the inside access that we do.)

And as has been mentioned, MSVC was selected before the other options were 
feasible. Python is a much older tool than those others, and so uses the tools 
that were best at the time.

So in my opinion at least, the reasoning for selecting MSVC was perfectly 
sound, and the reasoning for continuing with it is perfectly sound. 
Unwillingness on the part of package developers to not even test on Windows 
before releasing a wheel for it is not a compelling reason to change anything.

Cheers,
Steve

Top-posted from my Windows phone

From: Oleg Sivokon
Sent: Thursday, February 1, 2018 5:40
To: python-dev@python.org
Subject: [Python-Dev] Why is Python for Windows compiled with MSVC?

Hello list.

I'll give some background before asking my question in more detail.

I've been tasked with writing some infrastructure code that needs to talk to 
Kubernetes.  (Kubernetes is a popular software for managing and automating 
virtualization / containerization of cloud services).  One of the requirements 
was that the code be written in Python 3.X.

The tasks my code was supposed to perform on Kubernetes would be something like 
cluster creation from specification, deletion of all or parts of the cluster, 
providing realtime statistics of cluster usage etc.  There were few prototype 
scripts written in Bash using kubectl (official client written in Go).

My first reaction was to look for an official client for Kubernetes written in 
Python. There is one official client for Kubernetes, with a single maintainer, 
impossible to parse documentation, containing mostly generated code.  It is 
nigh impossible to use.  Here I need to explain that for whatever reason 
Kubernetes team decided to write their HTTP API in such a way that the server 
is "dumb" and the client must be "smart" in order to do anything useful.  For 
instance, if you have a description of your cluster, you cannot just send this 
description to the server and hope that it will know how to create the cluster 
from description.  You need to make multiple API calls (perhaps hundreds of 
them) to arrange for the server to create the cluster from description.

Since the official client is no help (it really only mirrors the HTTP API), I 
searched for other clients.  There are two more.  None is in good shape, and 
none comes even close to being able to do what kubectl can.

There is one more client that shells out calls to kubectl.  It implements only 
a small subset of kubectl commands, and... it's a lot of parsing of standard 
output with regular expressions and magic.

Well... I was given a lot of time to investigate other options for dealing with 
this project, so I decided, what if I can compile kubectl into a shared library 
and write a Python extension that links against that library.  And, indeed, 
after few days I came up with such an extension.  It worked!..  On Linux...

Now all I had to do was to re-create my success on Windows (most of the 
employees in my company use Windows).  At first I thought that I'd 
cross-compile on Linux using MinGW.  I compiled Go shared library into a DLL, 
then tried to compile my Python extension and... it didn't work.  I downloaded 
VirtualBox and some Windows images, etc... tried to compile on Windows.  It 
didn't work.  I started asking around, and was

Re: [Python-Dev] OS-X builds for 3.7.0

[Chris Barker]

On Wed, Jan 31, 2018 at 3:13 AM, Joni Orponen 
wrote:

> On Wed, Jan 31, 2018 at 12:43 AM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
>
>> And maybe we could even get rid of the "Framework" builds..
>>>
>>
>> Please do not. These make life easier for doing things the Apple way for
>> signed sandboxed applications.
>>
>> For the record, are you re-distributing the python.org builds, or
>> re-building yourself?
>>
>
> We are re-building ourselves.
>

Then it makes no difference to you if the pyton.org binaries are Framework
builds... though maybe you want the configure target available.

-CHB

-- 

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.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Chris Barker]

On Wed, Jan 31, 2018 at 4:20 AM, INADA Naoki  wrote:

> > Against the official CPython 3.6 (probably .3 or .4) release I see:
> > 1 that is 2.01x faster (python-startup, 24.6ms down to 12.2ms)
> > 5 that are >=1.5x,<1.6x faster.
> > 13 that are >=1.4x,<1.5x faster.
> > 21 that are >=1.3x,<1.4x faster.
> > 14 that are >=1.2x,<1.3x faster.
> > 5 that are >=1.1x,<1.2x faster.
> > 0 that are < 1.1x faster/slower.
> >
> > Pretty good numbers overall I think.
>


> Yay!!  Congrats for all of us!
>

I'm confused -- I _think_ these are performance improvements of the
Anaconda build over the python.org build for OS-X -- so congrats to the
Anaconda team :-)

But a hint that maybe we should do the python.org builds differently!

-CHB


-- 

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.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Terry Reedy]

On 1/31/2018 6:23 PM, Chris Barker wrote:
On Wed, Jan 31, 2018 at 4:20 AM, INADA Naoki > wrote:


> Against the official CPython 3.6 (probably .3 or .4) release I see:
> 1 that is 2.01x faster (python-startup, 24.6ms down to 12.2ms)
> 5 that are >=1.5x,<1.6x faster.
> 13 that are >=1.4x,<1.5x faster.
> 21 that are >=1.3x,<1.4x faster.
> 14 that are >=1.2x,<1.3x faster.
> 5 that are >=1.1x,<1.2x faster.
> 0 that are < 1.1x faster/slower.
>
> Pretty good numbers overall I think.

Yay!!  Congrats for all of us!


I'm confused -- I _think_ these are performance improvements of the 
Anaconda build over the python.org  build for OS-X -- 
so congrats to the Anaconda team :-)


But a hint that maybe we should do the python.org  
builds differently!


Ned Deily is in charge of the Mac build (as well as current release 
manager).  Within the last week, he revised the official builds (now 
two, I believe) for 3.7.0b1, due in a day or so.  One will be a future 
oriented 64-bit build.  The PR and What's New have more.


He may not be reading this thread, but will read MacOS tracker issues 
with a specific proposal, data and a patch.  Comparisons should be 
against the current master or an installed 3.7.0b1.


--
Terry Jan Reedy


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

Re: [Python-Dev] Why is Python for Windows compiled with MSVC?

[Gregory P. Smith]

TL;DR of Steve's post - MSVC is the compiler of choice for most serious
software on Windows. So we use it to best integrate with the world. There
is no compelling reason to change that.

The free-as-in-beer MSVC community edition is finally non-sucky (their
earlier efforts were crippled, they seem to have learned the lesson)

There are other viable Windows compilers.  If we want to support those in
CPython someone needs to contribute the work to do so, ongoing maintenance,
and buildbots.  I'd love to see a Clang based Windows build (Google Chrome
is built using that).  But I have no motivating reason to do the work.  I
*believe* such a build could be made to integrate and inter-operate fully
with MSVC builds and ABIs.  We could *probably* even make cross-compilation
of extensions from Linux -> Windows work that way.

We're highly unlikely to ever stop shipping python.org Windows binaries
built with anything other than MSVC unless Microsoft takes a turn toward
the dark side again.

-gps


On Wed, Jan 31, 2018 at 3:07 PM Steve Dower  wrote:

> Because every other supported platform builds using the native tools, so
> why shouldn’t the one with the most users?
>
>
>
> I’m likely biased because I work there and I’m the main intermediary with
> python-dev, but these days Microsoft is one of the strongest supporters of
> CPython. We employ the most core developers of any private company and we
> all are allowed work time to contribute, we provide full access to our
> development tools and platforms to all core developers and some prominent
> projects, we’ve made fixes, enhancements and releases or core products such
> as the CRT, MSVC, Visual Studio, Visual Studio Code, and Azure SPECIFICALLY
> to support CPython development and users. As far as I know, ALL the Windows
> buildbots are running on Azure subscriptions that Microsoft provides
> (though managed by some awesome volunteers). You’ll see us at PyCon US
> under the biggest banner and we’ll have a booth filled with engineers and
> not recruiters. Crash reports from thousands of opted-in users come into
> our systems and have directly lead to both CPython and Windows bug fixes.
>
>
>
> Meanwhile, most of the MinGW contributions have been complaints and
> drive-by patches. We (python-dev) are not opposed to supporting a second
> compiler for Windows, and honestly I’d love for extensions built with other
> compilers to be fully compatible with our main binary release, but the
> sacrifice involved in switching is significant and there’s no apparent
> commitment from the alternative options.
>
>
>
> (Note that I’m not saying Microsoft’s support is conditional on our
> compiler being used. But our ability to contribute technically would be
> greatly reduced if we didn’t have the inside access that we do.)
>
>
>
> And as has been mentioned, MSVC was selected before the other options were
> feasible. Python is a much older tool than those others, and so uses the
> tools that were best at the time.
>
>
>
> So in my opinion at least, the reasoning for selecting MSVC was perfectly
> sound, and the reasoning for continuing with it is perfectly sound.
> Unwillingness on the part of package developers to not even test on Windows
> before releasing a wheel for it is not a compelling reason to change
> anything.
>
>
>
> Cheers,
>
> Steve
>
>
>
> Top-posted from my Windows phone
>
>
>
> *From: *Oleg Sivokon 
> *Sent: *Thursday, February 1, 2018 5:40
> *To: *python-dev@python.org
> *Subject: *[Python-Dev] Why is Python for Windows compiled with MSVC?
>
>
>
> Hello list.
>
>
>
> I'll give some background before asking my question in more detail.
>
>
>
> I've been tasked with writing some infrastructure code that needs to talk
> to Kubernetes.  (Kubernetes is a popular software for managing and
> automating virtualization / containerization of cloud services).  One of
> the requirements was that the code be written in Python 3.X.
>
>
>
> The tasks my code was supposed to perform on Kubernetes would be something
> like cluster creation from specification, deletion of all or parts of the
> cluster, providing realtime statistics of cluster usage etc.  There were
> few prototype scripts written in Bash using kubectl (official client
> written in Go).
>
>
>
> My first reaction was to look for an official client for Kubernetes
> written in Python. There is one official client for Kubernetes, with a
> single maintainer, impossible to parse documentation, containing mostly
> generated code.  It is nigh impossible to use.  Here I need to explain that
> for whatever reason Kubernetes team decided to write their HTTP API in such
> a way that the server is "dumb" and the client must be "smart" in order to
> do anything useful.  For instance, if you have a description of your
> cluster, you cannot just send this description to the server and hope that
> it will know how to create the cluster from description.  You need to make
> multiple API calls (perhaps hundreds of them) to arrange for

[Python-Dev] "threading.Lock().locked()" is not documented

[Jesus Cea]

https://docs.python.org/3.6/library/threading.html doesn't document
"threading.Lock().locked()", and it is something quite useful.

In fact, it is used in "threading.py" itself. For instance, lines 109,
985, 1289.

Is there any reason to not document it?.

(I didn't investigate other objects in the module).

-- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz



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

[Python-Dev] [IMPORTANT] post 3.7.0b1 development now open

[Ned Deily]

Here we are: 3.7.0b1 and feature code freeze! Congratulations and
thanks to all of you who've contributed to the huge number of PEPs,
features, bug fixes, and doc changes that have gone into 3.7 since
feature development began back in September 2016, after 3.6.0b1,
3.6's feature freeze. Now that feature development for 3.7 is over,
the challenge is to put the finishing touches on the features and
documentation, squash bugs, and test test test.

In the cpython repo, there is now a 3.7 branch. Starting now, all PRs
destined for 3.7.0 should get cherry-picked from master to the 3.7
branch or just pushed to 3.7 if only applicable there. New features
should continue to be pushed to the master branch for release in 3.8;
no new features are now permitted in 3.7 unless you have contacted me
and we have agreed on an extension (and all granted extensions will
expire as of 3.7.0b2). As before, bug fixes appropriate for 3.6.x
should continue to be cherry-picked to the 3.6 branch. I've updated
the Developer's Guide to reflect the now current workflow. Let me
know if you find any bugs in it. Likewise, please contact me if you
have any questions about the workflow or about whether a change is
appropriate for 3.7 beta.

The cpython repo on Github has been updated. You should now find that
builds on the master branch produce a Python 3.8, rather than 3.7;
you may want to clean your build directory. And there is now a 3.7
branch that you will need to use for 3.7 builds and pushs. There were
several PRs that were merged to master over the last couple of days
since we started 3.7.0b1 release engineering. All but one of those
have been cherry-picked into the new 3.7 branch and you should have
seen messages for them. One was for a 3.8 feature and so was not
backported. At the moment, the new 3.7 buildbots may not be fully
operational but they should be soon. Likewise, the docs.python.org
may take up to 24 hours to reflect all the changes. Note that is the
first time we've done a feature freeze using our new git-based
workflow, so there's likely that there might be a glitch or something
overlooked. Please let us know if you suspect something or have a
question. I'll be around here and or #python-dev.

Also, don't forget to direct 3.8-related questions to Łukasz.  Welcome
on-board!

To recap:

2018-01-31: 3.7 branch open for 3.7.0; 3.8.0 feature development begins

2018-01-31 to 2018-05-21: 3.7.0 beta phase (no new 3.7 features)
   - push PRs for new features, bugs, regressions, doc fixes to the
master branch for release in 3.8
   - cherry-pick or push PRs for 3.7.0 (bug/regression/doc fixes) to the
new 3.7 branch
   - cherry-pick or push select PRs for important bug/regression/doc
fixes to 3.6 and 2.7 branches as appropriate
   - propose PRs to 3.5 and 3.4 branches for any identified security issues

2018-02-26: 3.7.0 beta 2 (next beta preview)

2018-03-26: 3.7.0 beta 3 (3.7.0 ABI freeze)

2018-04-30: 3.7.0 beta 4 (only critical and urgent fixes after this point)

2018-05-21: 3.7.0 release candidate 1 (3.7.0 code freeze, only any
emergency fixes afer this point)

2018-06-15: 3.7.0 release

2019-10-20: 3.8.0 release (next planned feature release, see PEP 569)


Thank you all again for your great efforts so far on 3.7!

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

[Python-Dev] [RELEASE] Python 3.7.0b1 is now available for testing

[Ned Deily]

On behalf of the Python development community and the Python 3.7 release
team, I'm happy to announce the availability of Python 3.7.0b1.  b1 is
the first of four planned beta releases of Python 3.7, the next major
release of Python, and marks the end of the feature development phase
for 3.7.  You can find Python 3.7.0b1 here:

https://www.python.org/downloads/release/python-370b1/

Among the new major new features in Python 3.7 are:

* PEP 538, Coercing the legacy C locale to a UTF-8 based locale
* PEP 539, A New C-API for Thread-Local Storage in CPython
* PEP 540, UTF-8 mode
* PEP 552, Deterministic pyc
* PEP 553, Built-in breakpoint()
* PEP 557, Data Classes
* PEP 560, Core support for typing module and generic types
* PEP 562, Module __getattr__ and __dir__
* PEP 563, Postponed Evaluation of Annotations
* PEP 564, Time functions with nanosecond resolution
* PEP 565, Show DeprecationWarning in __main__
* PEP 567, Context Variables

Please see "What’s New In Python 3.7" for more information.
Additional documentation for these features and for other changes
will be provided during the beta phase.

https://docs.python.org/3.7/whatsnew/3.7.html

Beta releases are intended to give you the opportunity to test new
features and bug fixes and to prepare their projects to support the
new feature release. We strongly encourage you to test your projects
with 3.7 during the beta phase and report issues found to
https://bugs.python.org as soon as possible.

While the release is feature complete entering the beta phase, it is
possible that features may be modified or, in rare cases, deleted up
until the start of the release candidate phase (2018-05-21). Our goal
is have no ABI changes after beta 3 and no code changes after rc1.
To achieve that, it will be extremely important to get as much exposure
for 3.7 as possible during the beta phase.

Attention macOS users: with 3.7.0b1, we are providing a choice of
two binary installers.  The new variant provides a 64-bit-only
version for macOS 10.9 and later systems; this variant also now
includes its own built-in version of Tcl/Tk 8.6.  We welcome your
feedback.

Please keep in mind that this is a preview release and its use is
not recommended for production environments.

The next planned release of Python 3.7 will be 3.7.0b2, currently
scheduled for 2018-02-26. More information about the release schedule
can be found here:

https://www.python.org/dev/peps/pep-0537/

--
  Ned Deily
  n...@python.org -- []

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

Re: [Python-Dev] Why is Python for Windows compiled with MSVC?

[Steven D'Aprano]

On Wed, Jan 31, 2018 at 03:04:04PM +, Oleg Sivokon wrote:

> Now, since Go won't compile with MSVC
[...]

Perhaps you should be asking Google why Go doesn't support the most 
popular C compiler on Windows.


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