Mailman 3 December 2017 - 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

Requirements to get the "bug triage" permission?
by Victor Stinner 25 Jan '18

25 Jan '18

Hi, I identified some active contributors and I would like to offer them to get the "bug triage" permission. What's the requirements to give such permissions to someone? On my "Different stages of core developers" "lader", it's the 3rd stage ("step"?): http://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_cor… Requirements to become a core developer (get the "commit bit") are now written down: http://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_cor… It would be nice to write down requirements to get the bug triage permission. IMHO the requirements are quite low: * at least one commit merged in Python * signed the CLA * be nice and respectful * don't close a bug if it's not well understood to not "loose" information (closed bugs are ignored in search by default, and hidden from the main page). Did it happen in the past that we removed the bug triage permission to someone who abused this power? Maybe we can give some guide lines on how to behave on the bug tracker? Responsability for bug tracker: * Request more information if a report is incomplete * Ping original reporters if they don't reply * Adjust Python version, component, bug type, etc. * Rewrite the issue title if needed * Close duplicated bugs as DUPLICATE * Close irrevelant bugs as NOTABUG The exact behaviour on the bug tracker is not specified. For example, when someone asks for help on code, I close the issue and suggest to use a different forum to get help, without giving examples of forums (since I simply don't know them :-)). When the reported issue described a legit Python behaviour, I try to explain the rationale of the behaviour before closing the issue as "not a bug". Sometimes I'm just tired of the 4th bug report on "floating point rouding issue" and just give the link to the FAQ without explaining anything. Devguide §Helping Triage Issues https://devguide.python.org/tracker/#helptriage Victor

9 21

Security: please enable 2-factor authentication on GitHub and your email
by Victor Stinner 07 Jan '18

07 Jan '18

Hi, On 12 February 2017, I got an email from Bitbucket: "we detected a suspicious login to your Bitbucket Cloud account. We believe that a malicious actor used a large database of usernames and passwords stolen from third party services to access Bitbucket Cloud accounts. We can't know exactly how your password was first compromised, however it was not caused by Atlassian." Wow. That's huge for me: * I was using the same password for almost all services (except of Gmail): GitHub, Bitbucket, a lot of web services. In term of security, that's "bad". I know... but it is convenient... * I had a few different password that I stored in clear text in a text file which was hosted on a private repository on... Bitbucket While *now* I'm quite sure that the hacker only succeed to log in but didn't notice my password file, it was a good "opportunity" to upgrade my security... By the way, I suggest you to subscribe to https://haveibeenpwned.com/ which is a service to be notified if one of the service that you are using have seen "pwned". Using victor.stinner(a)gmail.com you can see "Breaches you were pwned in: Dailymotion (october 2016) and GeekedIn (August 2016)". (There is also a pastebin with my email, but it's just statistics on Mercurial, nothing sensitive :-)) The question is no more if you have been hacked, but how much time do you have before one of the services that you are using will be hacked... haveibeenpwned.com only reference a few breaches that has been made public... It was an electric shock for me. I immediately changed the password of the most critical services for me: GitHub, Bitbucket and many others. I generated a random password of +10 characters (using KeePassX). I started to use KeePassX password manager to stop storing passwords in clear text, with a master passphrase to encrypt all these passwords. I also acquired a Yubikey Nano. It's 50$. You may think that it's expensive. But the question is more how much do you estimate all your data of all your computers? Less than 50$, seriously? :-) The next step was to enable 2-factor authentication on GitHub and Bitbucket: * Configure the yubikey to generate an OTP for GitHub (for "long press" on the key) * Firefox: install https://addons.mozilla.org/fr/firefox/addon/u2f-support-add-on/ to use Yubikey with GitHub (sadly, the plugin doesn't work with Bitbucket nor Google yet) * Enable 2-factor auth on GitHub and Bitbucket using Yubikey * Print two-step recoverty codes on paper and keep it safe somewhere If you cannot affort a Yubikey, don't or cannot use it, you may want to use FreeOTP: free OTP application for a smartphone (I'm using it on Android), usable with GitHub, Bitbucket, Google, etc. It's not exclusive, you can have multiple 2-factor keys (Yubikey, FreeOTP, something else). Oh, my explanation makes the assumption that you all already enabled 2-factor auth on your email, right? :-) If you wasn't aware: email is simply the *most* critical part of your whole online data. If a hacker gets access to your email, you already lost all your online accounts... For Gmail users: you may have a look at https://myaccount.google.com/security as well. Maybe remove old services that have access to your Google account? After the hack, I also generated a new SSH key, even if it wasn't stored online and is encrypted by a passphrase. Just because I was using the same key since many years. I chose to use the new modern ed25519 key format. It uses an elliptic curve rather than RSA, it's a different kind of security. While I don't know if it's more secure, I read that it's faster :-) https://en.wikipedia.org/wiki/EdDSA I was able to use this new key formats on all services... except Launchpad. Changing a private SSH key isn't easy: * You have to install the new SSH on most services that you are using * You have to manually remove the old SSH key from *all* services that you are using (there is no global "SSH revokation" service...) * I used ~/.ssh/known_hosts to get most services, but also updated GitHub, Bitbucket, etc. * There are a few other services like psf-salt/psf-chef where you may also want to see your SSH key updated * The question is then if the old SSH key must be removed... the problem is that I never tried to keep track of services that I'm using through SSH, so I decided to keep the old SSH key (outside ~/.ssh). In practice, I'm only using my new SSH private since longer than 6 months and I was never blocked. I also had trouble to get working SSH agent on Gnome for my ed25519 key, but I succeeded to enable the regular ssh-agent using systemd --user. Tell me if you want instructions for this part as well. Victor

