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
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
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 -- []
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.
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 ;-)
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.
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
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
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 -- []