[Python-Dev] [RELEASE] Python 3.7.0rc1 and 3.6.6rc1 are now available

2018-06-12 Thread Ned Deily 
Python 3.7.0rc1 and 3.6.6rc1 are now available. 3.7.0rc1 is the final
planned release preview of Python 3.7, the next feature release of
Python. 3.6.6rc1 is the the release preview of the next maintenance
release of Python 3.6, the current release of Python. Assuming no
critical problems are found prior to *2018-06-27*, the scheduled
release dates for 3.7.0 and 3.6.6, no code changes are planned
between these release candidates and the final releases. These
release candidates are intended to give you the opportunity to test
the new features and bug fixes in 3.7.0 and 3.6.6 and to prepare your
projects to support them. We strongly encourage you to test your
projects and report issues found to bugs.python.org as soon as
possible. Please keep in mind that these are preview releases and,
thus, their use is not recommended for production environments.
Attention macOS users: there is now a new installer variant for macOS
10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant
will become the default version when 3.7.0 releases. Check it out!

You can find these releases and more information here:
https://www.python.org/downloads/release/python-370rc1/
https://www.python.org/downloads/release/python-366rc1/

--
  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] Microsoft to acquire GitHub for $7.5 b

2018-06-12 Thread Mariatta Wijaya 
Backing up GitHub data has been brought up since the time we migrated to
GitHub, and being tracked here: https://github.com/pytho
n/core-workflow/issues/20

TL;DR We'll be using GitHub's new Migrations API
 to download archived
GitHub data of CPython. Ernest is helping us get set up with daily backups
of CPython repo to be stored within The PSF's infrastructure.

Mariatta

On Thu, Jun 7, 2018 at 11:24 AM, Chris Angelico  wrote:

> On Fri, Jun 8, 2018 at 3:33 AM, Chris Barker - NOAA Federal via
> Python-Dev  wrote:
> > Any service could change or fail. Period.
> >
> > So we shouldn’t want valuable information about Python development
> > only in gitHub.
> >
> > I don’t know how hard it is to backup / mirror an entire repo — but it
> > sure seems like a good idea.
>
> There are two separate concerns here:
>
> 1) How do we get a full copy of all of CPython and its change history?
>
> 2) How do we get all the non-code content - issues, pull requests,
> comments?
>
> The first one is trivially easy. *Everyone* who has a clone of the
> repository [1] has a full copy of the code and all history, updated
> every time 'git pull' is run.
>
> The second one depends on GitHub's exporting facilities; but it also
> depends on a definition of what's important. Maybe the PSF doesn't
> care if people's comments at the bottoms of commits are lost (not to
> be confused with commit messages themselves, which are part of the
> repo proper), so it wouldn't matter if they're lost. Or maybe it's
> important to have the contents of such commits, but it's okay to
> credit them to an email address rather than linking to an actual
> username. Or whatever. Unlike with the code/history repo, an imperfect
> export is still of partial value.
>
> ChrisA
>
> [1] Barring shallow clones, but most people don't do those
> ___
> 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/
> mariatta.wijaya%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] Some data points for the "annual release cadence" concept

2018-06-12 Thread Guido van Rossum 
So, to summarize, we need something like six for C?

On Tue, Jun 12, 2018 at 5:38 AM, Nick Coghlan  wrote:

> Hi folks,
>
> Given the discussion of adopting an annual release cadence at the language
> summit this year [1], this recent Jakarta (nee Java) EE announcement caught
> my attention: https://www.eclipse.org/ee4j/news/?date=2018-06-08#release-
> cadence
>
> JEE are switching to an annual update cadence for the base platform, with
> quarterly updates for individual components.
>
> Since we last seriously discussed potential release cadence changes back
> in 2012 (with PEPs 407 and 413 [2,3]), that means JEE joins GCC switching
> to an annual release cadence from GCC 5 back in 2015 (see [4]), while
> clang/LLVM have been doing twice-annual feature releases for several years
> now [5].
>
> Most directly relevant to Python would be the Node.js maintenance
> lifecycle initially developed in 2013, and evolved since then:
> https://github.com/nodejs/Release
>
> That's quite a fast lifecycle (even faster than we're considering - they
> do a release every 6 months, with every 2nd release being supported for 3
> 1/2 years), but one of the keys to making it work in practice is
> https://github.com/nodejs/nan
>
> The gist of the "Native Abstractions for Node.js" project is that it aims
> to provide a stable API & ABI for third party libraries to link against,
> but *without* having to keep those interfaces stable in V8/Node.js itself.
>
> In the Python world, the closest current equivalent would by SIP for PyQt
> projects [6], which provides a shim layer that allows version independent
> extension modules to target CPython's native stable ABI with the aid of a
> single version specific dependency (so only the "sip" wheel itself needs to
> be rebuilt for each new Python version, not every extension module that
> depends on it).
>
> So I expect a release cadence change would be a lot more viable now than
> it would have been 6 years ago, but I also suspect actually getting there
> will require a non-trivial amount of effort invested in generalising the
> SIP model such that the stable ABI gets a *lot* easier for projects to
> realistically target (including for cffi and Cython generated extension
> modules).
>
> Cheers,
> Nick.
>
> [1] https://lwn.net/Articles/755224/
> [2] https://www.python.org/dev/peps/pep-0407/
> [3] https://www.python.org/dev/peps/pep-0413/
> [4] https://gcc.gnu.org/releases.html
> [5] https://releases.llvm.org/ (Note: LLVM switched to twice-yearly X.0.0
> releases in 2017, but were doing twice yearly X.Y releases for some time
> before that)
> [6] https://pypi.org/project/SIP/
>
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Some data points for the "annual release cadence" concept

