Mailman 3 February 2018 - python-committers

GitHub: remove the "needs backport to 3.5" label?
by Victor Stinner 20 Aug '19

20 Aug '19

Hi, Python 3.5 entered security fix only mode. Should we now remove the "needs backport to 3.5" label? Other security only branches don't have this label neither (3.3 and 3.4). Victor

6 11

Licences for PyCharm and other JetBrains products
by Vinay Sajip 17 Dec '18

17 Dec '18

Recently I received 20 one-year licenses from JetBrains for the PyCharm IDE (Professional) and other JetBrains products (the licenses cover their "All Products Pack") for use in Python development. There are 11 licenses available - of the licenses I asked for last year, nine people took them up, so those are in use and come out of the allocation of 20. Those of you who took up the licences last time should find that the tools continue to work normally. The licences expire on 27 November 2018. If any others of you are interested in using these licenses, let me know off-list and I will forward the license access details to you. To access the licenses, you will need to have (or create) a JetBrains account. Regards, Vinay Sajip

2 1

[RELEASE] Python 3.7.0b2 is now available for testing
by Ned Deily 28 Feb '18

28 Feb '18

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.0b2. b2 is the second 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.0b2 here: https://www.python.org/downloads/release/python-370b2/ 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: as of b1, there is a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default version when 3.7.0 releases. Check it out! 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.0b3, currently scheduled for 2018-03-26. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0537/ -- Ned Deily nad(a)python.org -- []

1 0

3.7.0b2 code cutoff soon!
by Ned Deily 26 Feb '18

26 Feb '18

Just a reminder that 3.7.0b2 is almost upon us. Please get your feature fixes, bug fixes, and documentation updates in before 2018-02-26 ~23:59 Anywhere on Earth (UTC-12:00). That's a little over 1.5 days from now. Also, as previously noted, for those of you who asked for and received extensions for a few remaining 3.7.0 features, those extensions expire as of the b2 cutoff so please plan accordingly. Looking ahead, we need to start locking down 3.7.0 so that our downstream users, that is, third-party package developers, Python distributors, and end users, can test their code with confidence that the actual release of 3.7.0 will hold no unpleasant surprises. So please assume that the 3.7.0 ABI will be frozen as of beta 3, in 4 weeks on 2018-03-26, and that only doc updates and the kinds of bug fixes appropriate for a maintenance release should be going into the 3.7 branch after 3.7.0b3 without further discussion. Thanks again for all of your hard work towards making 3.7.0 yet another great release! --Ned -- Ned Deily nad(a)python.org -- []

1 0

Issues with hundreds of commits being opened and closed -- what's going on?
by Guido van Rossum 16 Feb '18

16 Feb '18

Occasionally I receive a sequence of emails from GitHub where a PR is requesting my review by some user, the-knights-who-say-ni responds with a CLA request, and then Bedevere closes it, without comment. Latest example: https://github.com/python/cpython/pull/5693 This seems to be some kind of user error -- the GitHub description is typically something like "<user> wants to merge 398 commits into master from 3.5". But this happens so frequently I would like to prevent this user error from happening in the first place. Does anyone understand what these users are doing that causes such PRs to be created? -- --Guido van Rossum (python.org/~guido)

4 4

Auto-merge the backport PR with one core dev approval and all passing CI
by Mariatta Wijaya 13 Feb '18

13 Feb '18

Hi, I will have some time in the next couple weeks to work on miss-islington. I'm thinking to work on this issue: https://github.com/python/miss-islington/issues/44 The idea is to have miss-islington automatically merge the backport PR, after all CI passed and after a core dev approved the PR. I think this will save us a lot of button clicks and time. Just wanted to check if everyone is pretty much +1 on this, before I start writing the code. Some notes and implicationss: - The expectation is that the commit message has already been cleaned up on the master branch - It already knows how to replace the # to GH- in the commit message - miss-islington will need write access to CPython - git log it will show miss-islington (bot) as the committer - If you still want to do the merge yourself, then just don't approve miss-islington's PR. What does everyone here think about all that? Thanks. Mariatta Wijaya

5 8

Re: [python-committers] [RELEASED] Python 3.4.8 and Python 3.5.5 are now available
by Larry Hastings 11 Feb '18

11 Feb '18

