Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On Tue, May 12, 2015 at 8:04 PM, Larry Hastings wrote: > What do you think? My votes are as follows: > > Workflow 0: -0.5 > Workflow 1: +1 > Workflow 2: +0.5 > > > Please cast your votes, Workflow 0: -0 Workflow 1: +1 Workflow 2: +0 --Berker ___ Pytho

Re: [Python-Dev] cpython: Issue #20172: Convert the winsound module to Argument Clinic.

On 13.05.15 09:32, zach.ware wrote: https://hg.python.org/cpython/rev/d3582826d24c changeset: 96006:d3582826d24c user:Zachary Ware date:Wed May 13 01:21:21 2015 -0500 summary: Issue #20172: Convert the winsound module to Argument Clinic. +/*[clinic input] +winsound.PlaySo

Re: [Python-Dev] Tracker reviews look like spam

On Wed, May 13, 2015 at 8:15 AM, David Wilson wrote: > SPF only covers the envelope sender, so it should be possible to set > that to something that validates with SPF, keep the RFC822 From: header > as it is, and maybe(?) include a separate Sender: header matching the > envelope address. As Came

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 11:18 AM, Jesus Cea wrote: Larry, could you comment about the impact in the buildbots?. I suppose option #1 could allows us to test both 3.5 and 3.6 changes. Would you confirm this? Workflow #1 gets us automatic buildbot testing for the 3.5 branch (betas and 3.5.1) and trunk (3.6

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 13 May 2015 03:47, "Brett Cannon" wrote: > > > > On Tue, May 12, 2015 at 1:05 PM Larry Hastings wrote: >> >> [SNIP] >> >> >> What do you think? My votes are as follows: >>> >>> Workflow 0: -0.5 >>> Workflow 1: +1 >>> Workflow 2: +0.5 >> >> >> Please cast your votes, > > > Workflow 0: -0 > Wor

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 05:11 PM, Dirkjan Ochtman wrote: Couldn't you just keep this as a branch that you then keep rebasing (without unlinking the original branch)? It doesn't seem like something that needs a one-off script, to me. Probably. It's water under the bridge now--that all happened last Febr

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On Tue, May 12, 2015 at 4:36 PM, Larry Hastings wrote: > BTW, this workload was exacerbated by my foolish desire to keep the revision > DAG nice and clean. So I was actually starting over from scratch and > redoing all the cherry-picking every couple of days, just so I could get all > the cherry-

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 11:21 AM, Ned Deily wrote: I like the idea of experimentally trying the push workflow but, if we are all doing our jobs right, there should be very few changes going in after rc1 so most committers won't need to push anything to the 3.5.0rc repo and, if for some reason they aren'

Re: [Python-Dev] Tracker reviews look like spam

On 12May2015 22:15, David Wilson wrote: SPF only covers the envelope sender, so it should be possible to set that to something that validates with SPF, keep the RFC822 From: header as it is, and maybe(?) include a separate Sender: header matching the envelope address. David Indeed. That sound

Re: [Python-Dev] Fwd: Coverity Scan update

On 2015-05-12 17:28, Guido van Rossum wrote: > -- Forwarded message -- > From: "Dakshesh Vyas" mailto:dv...@coverity.com>> > Date: May 12, 2015 1:08 AM > Subject: Coverity Scan update > To: "gu...@python.org " > > Cc: > > Hello Gui

Re: [Python-Dev] Tracker reviews look like spam

SPF only covers the envelope sender, so it should be possible to set that to something that validates with SPF, keep the RFC822 From: header as it is, and maybe(?) include a separate Sender: header matching the envelope address. David On Tue, May 12, 2015 at 06:08:30PM -0400, Terry Reedy wrote:

[Python-Dev] Tracker reviews look like spam

Gmail dumps patch review email in my junk box. The problem seems to be the spoofed From: header. Received: from psf.upfronthosting.co.za ([2a01:4f8:131:2480::3]) by mx.google.com with ESMTP id m1si26039166wjy.52.2015.05.12.00.20.38 for ; Tue, 12 May 2015 00:20:38 -0700

Re: [Python-Dev] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

In article <55523adb.4000...@hastings.org>, Larry Hastings wrote: > On 05/12/2015 10:23 AM, Chris Angelico wrote: > > Will this model be plausibly extensible to every release? For > > instance, when a 3.5.1 rc is cut, will the 3.5 branch immediately > > become 3.5.2, with a new 3.5.1 branch bein

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On May 12, 2015, at 10:38 AM, Larry Hastings wrote: >It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after >3.5.0 final ships, as per tradition. I still think it's a good idea to focus primarily on 3.5 while it's in the beta/rc period, but if you want to allow for landings

