Wes Turner writes:
> So forks with modules added or removed cannot be called Python?
> Forks without the blessing of the PSF cannot be called Python?
> That's really not open source.
Of course it is. The source is open and free.
But that's not what is in play here. The legal theory is tha
[Continuing to play devil's advocate for the sake of clarification]
On Mon, Dec 12, 2016 at 2:40 AM, Stephen J. Turnbull wrote:
> Wes Turner writes:
>
> > So forks with modules added or removed cannot be called Python?
> > Forks without the blessing of the PSF cannot be called Python?
> > Tha
On Mon, Dec 12, 2016 at 03:10:09AM -0600, Wes Turner wrote:
> [Continuing to play devil's advocate for the sake of clarification]
Clarification of *what* exactly? You don't seem to be asking any
questions, just making statements.
If you have a concrete, specific question, please ask it. If its a
~ Just upgrade to Python 3.6 and forget about this non~sense! ~
On Mon, Dec 12, 2016 at 2:53 AM, Steven D'Aprano
wrote:
> On Mon, Dec 12, 2016 at 03:10:09AM -0600, Wes Turner wrote:
> > [Continuing to play devil's advocate for the sake of clarification]
>
> Clarification of *what* exactly? You d
On 12 December 2016 at 19:10, Wes Turner wrote:
> On Mon, Dec 12, 2016 at 2:40 AM, Stephen J. Turnbull
> wrote:
>> Exactly how lenient an open source project can be with naming of
>> forks, I don't know. I would hope that courts would not look amiss at
>> the common practice of letting distros t
I am not sure, but soon, I will be a great fan of your work, once I get to
work on this!
Thank your for inspiring me to work on these stuff!
Best regards,
Annapoornima
On Fri, Dec 9, 2016 at 11:33 PM, Victor Stinner
wrote:
> 2016-12-09 18:46 GMT+01:00 Victor Stinner :
> > Last days, I patched
Hello,
Current heapify documentation says it takes linear time
https://docs.python.org/3/library/heapq.html#heapq.heapify
However, investigating the code (Python 3.5.2) I saw this:
def heapify(x):
"""Transform list into a heap, in-place, in O(len(x)) time."""
n = len(x)
> On Dec 11, 2016, at 1:38 PM, Rafael Almeida wrote:
>
> From what I gather, _siftup(heap, pos) does not run in constant time, but
> rather it runs in time proportional to the height of the subtree with root in
> ``pos''. Although, according to the in-code comments, it should be faster
> than
On Tue, Dec 13, 2016 at 12:18 AM, Nick Coghlan wrote:
> It absolutely *is* relevant, as is how diligent the redistributors are
> in differentiating between the unmodified upstream project and the
> patches we have applied post-release (rather than just posting the end
> result without a clear audi
> On Dec 12, 2016, at 8:12 AM, Raymond Hettinger
> wrote:
>
> The heapify() algorithm is well known and well studied. A quick Google
> search turns up plenty of explanations:
> https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=complexity%20of%20heapify
>
>
> al
On 13 December 2016 at 02:12, Chris Angelico wrote:
> On Tue, Dec 13, 2016 at 12:18 AM, Nick Coghlan wrote:
>> It absolutely *is* relevant, as is how diligent the redistributors are
>> in differentiating between the unmodified upstream project and the
>> patches we have applied post-release (rath
11 matches
Mail list logo