17 56

Travis-CI breakdown
by Antoine Pitrou 01 Jan '18

01 Jan '18

Hi, Do we have a contact over at Travis-CI? Their Linux build infrastructure has become crazily slow lately, something is clearly going wrong. Regards Antoine.

2 2

Date of the Python Language Summit?
by Victor Stinner 19 Dec '17

19 Dec '17

Hi, I'm starting to organize my travel to Cleveland for Pycon US 2018. I would like to know when will be the Python Language Summit to be able to decide how many nights I will stay. The hotel is usually a huge part of the budget. https://us.pycon.org/2018/ May 9,10: Tutorials May 11-13: Talks May 14-17: Sprints My preference would be to skip the two tutorial days, so organize the language summit after the talks. But it is also interesting to have the summit before talks, so we can have more time to discuss proposed ideas... Maybe the best would be the organizee the summut Thursday afternoon (May 10)? Victor

2 1

[RELEASE] Python 3.6.4 is now available
by Ned Deily 19 Dec '17

19 Dec '17

On behalf of the Python development community and the Python 3.6 release team, I am happy to announce the availability of Python 3.6.4, the fourth maintenance release of Python 3.6. Detailed information about the changes made in 3.6.4 can be found in the change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-4-final Please see "What’s New In Python 3.6" for more information about the new features in Python 3.6: https://docs.python.org/3.6/whatsnew/3.6.html You can download Python 3.6.4 here: https://www.python.org/downloads/release/python-364/ The next maintenance release of Python 3.6 is expected to follow in about 3 months, around the end of 2018-03. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ Enjoy! -- Ned Deily nad(a)python.org -- []

1 0

Julien Palard not seen as a core dev on the bug tracker
by Victor Stinner 18 Dec '17

18 Dec '17

Hi, Julien Palard has been promoted as a core developer at December 8th: https://devguide.python.org/developers/#permissions-history But he is still not seen as a core dev on the bug tracker: https://bugs.python.org/user23063 His nick name is "mdk". Can someone please fix his bpo account? Devguide: https://devguide.python.org/coredev/#issue-tracker Victor

2 3

AppVeyor builds broken
by Antoine Pitrou 14 Dec '17

14 Dec '17

Hello, It seems AppVevor builds (and generally Windows builds) have been broken for some time with a failure in test_distutils: https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.9471#L2040 ====================================================================== ERROR: test_get_exe_bytes (distutils.tests.test_bdist_wininst.BuildWinInstTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\projects\cpython\lib\distutils\tests\test_bdist_wininst.py", line 24, in test_get_exe_bytes exe_file = cmd.get_exe_bytes() File "C:\projects\cpython\lib\distutils\command\bdist_wininst.py", line 361, in get_exe_bytes f = open(filename, "rb") FileNotFoundError: [Errno 2] No such file or directory: 'C:\\projects\\cpython\\lib\\distutils\\command\\wininst-14.12.exe' ---------------------------------------------------------------------- Regards Antoine.

