On 22 January 2016 at 07:27, Emile van Sebille wrote:
> On 1/21/2016 10:42 AM, Paul Moore wrote:
>>
>> On 21 January 2016 at 17:18, Brett Cannon wrote:
>>>
>>> It's live: https://docs.python.org/devguide/#status-of-python-branches
>>
>> Nice :-)
>>
>> Minor nit, the status column says "end of lif
Zachary Ware writes:
> It's quite surprising to me, since all (as far as I know) PEPs are
> explicitly public domain. I am very much not a lawyer, though :)
The reason for any explicit CLA is CYA: you can't be sure that the
contributor DTRTs, so the CLA shows that the contribution was received
Emile van Sebille writes:
> I'd prefer end-of-support -- bet you can't count how many pre 2.5
> installations are still live.
I see your point, but (having just been thinking about CLAs and
Schneier's blog) have to suggest that software that has an explicit
"security support" period and is in
On 1/21/2016 10:42 AM, Paul Moore wrote:
On 21 January 2016 at 17:18, Brett Cannon wrote:
It's live: https://docs.python.org/devguide/#status-of-python-branches
Nice :-)
Minor nit, the status column says "end of life", but the text below
the table uses the term "end of line" (as does the com
I'm still yet to meet a lawyer who trusts "public domain" statements...
The CLA will ensure we have enough rights to republish the PEP on p.o or future
sites, and it doesn't prevent authors from also releasing the text elsewhere
under other terms.
Top-posted from my Windows Phone
-Original
On 21 January 2016 at 17:18, Brett Cannon wrote:
> It's live: https://docs.python.org/devguide/#status-of-python-branches
Nice :-)
Minor nit, the status column says "end of life", but the text below
the table uses the term "end of line" (as does the comment "Versions
older than 2.6 reached their
Thanks Victor for doing this. I'm starting a campaign to tell people about
it on Twitter. :-)
On Thu, Jan 21, 2016 at 9:18 AM, Brett Cannon wrote:
> It's live: https://docs.python.org/devguide/#status-of-python-branches
>
> On Wed, 20 Jan 2016 at 23:47 Victor Stinner
> wrote:
>
>> 2016-01-20 22
On Thu, Jan 21, 2016 at 11:12 AM, Brett Cannon wrote:
> On Wed, 20 Jan 2016 at 23:07 Nick Coghlan wrote:
>> - I wasn't aware of that
>> requirement, so I've never explicitly checked CLA status for folks
>> contributing packaging related PEPs. (And looking at the
>> just-checked-in PEP 513, I appa
It's live: https://docs.python.org/devguide/#status-of-python-branches
On Wed, 20 Jan 2016 at 23:47 Victor Stinner
wrote:
> 2016-01-20 22:22 GMT+01:00 Victor Stinner :
> > I pushed my table, it will be online in a few hours (I don't know when
> > the devguide is recompiled?):
> >
> http://docs.p
On Wed, 20 Jan 2016 at 23:07 Nick Coghlan wrote:
> On 21 January 2016 at 10:16, Brett Cannon wrote:
> > I just checked with Van and we should have CLAs for even PEP
> contributors,
> > so it will have to go through the same steps as the other ancillary
> > repositories.
>
> We should probably me
On 2016-01-21 3:34 AM, Victor Stinner wrote:
[..]
But if a global counter doesn't make the slow more complex and opens
new kinds of optimization, I agree to change my PEP 509.
Please. That would allow us to use ma_version to
implement caches in CPython itself.
Yury
2016-01-21 6:08 GMT+01:00 Yury Selivanov :
> Yeah, I think that's what we agreed on:
> https://mail.python.org/pipermail/python-dev/2016-January/142837.html
>
> The only advantage of ma_extra pointer is that it allows to add more stuff
> to dicts in the future.
I don't agree on ma_extra since I do
2016-01-21 2:54 GMT+01:00 Andrew Barnert :
> This idea worries me. I'm not sure why, but I think because of threading.
> After all, it's pretty rare for two threads to both want to work on the same
> dict, but very, very common for two threads to both want to work on _any_
> dict. So, imagine so
13 matches
Mail list logo