Re: [Python-Dev] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 10:04 AM, Larry Hastings wrote: Workflow 1: +1 -- ~Ethan~ ___ 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%40mai

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On May 12, 2015, at 10:38, Larry Hastings wrote: > On 05/12/2015 10:23 AM, Ned Deily wrote: >> One possible issue with Workflow 1 is that there would need to be an >> additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA >> "trunk"), 3.4, and 2.7 ones) for the period from be

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 05/12/2015 04:19 AM, Nick Coghlan wrote: It occurs to me that the subtitle of PEP 493 could be "All software is terrible, but it's often a system administrator's job to make it run anyway" :) +1 QoTW -- ~Ethan~ ___ Python-Dev mailing list Python

Re: [Python-Dev] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On Tue, 12 May 2015 10:04:39 -0700 Larry Hastings wrote: > > Workflow 1 > == > > When I ship beta 1, we create the 3.5 branch. trunk become 3.6. > > When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically > visible repo /on bitbucket/ for 3.5.0, and we use bitbucket "

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On Tue, May 12, 2015 at 1:05 PM Larry Hastings wrote: > [SNIP] > > What do you think? My votes are as follows: > > Workflow 0: -0.5 > Workflow 1: +1 > Workflow 2: +0.5 > > > Please cast your votes, > Workflow 0: -0 Workflow 1: +1 Workflow 2: +0 ___ P

Re: [Python-Dev] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 10:23 AM, Chris Angelico wrote: Will this model be plausibly extensible to every release? For instance, when a 3.5.1 rc is cut, will the 3.5 branch immediately become 3.5.2, with a new 3.5.1 branch being opened on bitbucket? Yes, we could always do it that way, though in the past

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 10:23 AM, Ned Deily wrote: One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA "trunk"), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On May 12, 2015, at 10:04, Larry Hastings wrote: > Workflow 1 > == > > When I ship beta 1, we create the 3.5 branch. trunk become 3.6. > > When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically > visible repo on bitbucket for 3.5.0, and we use bitbucket "pull request

Re: [Python-Dev] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On Wed, May 13, 2015 at 3:04 AM, Larry Hastings wrote: > Workflow 1 > == > > When I ship beta 1, we create the 3.5 branch. trunk become 3.6. > > When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically > visible repo on bitbucket for 3.5.0, and we use bitbucket "pull reque

[Python-Dev] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

Python 3.5 beta 1 is coming up soon. After beta is rc; after rc is 3.5.0 final. During the beta and rc periods the Python developer workflow changes a little--what sorts of checkins are permissible, and how to get something accepted and merged generally becomes more complicated. I was the

Re: [Python-Dev] Mac popups running make test

On Tue, May 12, 2015 at 4:14 PM, Skip Montanaro wrote: > > > Twice now, I've gotten this popup: ... > > Let me improve my request, as it seems there is some confusion about > what I want. I'm specifically not asking that the popups not be > displayed. I don't mind dismissing them. When they appear

Re: [Python-Dev] anomaly

On 5/11/2015 3:40 AM, Florian Bruhin wrote: [snip] This trollish thread was cross-posted to python-list, where it was semi-ok, at least in the beginning, and pydev, where it is not. It has continued on python-list with pydev removed. Please do not continue it here (on pydev). -- Terry Jan

[Python-Dev] Fwd: Coverity Scan update

-- Forwarded message -- From: "Dakshesh Vyas" Date: May 12, 2015 1:08 AM Subject: Coverity Scan update To: "gu...@python.org" Cc: Hello Guido van Rossum, Thank you for using Coverity Scan. With more than 4000 open source projects now registered at Coverity Scan, we are committed

Re: [Python-Dev] What's missing in PEP-484 (Type hints)

re: comprehension Perhaps PEP can, at least, have a short list/summary of limitations? I recall something was mentioned, but I can't find a section like that in PEP. re: example following https://github.com/JukkaL/mypy/blob/master/stubs/3.2/socket.py # socket.pyi python2 class _socketobject:

Re: [Python-Dev] Mac popups running make test

> Twice now, I've gotten this popup: ... Let me improve my request, as it seems there is some confusion about what I want. I'm specifically not asking that the popups not be displayed. I don't mind dismissing them. When they appear, I would, however, like to glance over at the stream of messages e

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12 May 2015 at 21:45, Donald Stufft wrote: > >> On May 12, 2015, at 7:40 AM, Nick Coghlan wrote: >> >> On 12 May 2015 at 21:21, Donald Stufft wrote: >>> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote: On 12 May 2015 at 21:09, Donald Stufft wrote: > If you control the app

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