3 2

Saying hello as a new core dev
by Julien Palard 13 Dec '17

13 Dec '17

Hi, python-committers! That's huge, for me, to receive this notification "Your now a core developer, congratulations!" thanks everyone here! And waw, your messages in your votes to bring me in are heartwarming, as I said yesterday they validate, again and again, the ancient adage "Come for the language, stay for the community". -- Julien Palard https://mdk.fr

3 2

Fwd: What happens if I loose my password, 2FA key and recovery key
by Victor Stinner 12 Dec '17

12 Dec '17

For the ones who are worried about losing all credentials for their GitHub account, here are some official answers from GitHub support. Victor ---------- Forwarded message ---------- From: Michael (GitHub Staff) <support(a)github.com> Date: 2017-12-12 11:05 GMT+01:00 Subject: Re: What happens if I loose my password, 2FA key and recovery key To: Victor Stinner <victor.stinner(a)gmail.com> Hi Victor, Thanks for getting in touch. To address your questions: The question is what happens if you loose your password, your 2FA key and your recovery key... Ok, it's unlikely, but it's a real question. If you were to lose access to all of your 2FA credentials, I'm afraid we wouldn't be able to disable 2FA for you, for security reasons. For this reason, we recommend setting up one or more fallbacks. One way of safeguarding recovery keys is storing them in an encrypted password manager like 1Password or LastPass, which often have cloud backup capabilities. The second question is if the email account comes into the play as the last attempt to recover access to the GitHub account. The email and password associated with an account provide one factor of authentication. If 2FA is enabled, a second factor is required. In the case of someone losing access to all 2FA credentials, but still having access to the email associated with an account, we aren't able to disable 2FA, but can release the email address from the account. This would then allow the user to register the email address to a new account. Additionally, any contributions associated with that email address would follow along to the new account. At present, we have a range of fallbacks, which I'll list below. It's a good idea to use more than one, while also being mindful of not creating too much exposure. *Download your recovery codes.* This is far and away the best way to make sure you don't get locked out of your account. If you ever disable and then re-enable 2FA, be sure to download the new codes we generate as the old ones will no longer work. https://help.github.com/articles/downloading-your-two-factor-authentication- recovery-codes *Set a fallback number.* As long as your phone wasn't lost, you'll be able to regain access to your account in the amount of time it takes to receive an SMS. https://help.github.com/articles/setting-a-fallback-authentication-number *Add a security key.* Phone got stolen *and* you lost your recovery codes? Today is turning into a rough day, but you'll still have access to your account if you have a FIDO U2F security key added to your account. https://help.github.com/articles/configuring-two-factor-authentication-via- fido-u2f *Store a recovery token* If you use Facebook, you're now able to store a 2FA recovery token with your account. Here's how: https://help.github.com/articles/generating-and-storing-an-account-recovery- token *Set up an SSH key* We’re sometimes able to recover an otherwise locked out account if there’s an SSH key set up. You can add one by heading to: https://help.github.com/articles/adding-a-new-ssh-key- to-your-github-account/ Let me know if you have any questions or if there's anything else we can help with! Best regards, Michael

1 0

2FA: only needed at the *first* GitHub login, not needed for commits
by Victor Stinner 12 Dec '17

12 Dec '17

