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
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
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 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
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
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
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
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: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 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 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
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 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
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 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
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 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
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 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
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 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 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 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
23 matches
Mail list logo