2018-06-12 Thread Nick Coghlan 
Hi folks,

Given the discussion of adopting an annual release cadence at the language
summit this year [1], this recent Jakarta (nee Java) EE announcement caught
my attention:
https://www.eclipse.org/ee4j/news/?date=2018-06-08#release-cadence

JEE are switching to an annual update cadence for the base platform, with
quarterly updates for individual components.

Since we last seriously discussed potential release cadence changes back in
2012 (with PEPs 407 and 413 [2,3]), that means JEE joins GCC switching to
an annual release cadence from GCC 5 back in 2015 (see [4]), while
clang/LLVM have been doing twice-annual feature releases for several years
now [5].

Most directly relevant to Python would be the Node.js maintenance lifecycle
initially developed in 2013, and evolved since then:
https://github.com/nodejs/Release

That's quite a fast lifecycle (even faster than we're considering - they do
a release every 6 months, with every 2nd release being supported for 3 1/2
years), but one of the keys to making it work in practice is
https://github.com/nodejs/nan

The gist of the "Native Abstractions for Node.js" project is that it aims
to provide a stable API & ABI for third party libraries to link against,
but *without* having to keep those interfaces stable in V8/Node.js itself.

In the Python world, the closest current equivalent would by SIP for PyQt
projects [6], which provides a shim layer that allows version independent
extension modules to target CPython's native stable ABI with the aid of a
single version specific dependency (so only the "sip" wheel itself needs to
be rebuilt for each new Python version, not every extension module that
depends on it).

So I expect a release cadence change would be a lot more viable now than it
would have been 6 years ago, but I also suspect actually getting there will
require a non-trivial amount of effort invested in generalising the SIP
model such that the stable ABI gets a *lot* easier for projects to
realistically target (including for cffi and Cython generated extension
modules).

Cheers,
Nick.

[1] https://lwn.net/Articles/755224/
[2] https://www.python.org/dev/peps/pep-0407/
[3] https://www.python.org/dev/peps/pep-0413/
[4] https://gcc.gnu.org/releases.html
[5] https://releases.llvm.org/ (Note: LLVM switched to twice-yearly X.0.0
releases in 2017, but were doing twice yearly X.Y releases for some time
before that)
[6] https://pypi.org/project/SIP/


-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python3 compiled listcomp can't see local var - bug or feature?

2018-06-12 Thread Rob Cliffe via Python-Dev 

Ah yes, I see what you mean:

class Test():
   x = 1
   print (x) # Prints 1
   print([x+i for i in range(1,3)])  # NameError (x)

Anyway, I  apologise for posting to Python-Dev on was a known issue, and 
turned out to be more me asking for help with development with Python, 
rather than development of Python.  (My original use case was a 
scripting language that could contain embedded Python code).  Thanks to 
Nick for his original answer.


Rob Cliffe


On 11/06/2018 23:31, Eric Fahlgren wrote:
On Mon, Jun 11, 2018 at 3:10 PM Rob Cliffe via Python-Dev 
mailto:python-dev@python.org>> wrote:


Skip, I think you have misunderstood the  point I was making.  It was
not whether the loop variable should leak out of a list
comprehension.
Rather, it was whether a local variable should, so to speak, "leak
into"
a list comprehension.  And the answer is: it depends on whether
the code
is executed normally, or via exec/eval.  Example:

def Test():
       x = 1
       print([x+i for i in range(1,3)])          # Prints [2,3]
   exec('print([x+i for i in range(1,3)])') # Raises NameError (x)
Test()

I (at least at first) found the difference in behaviour surprising.


​Change 'def' to 'class' and run it again.  You'll be even more 
surprised.​


 
	Virus-free. www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


___
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] 3.7.0rc1 and 3.6.6rc1 now tagged - on to final!

2018-06-12 Thread Ned Deily 
An update: 3.7.0rc1 and 3.6.6rc1 are now tagged and we now move on to the
final stages for 3.7.0 and for 3.6.6. The source code has been shipped to
our factory (in a tariff-free zone!) where the elves will produce the
final bits for the release. They promise to be done soon so stay tuned
for the release announcements later today.

In the meantime, the 3.7 and 3.6 branches in the cpython repo are open
for merges. As of the rc1 cutoffs (tags v3.7.0rc1 and v3.6.6rc1 in the
cpython repo), expect merges to 3.7 to appear in 3.7.1 and merges to 3.6
to appear in 3.6.7. Please continue to treat the 3.7 branch as if it were
already released and in maintenance mode. Please continue to pay
attention to CI test failures and buildbot test failures and see if you
can help resolve them. If you find something that may affect either final
release, please make sure to open a new issue on bugs.python.org, or
update an existing issue, and set the priority to "release blocker". As
always, improving the documentation never ceases so keep those updates
coming in. Prior to 3.7.0 final and 3.6.6 final, I will review doc
changes that have been merged and consider cherry-picking them into the
release materials. By the way, don't be fooled: if you build Python from
the 3.7 branch at the moment, the version will be "3.7.0rc1+" but changes
merged will be in 3.7.1; similarly for 3.6.

The clock is now ticking: 15 days until the final releases. Please do
what you can to encourage exposure and testing by ourselves and our
downstream users.

Once again, I want to thank everyone who has been involved so far in
helping us through the 3.7 endgame and who have given up their
personal time to work on making Python better. I remain deeply grateful.

--Ned

Upcoming dates:
- 2018-06-27 3.7.0 final !!! and 3.6.6 final !!
- 2018-07-xx 3.7.1
- 2018-09-xx 3.6.7


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