Hi, On the "Security: please enable 2-factor authentication on GitHub and your email" thread that I started, I see many people afraid of being annoyed everyday by 2FA (2-factor authentication, called "Authentication code" in GitHub). Let me explain how GitHub uses 2FA. * Let's say that you are not logged on GitHub (or log out to test yourself). * Log in GitHub: enter email and password, then you are asked for an "Authentication code". * You're logged in, congrats :-) * Close Firefox * Open Firefox, go to GitHub: you are already logged in. No more password nor Authentication code asked. Hum... that's it :-) I don't know how long the GitHub cookie remains valid, but it's very rare (maybe once per month? or once every 3 months??) for me to have to log in again. And usually, it's because I log out on purpose. Ok, now you can to push a pull request using SSH: * Step 1: git push (...) * There is no step 2 :-) There is no 2FA here. If I understood correctly, for HTTPS, there is no 2FA neither. So where is the 2FA? * New log in The 2FA is not needed for: * (If you are already logged in) Disabling 2FA doesn't require an authentication code. I just checked for you :-) * Adding a new SSH key to your account only requires your password, but the authentication code is also accepted instead of the password So what is the point of 2FA? It protects the log in. If an attacker has your password without the 2FA key, they are unable to log in. >From what I see, the 2FA doesn't protect against pushing commits if the attacker steal your SSH key or your HTTPS password. My understanding is that it's more common to get a password stolen than a SSH key. While you have to write the password regulary in web forms, GitHub only requires your SSH *public key* (only asked you, when adding a new key). The risk of leaking a SSH private key by mistake is much lower. For example, a browser doesn't ask you to store your SSH private key, only your password. For HTTPS: well, try to avoid HTTPS and prefer SSH? :-) A few months ago, using a Yubikey is Firefox required a plugin. Good news: since Firefox 57 (or even Firefox 56), U2F support is now builtin! But it's still experimental and so disabled by default (it's a simple flag that has to be set to true in about:config): https://www.yubico.com/2017/11/how-to-navigate-fido-u2f-in-firefox-quantum/ Google has the same 2FA design. It stores a cookie and so once you are logged on your computer, the 2FA is no more used. There is a check box like "[x] Remember this computer" or something like that. The 2FA matters you someone tries to use your password on a different computer. At work, I have a different experience with 2FA. It's much more stricter. I have to use my 2FA at least once a day, or more frequently depending on the services that I have to use. So yeah, I understand that some people who already suffer from that don't want to be annoyed on the Python project. Victor

2 1

Official python-dev docker images
by Barry Warsaw 10 Dec '17

10 Dec '17

As part of the importlib_resources skunkworks project Brett and I have been working on (just announced), we’ve also put together a nice Docker image that we’re using for our automated testing. This image is based on Ubuntu 16.04 and provides the latest stable releases of Python 2.7, and 3.4-3.6, along with a mostly up-to-date git checkout of master, currently Python 3.7 of course. Once 3.7 is released to beta, we intend to track its release tarballs too. We also install a few other commonly needed tools, like pip, git, unzip, wget, mypy, and tox. Here’s the project repo: https://gitlab.com/python-devs/ci-images Huge shout out to Abhilash Raj who helped us clean up and compactify the image, and also for setting up automated publishing to quay.io. In case you weren’t aware, Abhilash is who I passed GNU Mailman project leadership to, so he has a lot of Python experience, and a ton of expertise in the image space. He’s an amazing amount of work to improve the quality of this image! Brett and I want to promote this more widely within the Python community as the “official Python Docker image” that projects can use in their own testing environments, or base their own images on it. We wanted to give you guys a heads up first to get your feedback, and maybe thoughts on the best places to promote this, e.g. on the python.org website or other places. We welcome your participation too of course! I’m happy to give write access to the project to any Python committer who wants to help. Cheers, -Barry, Brett, Abhilash

4 8

Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug)
by Victor Stinner 10 Dec '17

10 Dec '17

Hi, For your information, I just sent emails to Julien, Cheryl and Sanyam to notify them that I will their mentor during one month. I asked them to ask me to double check before merging a pull request (Julien) or closing a bug (Cheryl and Sanyam). Since I'm trying for formalize the whole process to become a core dev, I kept a copy of my emails to serve as template for future mentors: https://github.com/vstinner/misc/blob/master/cpython/mentor_core_dev_email.… https://github.com/vstinner/misc/blob/master/cpython/mentor_bug_triage_emai… By the way, I'm now working on the "Process to become a core developer" document (maybe becoming a PEP later?) at: https://github.com/vstinner/misc/blob/master/cpython/pep-core_dev_process.r… (I almost didn't change since I sent it to python-committers) Victor

8 9

RFC: Process to become a core developer
by Victor Stinner 09 Dec '17

09 Dec '17

