On 12.05.2015 05:03, Nick Coghlan wrote:
On 12 May 2015 at 04:49, M.-A. Lemburg m...@egenix.com 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
- Original Message -
From: Donald Stufft don...@stufft.io
To: Nick Coghlan ncogh...@gmail.com
Cc: python-dev python-dev@python.org, M.-A. Lemburg m...@egenix.com
Sent: Monday, May 11, 2015 1:16:58 PM
Subject: Re: [Python-Dev] PYTHONHTTPSVERIFY env var
On May 11, 2015, at 6:47
* Mark Rosenblitt-Janssen dreamingforw...@gmail.com [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 =
On Tue, May 12, 2015 at 1:05 PM Larry Hastings la...@hastings.org 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
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
On May 12, 2015, at 10:04, Larry Hastings la...@hastings.org 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
On Wed, May 13, 2015 at 3:04 AM, Larry Hastings la...@hastings.org 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
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
On Tue, 12 May 2015 10:04:39 -0700
Larry Hastings la...@hastings.org 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
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
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
On May 12, 2015, at 10:38, Larry Hastings la...@hastings.org 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
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:
In article 55523adb.4000...@hastings.org,
Larry Hastings la...@hastings.org 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
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
On Tue, May 12, 2015 at 4:14 PM, Skip Montanaro
skip.montan...@gmail.com 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
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
On Tue, May 12, 2015 at 4:36 PM, Larry Hastings la...@hastings.org 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
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
On 13 May 2015 03:47, Brett Cannon br...@python.org wrote:
On Tue, May 12, 2015 at 1:05 PM Larry Hastings la...@hastings.org 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
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 m...@egenix.com wrote:
On
On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io 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
On 12.05.2015 13:21, Donald Stufft wrote:
On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote:
If you control the app you don't need to do that. All relevant api accept
the context parameter. The shims are only
On 12 May 2015 at 17:57, M.-A. Lemburg m...@egenix.com 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
On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io 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
On 12 May 2015 at 21:21, Donald Stufft don...@stufft.io wrote:
On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote:
If you control the app you don't need to do that. All relevant api accept
the context parameter.
On 12.05.2015 12:04, Donald Stufft wrote:
On May 12, 2015, at 3:57 AM, M.-A. Lemburg m...@egenix.com 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
On 12 May 2015 at 21:17, Nick Coghlan ncogh...@gmail.com 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
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 tjre...@udel.edu;
Tue, 12 May
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:
On 2015-05-12 17:28, Guido van Rossum wrote:
-- Forwarded message --
From: Dakshesh Vyas dv...@coverity.com mailto:dv...@coverity.com
Date: May 12, 2015 1:08 AM
Subject: Coverity Scan update
To: gu...@python.org mailto:gu...@python.org gu...@python.org
mailto:gu...@python.org
On 12May2015 22:15, David Wilson dw+python-...@hmmz.org 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.
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
On 12 May 2015 at 21:45, Donald Stufft don...@stufft.io wrote:
On May 12, 2015, at 7:40 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:21, Donald Stufft don...@stufft.io wrote:
On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:09,
On May 12, 2015, at 7:40 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:21, Donald Stufft don...@stufft.io wrote:
On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote:
If you control the app
On Wed, May 13, 2015 at 8:15 AM, David Wilson dw+python-...@hmmz.org 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
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:
On 12 May 2015 at 20:56, M.-A. Lemburg m...@egenix.com wrote:
On 12.05.2015 12:04, Donald Stufft wrote:
On May 12, 2015, at 3:57 AM, M.-A. Lemburg m...@egenix.com wrote:
In a user based installation (which most applications shipping
their own Python installation are), you can always do this
On 12.05.2015 13:19, Nick Coghlan wrote:
On 12 May 2015 at 21:17, Nick Coghlan ncogh...@gmail.com 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
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
On May 12, 2015, at 3:57 AM, M.-A. Lemburg m...@egenix.com 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
-- Forwarded message --
From: Dakshesh Vyas dv...@coverity.com
Date: May 12, 2015 1:08 AM
Subject: Coverity Scan update
To: gu...@python.org gu...@python.org
Cc:
Hello Guido van Rossum,
Thank you for using Coverity Scan.
With more than 4000 open source projects now registered at
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
43 matches
Mail list logo