Actually, it was updated on the server, but somehow the old version was sticking around in the CDN cache. I "purged" it and it's fine now. Weird that it would linger this long! Cheers, //arry/ On 02/10/2018 03:20 AM, Serhiy Storchaka wrote: > 05.02.18 02:35, Larry Hastings пише: >> On behalf of the Python development community, I'm happy to announce >> the availability of Python 3.4.8 and Python 3.5.5. >> >> Both Python 3.4 and 3.5 are in "security fixes only" mode. Both >> versions only accept security fixes, not conventional bug fixes, and >> both releases are source-only. >> >> >> You can find Python 3.4.8 here: >> >> https://www.python.org/downloads/release/python-348/ >> >> >> And you can find Python 3.5.5 here: >> >> https://www.python.org/downloads/release/python-355/ > > Online documentation for 3.5 is not updated yet. > > > https://docs.python.org/3.5/whatsnew/changelog.html#python-3-5-5 >

1 0

Re: [python-committers] cherry picking, miss islington, and generated files
by Mariatta Wijaya 07 Feb '18

07 Feb '18

Sure, I sort of asked this in the past: what are the generated files, how to identify them, is there a pattern? I need to dig up that thread and find out if anyone answered. It's been a while :) Usually there would be conflict in backport though. It was suggested that cherry-picker can regenerate the files and resolve the conflict. Your suggestion of having miss Islington comment on the PR sounds good too. On Feb 2, 2018 8:17 PM, "Barry Warsaw" <barry(a)python.org> wrote: I’m in the process of back porting a change which touches importlib and requires regeneration of Python/importlib.h and Python/importlib_external.h. The original fix on master: https://github.com/python/cpython/pull/5481 Miss Islington’s back port to 3.7: https://github.com/python/cpython/pull/5498 Miss Islington was not able to auto-pick this into 3.6, which makes sense. I got a little concerned though that the back port touches those two generated files, and didn’t feel comfortable just pushing the Big Green Button. I chatted with Brett and he also agreed that the merge should probably be done manually. So for the 3.7 merge, I actually followed the GitHub CLI merge instructions, regenerated the .h files, pushed the branch, and opened a new PR: https://github.com/python/cpython/pull/5503/files Once CI passed, I hit the BGB and the merge occurred as normal. For the 3.6 fix, I used cherry_pick, resolved the conflicts manually, regen’d the header files, pushed the branch, and submitted a new PR: https://github.com/python/cpython/pull/5504 This one’s still running CI, but if it passes, I’ll merge it. I wanted to mention this because maybe Miss Islington should flag, warn, or otherwise indicate when autogenerated files are being merged? Are there any other files other than the importlib .h files that we should take extra care with? Cheers, -Barry _______________________________________________ python-committers mailing list python-committers(a)python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

5 12

[RELEASED] Python 3.4.8 and Python 3.5.5 are now available
by Larry Hastings 05 Feb '18

05 Feb '18

On behalf of the Python development community, I'm happy to announce the availability of Python 3.4.8 and Python 3.5.5. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.8 here: https://www.python.org/downloads/release/python-348/ And you can find Python 3.5.5 here: https://www.python.org/downloads/release/python-355/ Happy Pythoning, //arry/

1 0

cherry picking, miss islington, and generated files
by Barry Warsaw 03 Feb '18

03 Feb '18

I’m in the process of back porting a change which touches importlib and requires regeneration of Python/importlib.h and Python/importlib_external.h. The original fix on master: https://github.com/python/cpython/pull/5481 Miss Islington’s back port to 3.7: https://github.com/python/cpython/pull/5498 Miss Islington was not able to auto-pick this into 3.6, which makes sense. I got a little concerned though that the back port touches those two generated files, and didn’t feel comfortable just pushing the Big Green Button. I chatted with Brett and he also agreed that the merge should probably be done manually. So for the 3.7 merge, I actually followed the GitHub CLI merge instructions, regenerated the .h files, pushed the branch, and opened a new PR: https://github.com/python/cpython/pull/5503/files Once CI passed, I hit the BGB and the merge occurred as normal. For the 3.6 fix, I used cherry_pick, resolved the conflicts manually, regen’d the header files, pushed the branch, and submitted a new PR: https://github.com/python/cpython/pull/5504 This one’s still running CI, but if it passes, I’ll merge it. I wanted to mention this because maybe Miss Islington should flag, warn, or otherwise indicate when autogenerated files are being merged? Are there any other files other than the importlib .h files that we should take extra care with? Cheers, -Barry

1 0