On 24 November 2015 at 03:46, Nick Coghlan wrote:
> I think there are three relevant categories here:
>
> 1. Folks who assume that "https" means the same thing in Python that
> it means in web browsers, and are currently experiencing a silent
> security failure
> 2. Folks who already know it doesn
On 2015-11-24 01:18, Nick Coghlan wrote:
> On 24 November 2015 at 05:35, Christian Heimes wrote:
>> On 2015-11-17 01:00, Guido van Rossum wrote:
>>> Hm, making Christian the BDFL-delegate would mean two out of three
>>> authors *and* the BDFL-delegate all working for Red Hat, which clearly
>>> has
> On Nov 24, 2015, at 7:53 AM, Christian Heimes wrote:
>
> On 2015-11-24 01:18, Nick Coghlan wrote:
>> On 24 November 2015 at 05:35, Christian Heimes wrote:
>>> On 2015-11-17 01:00, Guido van Rossum wrote:
Hm, making Christian the BDFL-delegate would mean two out of three
authors *and
On 24 Nov 2015 8:12 pm, "Paul Moore" wrote:
>
> On 24 November 2015 at 03:46, Nick Coghlan wrote:
> > I think there are three relevant categories here:
> >
> > 1. Folks who assume that "https" means the same thing in Python that
> > it means in web browsers, and are currently experiencing a silen
On 24 November 2015 at 13:20, Nick Coghlan wrote:
> I believe you're referring mainly to the original PEP 476 change there. In
> the context of PEP 493, this is another group that would potentially benefit
> from the suggested "security downgrade" environment variable (if any
> redistributors deci
In a message of Tue, 24 Nov 2015 14:05:53 +, Paul Moore writes:
>Simply adding "people who have no control over their broken
>infrastructure" with a note that this PEP helps them, would be
>sufficient here (and actually helps the case for the PEP, so why not?
>;-))
But does it help them? Or d
On 25 November 2015 at 00:27, Laura Creighton wrote:
> In a message of Tue, 24 Nov 2015 14:05:53 +, Paul Moore writes:
>>Simply adding "people who have no control over their broken
>>infrastructure" with a note that this PEP helps them, would be
>>sufficient here (and actually helps the case f
I think the PEP is a good step forward to compromise between
the crypto purists (use whatever technologies makes us more
secure even if it breaks things) and those who cannot upgrade
their Python 2.7 because of the PEP 476 change, since it causes their
applications to fail (e.g. because the embedde
On Nov 24, 2015 6:28 AM, "Laura Creighton" wrote:
>
> In a message of Tue, 24 Nov 2015 14:05:53 +, Paul Moore writes:
> >Simply adding "people who have no control over their broken
> >infrastructure" with a note that this PEP helps them, would be
> >sufficient here (and actually helps the case
On 2015-11-24 00:47, Nick Coghlan wrote:
> Updated version of the PEP posted: https://hg.python.org/peps/rev/8decac213ebf
>
> On 24 November 2015 at 05:35, Christian Heimes wrote:
>> 1) The example implementation of the function doesn't check the
>> sys.flags.ignore_environment. Internally CPytho
On 24 November 2015 at 14:27, Laura Creighton wrote:
> In a message of Tue, 24 Nov 2015 14:05:53 +, Paul Moore writes:
>>Simply adding "people who have no control over their broken
>>infrastructure" with a note that this PEP helps them, would be
>>sufficient here (and actually helps the case f
Raymond,
I think you made a typographical error in your Counter.update example.
>>> from collections import Counter
>>> c = Counter(a=4, b=2, c=0, d=-2)
>>> d = Counter(a=1, b=-5, c=-2, d=6)
>>> c.update(d)
>>> c
Counter({'a': 5, 'd': 4, 'c': -2, 'b': -3})
Pair programming
On Mon, Nov 23, 2015 at 5:59 PM, Barry Warsaw wrote:
> I'm concerned about accepting PEP 493 making a strong recommendation to
> downstreams. Yes, in an ideal world we all want security by default, but I
> think the backward compatibility concerns of the PEP are understated,
> especially as they
On 24 November 2015 at 17:16, Toshio Kuratomi wrote:
> The long term answer for such environments is to update their internal
> certificate management to at least match the standards set by the public
> internet, but in the meantime, it is desirable to offer these administrators
> a way to c
On Tue, Nov 24, 2015 at 10:08 AM, Paul Moore wrote:
> I'm not actually sure that it's the place of this PEP to even comment
> on what the long term answer for such environments should be (or
> indeed, any answer, long term or not). I've argued the position that
> in some organisations it feels li
On 24 November 2015 at 18:37, Toshio Kuratomi wrote:
> I don't quite agree with this but it's probably moot in the face of
> the previous and certain cornercases. Self-signed certs work just
> fine with the backports to python-2.7.9+ but you have to add the ca to
> the clients. An organization t
On Tue, Nov 24, 2015 at 10:56 AM, Paul Moore wrote:
> On 24 November 2015 at 18:37, Toshio Kuratomi wrote:
>> The cornercases come
>> into play because you don't always control all of the devices and
>> services on your network. The site could evaluate and decide that
>> MITM isn't a threat to
Someone just added a leak to pickle.
On Tue, 24 Nov 2015 at 01:45 wrote:
> results for e5e507a357a6 on branch "default"
>
>
> test_asyncio leaked [3, 0, 0] memory blocks, sum=3
> test_functools leaked [0, 2, 2] memory blocks, sum=4
> test_pickle leake
Slots like PyTypeObject.tp_setattr, PySequenceMethods.sq_ass_item,
PyMappingMethods.mp_ass_subscript are used not only for setting
attribute/item value, but also for deleting attribute/item (if value is
NULL). This is not documented and should be. [1] Correspondingly public
API functions like
On 24.11.15 21:31, Brett Cannon wrote:
Someone just added a leak to pickle.
It always was here. I just added tests that expose it.
http://bugs.python.org/issue25725
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/l
Ooooh, that's probably really old code. I guess for the slots the
reasoning is to save on slots. For the public functions, alas it will
be hard to know if anyone is depending on it, even if it's
undocumented. Perhaps add a deprecation warning to these if the value
is NULL for one release cycle?
On
On 25 Nov 2015 05:42, "Toshio Kuratomi" wrote:
> >
>
> Yeah, I think you are correct in your understanding of what actual
> changes to the python distrribution are being proposed for
> redistributors in the PEP. Reading through the PEP again, I'm not
> sure if I'm correct in thinking that this o
On 25 November 2015 at 07:33, Guido van Rossum wrote:
> Ooooh, that's probably really old code. I guess for the slots the
> reasoning is to save on slots. For the public functions, alas it will
> be hard to know if anyone is depending on it, even if it's
> undocumented. Perhaps add a deprecation w
23 matches
Mail list logo