> On May 12, 2015, at 7:40 AM, Nick Coghlan wrote: > > On 12 May 2015 at 21:21, Donald Stufft wrote: >> >>> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote: >>> >>> On 12 May 2015 at 21:09, Donald Stufft wrote: If you control the app you don't need to do that. All relevant api accept

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12.05.2015 13:21, Donald Stufft wrote: > >> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote: >> >> On 12 May 2015 at 21:09, Donald Stufft wrote: >>> If you control the app you don't need to do that. All relevant api accept >>> the context parameter. The shims are only useful when you don't c

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12 May 2015 at 21:21, Donald Stufft wrote: > >> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote: >> >> On 12 May 2015 at 21:09, Donald Stufft wrote: >>> If you control the app you don't need to do that. All relevant api accept >>> the context parameter. The shims are only useful when you don

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote: > > On 12 May 2015 at 21:09, Donald Stufft wrote: >> If you control the app you don't need to do that. All relevant api accept >> the context parameter. The shims are only useful when you don't control the >> app. So an app shipping their own

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12.05.2015 13:19, Nick Coghlan wrote: > On 12 May 2015 at 21:17, Nick Coghlan wrote: >> Both of those make sense to me as cases where the environment variable >> based security downgrade approach is the "least bad" answer available, >> which is why I eventually agreed it should be one of the >>

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12 May 2015 at 21:17, Nick Coghlan wrote: > Both of those make sense to me as cases where the environment variable > based security downgrade approach is the "least bad" answer available, > which is why I eventually agreed it should be one of the > recommendations in the PEP. It occurs to me t

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12 May 2015 at 21:09, Donald Stufft wrote: > If you control the app you don't need to do that. All relevant api accept the > context parameter. The shims are only useful when you don't control the app. > So an app shipping their own python doesn't fall under that. I think the "bundled Python

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12 May 2015 at 20:56, M.-A. Lemburg wrote: > On 12.05.2015 12:04, Donald Stufft wrote: >> >>> On May 12, 2015, at 3:57 AM, M.-A. Lemburg wrote: >>> >>> In a user based installation (which most applications shipping >>> their own Python installation are), you can always do this >>> provided you

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

If you control the app you don't need to do that. All relevant api accept the context parameter. The shims are only useful when you don't control the app. So an app shipping their own python doesn't fall under that. > On May 12, 2015, at 6:56 AM, M.-A. Lemburg wrote: > >> On 12.05.2015 12:04,

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12.05.2015 12:04, Donald Stufft wrote: > >> On May 12, 2015, at 3:57 AM, M.-A. Lemburg wrote: >> >> In a user based installation (which most applications shipping >> their own Python installation are), you can always do this >> provided you can gain the application user permissions. > > Of co

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

> On May 12, 2015, at 3:57 AM, M.-A. Lemburg wrote: > > In a user based installation (which most applications shipping > their own Python installation are), you can always do this > provided you can gain the application user permissions. Of course, if the application is shipping it’s own Python

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12 May 2015 at 17:57, M.-A. Lemburg wrote: > The point here is that sys admins should not > have to patch Python to make things work again, in case > an application is not prepared for the certificate > verification - which is rather likely, since the pre-Python > 2.7.9 doesn't even provide the

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

- Original Message - > From: "Donald Stufft" > To: "Nick Coghlan" > Cc: "python-dev" , "M.-A. Lemburg" > Sent: Monday, May 11, 2015 1:16:58 PM > Subject: Re: [Python-Dev] PYTHONHTTPSVERIFY env var > > > > On May 11, 2015, at 6:47 AM, Nick Coghlan wrote: > > > > On 11 May 2015 at 20

Re: [Python-Dev] anomaly

* Mark Rosenblitt-Janssen [2015-05-10 11:34:52 -0500]: > Here's something that might be wrong in Python (tried on v2.7): > > >>> class int(str): pass > > >>> int(3) > '3' What's so odd about this? "class int" is an assignment to "int", i.e. what you're doing here is basically: int = str int(3

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12.05.2015 05:03, Nick Coghlan wrote: > On 12 May 2015 at 04:49, M.-A. Lemburg wrote: >> On 11.05.2015 12:15, Nick Coghlan wrote: >>> By contrast, the configuration file shouldn't provide a new attack >>> vector (or simplify any existing attack vector), as if you have the >>> permissions needed