Hi, I'm working on a process to describe how a contributor becomes a core developer. The purpose is to be transparent, list "requirements" and responsabilities to the contributor, and have written rules to help to take a fair decision. This document is a draft. I chose to post it on python-committers. I expect that we would have to iterate on it multiple times until we can reach a consensus to agree on the process. While the process has many details, it must be seen more as a guideline than strict rules. Note: I'm trying to avoid gender to be inclusive when mentioning a contributor by using "they" or "their". I'm not sure that it's correct in english, since english is not my first language. Is "they" acceptable to identify a single contributor, or is it restricted to the plural form (contributors)? == Introduction == The overall goal is to get more active developers working on Python to better scale horizontally: get more reviews to get better changes. The code quality is expected to be enhanced: more eyes on reviews should help to catch bugs earlier. Another less important goal is to speed up the Python development IMHO the current blocker issue is that it is too hard to become a core developer. While becoming a core developer is not required to contribute, in my experience, core developers feel more involved and better recognized for their work. Core developer first means becoming responsible of a change: maintain the code/documentation and handle any potential regression. Long term commitment and good quality reviews are also expected from core developers. The blocker issue can be explained by the very high step that should be climed at once to become a core developer. The contributor responsibilities changes at once from "no power" to "can do anything on any part of the project". A promotion is decided with a vote. If a voter doesn't know the contributor, it can be very stressful to take a decision. Building a trust relationship takes time and is not currently formalized by a process. This process is trying to address these issues. I propose to formalize a process to promote a contributor from the early newcomer step to the final core developer step. The process is made of multiple steps to help the contributor to estimate their own progress. Mentoring becomes required by the process and is a major part of the whole process. While the process explains how to "clim" steps, going backward now becomes part of the process, it is not seen as a failure but as a normal and expected change under certain conditions. The final vote to promote a contributor as a core developer is expected to become more natural and simpler. The voters are expected to know better the future candidate. == Process Steps == I propose the following steps to become a core developer: * Step 0: Newcomer * Step 1: Contributor * Step 2: Bug triage permission * Step 3: Mentoree. * Step 4: Core developer == Step 0: Newcomer == The first step is to start as a newcomer. Usually, newcomers are following the Python development without actively contributing. == Step 1: Contributor == I consider that newcomers become automatically contributors as soon as they post their first comment on the bug tracker, comment on a pull request, or a pull request. Their is no manual validation, nor additional privilege. It's just a thin distinction with a newcomer. At this step, it becomes interesting to start reading the Python Developer Guide: http://devguide.python.org/ == Step 2: Bug Triage Permission == Once a contributor becomes active enough, a core developer can propose to give the bug triage permission to the contributor. The contributors may ask themself to give this permission. The level of activity is not strictly defined, since it depends on the kind of contributions and their quality. The core developer is responsabile to estimate this. There is no formal vote to give the bug triage permission. The core developer becomes responsible of the promotion. In practice, core developers are free to discuss together ;-) Getting the bug triage permission gives more responsabilities to the contributor: the bug tracker should not be misused to not lost useful information. Taking a decision on an issue requires a certain level of knowledege of the Python development. I propose that the contributor gets a mentor during one month. The role of the mentor is to answer to any question of the mentoree, and help them to take decisions if needed. The mentor is not expected to watch closely what the contributor does on the bug tracker. If the contributor misuses the bug tracker, the mentor (or another core developer) should help the contributor to adjust their behaviour. If the contributor continue to abuse the bug tracker or misbehaves, the permission is removed and the contributor moves back to the previous step. This step is the opportunity to know each other, begin to create a trust relationship. Required skills for the contributor: * Be active on the Python project: bug tracker, pull requests and/or mailing lists like python-ideas and python-dev. There is no minimum number of contributions: it's not a matter of quantity, but more a matter of quality and the kind of contributions. * Be nice, police and respectful. * Know what they are talking about, and explain their reasoning well. Skills which are nice to have, but not required: * Know how to triage bugs. If the contributor doesn't know that, I consider that the role of the mentor is to explain this (using the devguide documentation). * Read the Python Developer Guide. This step is also a first milestone to measure the contrbutor involvment in the Python project, to later be able to estimate their "longterm commitement". == Step 3: Getting a mentor == Python project is big and has a long history. Contributors need a referrer to guide them in this wild and dangerous (!) project, and in the development workflow. The role of the mentor is to answer to contributors questions and review their work. The role is not to become the single gatekeeper merging all contributions of one specific contributor. It's perfectly fine if the mentor is unable to review a pull request, just help to find an appropriate reviewer in this case. This step is a second opportunity to build a trust relationship, maybe already started at the previous step with the same mentor. Required contributor skills: * Be active on the Python project: I would like to say "still" be active on the Python project, which is another proof of the contributor commitement in the project * Sign the CLA: at some point, getting changes merged into Git becomes mandatory, and so the CLA must be signed. * Find a mentor. Required mentor skills: * Be a core contributor. * Be available at least during one whole month. * Follow the contributor: must get an update at least once a week, especially if the contributor doesn't show up. Obviously, it's better if the contributor interest areas match with the mentor interest areas ;-) (... Maybe later we may change the process to allow non-core developers to become mentors, but I'm not sure about of this yet ...) If the contributor becomes unavailable, it's fine, it's just a small step backward, until they become available again. If the mentor becomes unavailable, maybe a different mentor can continue the process, otherwise the contributor goes back to the previous step. == Step 4: Core Developer == Once the mentor or another core developer consider that the contributor is mature enough to be promoted, a vote is organized on the python-committers mailing list. The contributor skills and contributions should be listed. Usually, any negative vote becomes a veto which blocks the promotion. While a few votes were negative in the past, I hope that this new formalized process would make the vote more natural and limit the "risk" of negative votes. Requirements to become a core developer: * Be nice and respectful * Humility * Long term commitement * Reviews * Know the CPython workflow * Know the CPython lifecycle * Know the Python C API specific issues, for contributors working on the C code * Good quality patches I described these requirements in detail at: http://cpython-core-tutorial.readthedocs.io/en/latest/core_developer.html#r… Becoming a core developer involves getting more responsabilities: * The core developer becomes the "owner" of a merged change: maintain the code and handle any potential regression * Review pull requests * Triage bugs The newly promoted core developer will followed by a mentor during one month until they become confortable enough. Obviously, the mentoring can be extended if needed. If the result of the promotion vote is negative, it's ok, move back to the previous step, and retry later. Usually the vote can be retried 6 months later, time spent to address lacking skills (maybe with a mentor). Hum, it seems like the contributor has been promoted: congratulations and welcome aboard! Victor

