python-committers November 2017

python-committers@python.org

14 participants
9 discussions

GitHub: remove the "needs backport to 3.5" label?

by Victor Stinner

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

1 year, 11 months

Requirements to get the "bug triage" permission?

by Victor Stinner

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

3 years, 6 months

3.7.0a3 cutoff extended a week to 12-04

by Ned Deily

We are extending the cutoff for the next 3.7 alpha preview (3.7.0a3) a week, moving it from today to 12-04 12:00 UTC. The main reason is a selfish one: I have been traveling and mainly offline for the last few weeks and I am still catching up with activity. Since we are getting close to feature code cutoff for the 3.7 cycle, it would be better to get things in sooner than later. Following alpha 3, we will have one more alpha preview, 3.7.0a4 on 2018-01-08, prior to the feature code cutoff with 3.7.0b1 on 2018-01-29. Note that 12-04 is also the scheduled date for the next 3.6.x maintenance release release candidate, 3.6.4rc1. So I hope you can take advantage of the extra days for both release cycles. Thanks again for all your efforts! --Ned -- Ned Deily nad(a)python.org -- []

3 years, 8 months

CLA indication on Github out of date?

by Antoine Pitrou

Hello, I forget... Who handles updating the Python CLA database? One of our contributors apparently signed the CLA but still has the "CLA not signed" indicator on their PR: https://github.com/python/cpython/pull/4496#issuecomment-346792634 (sent to: python-committers, board@psf) Regards Antoine.

3 years, 8 months

Nickname changed from haypo to vstinner

by Victor Stinner

Hi, For your information, I changed my nickname from "haypo" to "vstinner" on IRC, GitHub and Bitbucket. The change is supposed to be transparent, *but* there is an exception. On GitHub, @haypo mentions don't notify me anymore. So please, if you want to notify me on GitHub, please use @vstinner. That's all, sorry for the noise, Victor Stinner aka vstinner ;-)

3 years, 8 months

IPv6 issues on *.python.org

by Antoine Pitrou

Hello, I'm having IPv6 issues on *.python.org. Is anyone having the same issues or is it just me? Who should I report this to? $ curl -6 -v -I https://www.python.org/ * Trying 2a04:4e42:9::223... * Connected to www.python.org (2a04:4e42:9::223) port 443 (#0) * found 148 certificates in /etc/ssl/certs/ca-certificates.crt * found 604 certificates in /etc/ssl/certs * ALPN, offering http/1.1 * gnutls_handshake() failed: Error in the pull function. * Closing connection 0 curl: (35) gnutls_handshake() failed: Error in the pull function. Regards Antoine.

3 years, 8 months

Re: [python-committers] [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

by Nick Coghlan

On 4 November 2017 at 09:52, Jelle Zijlstra <jelle.zijlstra(a)gmail.com> wrote: > > 2017-11-03 16:44 GMT-07:00 Joao S. O. Bueno <jsbueno(a)python.org.br>: >> >> This just popped up in Brython's issue tracker discussion: >> >> """ >> Pierre Quentel <notifications(a)github.com> >> >> 04:57 (16 hours ago) >> to brython-dev/br., Subscribed >> >> I think it's better to rename all occurences of async now, although >> it's strange that : >> >> there is currently no deprecation warning in CPython with code that >> uses it as a variable name, PEP492 said that "async and await names >> will be softly deprecated in CPython 3.5 and 3.6" >> there is no mention of async and await becoming keywords in What's new >> in Python 3.7 >> >> Maybe the idea was finally given up, but I can't find a reference. >> >> """ >> >> So, what is the status of promoting async and await to full keyword for >> 3.7? >> > This was implemented, and it's in NEWS: > https://github.com/python/cpython/pull/1669. That's a big enough change that it should be in What's New as well (at least in the porting section, and probably more prominent than that). The current lack of DeprecationWarnings in 3.6 is a fairly major oversight/bug, though: Python 3.6.2 (default, Oct 2 2017, 16:51:32) [GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> await = 1 >>> async = 1 >>> print(async, await) 1 1 So if we're going to go ahead with making them real keywords in 3.7 (as specified in PEP 492), then the missing DeprecationWarning problem in 3.6 needs to be fixed. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 years, 8 months

Re: [python-committers] [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

by Victor Stinner

2017-11-04 0:44 GMT+01:00 Joao S. O. Bueno <jsbueno(a)python.org.br>: > This just popped up in Brython's issue tracker discussion: > > """ > Pierre Quentel <notifications(a)github.com> > > 04:57 (16 hours ago) > to brython-dev/br., Subscribed > > I think it's better to rename all occurences of async now, although > it's strange that : > > there is currently no deprecation warning in CPython with code that > uses it as a variable name, PEP492 said that "async and await names > will be softly deprecated in CPython 3.5 and 3.6" > there is no mention of async and await becoming keywords in What's new > in Python 3.7 > > Maybe the idea was finally given up, but I can't find a reference. async & await already became concrete keywords in Python 3.7: $ ./python Python 3.7.0a2+ (heads/master-dirty:cbe1756e3e, Nov 4 2017, 00:24:07) >>> async=1 File "<stdin>", line 1 async=1 ^ SyntaxError: invalid syntax Please request an entry in the "What's New in Pyhon 3.7" at https://bugs.python.org/issue30406 Victor

3 years, 8 months

Reminder: 12 weeks to 3.7 feature code cutoff

by Ned Deily

Happy belated Halloween to those who celebrate it; I hope it wasn't too scary! Also possibly scary: we have just a little over 12 weeks remaining until Python 3.7's feature code cutoff, 2018-01-29. Those 12 weeks include a number of traditional holidays around the world so, if you are planning on writing another PEP for 3.7 or working on getting an existing one approved or getting feature code reviewed, please plan accordingly. If you have something in the pipeline, please either let me know or, when implemented, add the feature to PEP 537, the 3.7 Release Schedule PEP. As you may recall, the release schedule calls for 4 alpha preview releases prior to the feature code cutoff with the first beta release. We have already produced the first two alphas. Reviewing the schedule recently, I realized that I had "front-loaded" the alphas, leaving a bigger gap between the final alphas and the first beta. So I have adjusted the schedule a bit, pushing alpha 3 and 4 out. The new dates are: - 3.7.0 alpha 3: 2017-11-27 (was 2017-11-13) - 3.7.0 alpha 4: 2018-01-08 (was 2017-12-18) - 3.7.0 beta 1: 2018-01-29 (feature freeze - unchanged) I hope the new dates give you a little bit more time to get your bits finished and get a little bit of exposure prior to the feature freeze. Considering how quickly and positively it has been adopted, 3.6 is going to be a tough act to follow. But we can do it again. Thank you all for your ongoing efforts! --Ned -- Ned Deily nad(a)python.org -- []

3 years, 9 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers November 2017