6 9

Proposed schedule for next 3.4 and 3.5 releases - end of January / early February
by Larry Hastings 08 Dec '17

08 Dec '17

Howdy howdy. I know nobody's excited by the prospect of 3.4 and 3.5 releases--I mean, fer gosh sakes, neither of those versions even has f-strings! But we're about due. I prefer to release roughly every six months, and the current releases came out in early August. Here's my proposed schedule: Sun Jan 21 2017 - release 3.4.8rc1 and 3.5.5rc1 Sun Feb 04 2017 - release 3.4.8 final and 3.5.5 final Unless I'm presented with good reasons to change it, that'll be the schedule. I'll update the PEPs with the final release dates in about a week. Just for fun, I'll remind everybody here that 3.4 and 3.5 are both in security-fixes-only mode. This means two things: 1. These will be source-code-only releases; the Python core dev team won't release any more binary installers for 3.4 or 3.5. 2. I'm the only person permitted to accept PRs for 3.4 and 3.5. If you have security fixes for either of those versions, please add me as a reviewer. Happy holidays to you and yours, //arry/

1 0

Statistics: growth of core dev number vs growth of the code size/complexity
by Victor Stinner 08 Dec '17

08 Dec '17

Hi, I wrote a quick & dirty parser to compute statistics on *new* CPython core developer per year using the following page as data: https://devguide.python.org/developers/ 2007: 15 2008: 19 2009: 11 2010: 20 2011: 12 2012: 9 2013: 4 2014: 10 2015: 2 2016: 5 2017: 2 Compare these numbers to Stéphane Wirtel's statistics on pull requests: https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests => Number of active core developerson on GitHub pull requests: 27 (stats from February 2017 to October 2017) (I'm not sure of the meaning of this number, it's the number of core developer who authored pull requests, I don't think that it counts core developers who only made reviews.) If you look at the size of the source code, it's still growing constanly since 1990: https://www.openhub.net/p/python/ 2007: around 783k lines 2010: around 683k lines 2013: around 800k lines 2015: around 875k lines 2017: around 973k lines The number of bugs is also constanly growing. Statistics on bugs since 2011: https://bugs.python.org/issue?@template=stats 2011: around 2500 open issues 2013: around 4000 open issues 2015: around 5000 open issues 2017: around 6200 open issues The size of the CPython project is constantly growing as its complexity (technical debt? what is this? :-)), but the growth of core developers is slowing down. I do consider that we need more people to handle the growing number of issues and pull requests, so the question is now how to find and "hire" (sorry, promote) them ;-) Maybe we have a problem with mentoring. Maybe the CPython code base became too hard to train newcomers? Maybe we are too conservative? I don't know. Victor

8 8

Promote Julien Palard as core developer
by Victor Stinner 08 Dec '17

08 Dec '17

Hi, I propose to promote Julien Palard as a core developer. Julien Palard is leading the french translation of the Python documentation since 2 or 3 years. He spent a lot of time to try to get this translation online. Since he was unlucky on the python-ideas mailing list, I convinced him to write down a PEP. He wrote it with Naoki INADA (who is translated the documentation to Japanese) and me. It wasn't easy to write the PEP and get it approved: it took almost 1 year and a half! The PEP 545 was approved and implemented in Python 3.7! https://www.python.org/dev/peps/pep-0545/ Thanks to Julien (and others), translated documentations are now online at: https://docs.python.org/fr/ -- French https://docs.python.org/ja/ -- Japanese See also the What's New in Python 3.7 entry: https://docs.python.org/dev/whatsnew/3.7.html#documentation Julien spent a lot of time to fix a lot of various issues in the documentation, the docsbuild-scripts project used to build the CPython documentation, Sphinx, etc. to be able to translate properly the documentation. For me, the documentation and the docsbuild-scripts project are tightly coupled to the CPython project. Last june, I even asked to give the commit bit to Julien on the https://github.com/python/docsbuild-scripts/ project on this list, since I expected that this project was part of CPython (it isn't, it's another "team" on GitHub, if I understood correctly) :-) In the meanwhile, Julien became a "core developer" on this project as well. He also worked closely with the Python infra team to fix a few bugs when the translated documentation was published at python.org. To come back to CPython itself, Julien Palard already got 18 commits merged into the master branch since January 2016: 11 before GitHub ("patch by Julien Palard") + 7 since CPython migrated to GitHub ("Julien Palard" author). Most of his commits are related to the Python documentation content and tooling to build the documentation. He fixed "bugs" in the documentation, to clarify some documentation. Giving him the commit bit would ease his work, since too few people are looking at these areas of the code. When I reviewed his patches, they are usually good after one or two iterations, and Julien welcomes criticism. I know that Julien doesn't have the typical profile of core developers, only or mostly contribute to the code: Julien is currently focused on the doculmentation. But I believe (because he told me so ;-)) that Julien will slowly contribute to other areas of the code, once he will feel more confortable, and I may guide him in the code if needed. I think that many of us started to contribute to a project on its documentation ;-) I don't think that he needs an official menthor since he already knows well the CPython workflow, and he knows how to ask questions if needed ;-) Promoting Julien is part of my global idea/project of trying to recognize more contributions which are not strictly code, but as useful or even more useful than code! Python documentation is part of Python's success. I was told many times that Python has a good documentation, it's nice to hear that ! IMHO reducing CPython to its C and Python code is wrong and nor fair, CPython made of much more "sub-projects". Victor

7 8

Adding Ivan Levkivskyi as a core committer
by Guido van Rossum 08 Dec '17

08 Dec '17

I'd like to propose Ivan Levkivskyi as a new core committer. He's (re-)written most of the typing.py module and will do so again for Python 3.7, he's the sole or primary author on several PEPs (526, 544, 560, 562), is co-author on several more (483, 561) and has been acknowledged in yet others (557, 563). He is responsible for at least 16 commits in master. I have worked with him for a long time on typing.py and on mypy (where he is a core dev) and I can vouch for him completely. -- --Guido van Rossum (python.org/~guido)

16 22

Cheryl Sabella was promoted to get bug triage permission
by Victor Stinner 07 Dec '17

07 Dec '17

Hi, To recognize the good contributions of Cheryl Sabella, I gave her the bug triage permission on bugs.python.org. (In practice, Ezio gave her the permission.) In the past, such "promotion" wasn't always advertized on python-committers, but my intent is to make our process more transparent and award people who deserve it! IMHO bug triage is the first step/milestone to become a core developer in the long term. FYI She pushed not less than 14 commits into the master branch since August, 2017. Congrats Cheryl! Victor

6 6

Sanyam Khurana has been promoted to get bug triage permission
by Victor Stinner 07 Dec '17

07 Dec '17

Hi, To recognize the good contributions of Sanyam Khurana, I gave him the bug triage permission on bugs.python.org. (In practice, Ezio gave him the permission.) He already commited 9 changes into the master branch since April, 2017. Congrats Sanyam! Victor

3 2

Re: [python-committers] Cheryl Sabella was promoted to get bug triage permission
by Victor Stinner 06 Dec '17

06 Dec '17

2017-12-06 23:07 GMT+01:00 Cheryl Sabella <cheryl.sabella(a)gmail.com>: > Wow, this is a shock! I'm sorry, maybe I had to warn you before? ;-) > Thank you, Victor, Ezio, and everyone else. This is > such an amazing and welcoming community, so thank you for letting me be a > part of it. You're welcome. Victor

1 0

Re: [python-committers] Cheryl Sabella was promoted to get bug triage permission
by Mariatta Wijaya 06 Dec '17

06 Dec '17

Congrats Cheryl!! Thanks for your continued contributions! On Dec 6, 2017 9:43 AM, "Victor Stinner" <victor.stinner(a)gmail.com> wrote: Hi, To recognize the good contributions of Cheryl Sabella, I gave her the bug triage permission on bugs.python.org. (In practice, Ezio gave her the permission.) In the past, such "promotion" wasn't always advertized on python-committers, but my intent is to make our process more transparent and award people who deserve it! IMHO bug triage is the first step/milestone to become a core developer in the long term. FYI She pushed not less than 14 commits into the master branch since August, 2017. Congrats Cheryl! Victor _______________________________________________ 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/

1 0

[RELEASE] Python 3.6.4rc1 and 3.7.0a3 now available for testing
by Ned Deily 05 Dec '17

05 Dec '17

Announcing the immediate availability of Python 3.6.4 release candidate 1 and of Python 3.7.0 alpha 3! Python 3.6.4rc1 is the first release candidate for Python 3.6.4, the next maintenance release of Python 3.6. While 3.6.4rc1 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). 3.6.4 is planned for final release on 2017-12-18 with the next maintenance release expected to follow in about 3 months. You can find Python 3.6.4rc1 and more information here: https://www.python.org/downloads/release/python-364rc1/ Python 3.7.0a3 is the third of four planned alpha releases of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview release, 3.7.0a4, is planned for 2018-01-08. You can find Python 3.7.0a3 and more information here: https://www.python.org/downloads/release/python-370a3/ -- Ned Deily nad(a)python.org -- []

1 0

python-devs/python project on GitLab
by Barry Warsaw 05 Dec '17

05 Dec '17

Back when we were deciding between GitHub and GitLab, we created this project: https://gitlab.com/python-devs/python Unless anyone objects, we’re going to delete this project. We have no need for this now that CPython development is on GitHub. (No, we’re not getting rid of the group, just the project.) Cheers, -Barry

1 0

3.7.0a3 still open
by Ned Deily 04 Dec '17

04 Dec '17

Congratulations to the owners of the newly accepted PEPs. The code cutoff for 3.7.0 alpha 3 is scheduled for today (along with 3.6.3rc1). I know at least one of the PEPs has code ready to commit. I will hold off on tagging 3.7.0a3 for another 6 hours or so. If you feel your code is adequately reviewed and ready to go, go for it; likewise for normal bug fixes and doc changes. But keep in the mind that there is still one more alpha preview release coming prior to the beta 1 feature code freeze, so no need to panic. -- Ned Deily nad(a)python.org -- []

1 0

Mostly offline from December 10th through to January 1st
by Nick Coghlan 03 Dec '17

03 Dec '17

Hi folks, Just a heads up that I'll be mostly offline for the last 3 weeks of December. I don't think there's anything in particular coming up that will need my attention specifically (I'm hoping we can get the DeprecationWarning PEP resolved this week), but it does mean I won't be around to review startup refactoring or subinterpreter related PRs if any further work is done on those. Cheers, Nick. P.S. I'd still like to get PEP 558's "Defined semantics for locals()" included in 3.7, but I'm also OK with it slipping to 3.8 - the quirky behaviour that it addresses has been around for a decade and a half, so I don't think anyone is really going to care all that much whether it gets fixed in 2018 or in 2019. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0