Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub
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 that the name "Python" is reserved so that users can know that Python-Dev's strict (or not so, YMMV) QA policies have been applied and promises (or lack thereof) of support are valid, and to avoid gratuitous claims against the PSF by people who take use of the trademark to mean that it's PSF-sponsored or at least PSF-sanctioned. That is a perfectly reasonable way for third parties to behave, since it's the PSF's responsibility to defend its trademark. Note that trademark is unlike patent and copyright, which are unconditional whether or not infringers have been punished before. OTOH, trademark must be defended, because when the reputational capital depreciates too much US courts will refuse to enforce trademark. We say trademark protection is "use it or lose it". It's a moot point here because Guido and Van are satisfied with the response of the author so far. But I fear that since Guido declared that no "Python 2.8" will ever exist, failure to object to that name would be all the evidence a court would need to decide that we don't care enough about the trademark, making it that much more difficult to enforce in the future. (IANAL and it's been ~15 years since I've looked at law or cases on trademark, but I suppose it's still true.) 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 that patch Python or break out the stdlib or docs into a separate package call their package "python". But you'd have to ask a real lawyer and maybe find a court case on that. Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub
[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? > > 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 that the > name "Python" is reserved so that users can know that Python-Dev's > strict (or not so, YMMV) QA policies have been applied These are QA'd: https://www.python.org/downloads/ Other [prefix] Python [suffix] distributions are not officially QA'd by the core Python team. > and promises > (or lack thereof) of support are valid, https://docs.python.org/3/license.html#terms-and- conditions-for-accessing-or-otherwise-using-python ``` 4. PSF is making Python 3.5.2 available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 3.5.2 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON 3.5.2 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 3.5.2, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. ``` > > and to avoid gratuitous claims > against the PSF by people who take use of the trademark to mean that > it's PSF-sponsored or at least PSF-sanctioned. These are the PSF releases: https://www.python.org/downloads/ There are many redistributions with various patches applied. > That is a perfectly > reasonable way for third parties to behave, since it's the PSF's > responsibility to defend its trademark. > > Note that trademark is unlike patent and copyright, which are > unconditional whether or not infringers have been punished before. > OTOH, trademark must be defended, because when the reputational > capital depreciates too much US courts will refuse to enforce > trademark. We say trademark protection is "use it or lose it". > > It's a moot point here because Guido and Van are satisfied with the > response of the author so far. But I fear that since Guido declared > that no "Python 2.8" will ever exist, failure to object to that name > would be all the evidence a court would need to decide that we don't > care enough about the trademark, making it that much more difficult to > enforce in the future. (IANAL and it's been ~15 years since I've > looked at law or cases on trademark, but I suppose it's still true.) > > 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 that patch Python or break out > the stdlib or docs into a separate package call their package > "python". But you'd have to ask a real lawyer and maybe find a court > case on that. > There's really a "ship of theseus" argument: it is defacto standard practice for downstream distributions to distribute modified copies of Python while retaining the name Python. How extensive those patches are is likely irrelevant to a trademark dispute (of which there is none here). IIUC, when a developer forks (e.g. clicks "fork" w/ github.com/python/cpython), there is still no need to change the repository name. > > Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub
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 general question, you can ask it too, but don't be surprised if the answer is "it depends on the specific circumstances". -- Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub
~ 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 don't seem to be asking any > questions, just making statements. > > If you have a concrete, specific question, please ask it. If its a > general question, you can ask it too, but don't be surprised if the > answer is "it depends on the specific circumstances". > > > -- > Steve > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > burkhardameier%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub
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 that patch Python or break out >> the stdlib or docs into a separate package call their package >> "python". But you'd have to ask a real lawyer and maybe find a court >> case on that. > > There's really a "ship of theseus" argument: it is defacto standard practice > for downstream distributions to distribute modified copies of Python while > retaining the name Python. How extensive those patches are is likely > irrelevant to a trademark dispute (of which there is none here). 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 audit trail). Distros don't do all that extra work just for the fun of it - it's an essential part of keeping track of who's ultimately responsible for which pieces in a way that's transparent to recipients of the software. Ensuring we aren't taking excessive liberties with the language definition is also one of the reasons we sometimes seek explicit permission for deviations - it documents that those particular changes still fit within the bounds of what counts as "Python". However, we've drifted well off-topic for python-dev now (the PSF's management of the legal marks is handled by the Trademarks Comittee and the PSF Board rather than python-dev), so if you'd like to learn more about trademark law and how it applies to open source projects in general, I'd suggest taking advantage of the extensive material available online rather than posting further here (the history of the Firefox/Iceweasel disagreement between Mozilla and Debian is a particularly interesting case study). Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
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 functions of PyObject_CallFunction() family to > > use internally fast calls. > > (...) > > http://bugs.python.org/issue28915 > > Oh, I forgot to mention the performance results of these changes. > Python slots are now a little bit faster. Extract of the issue: > http://bugs.python.org/issue28915#msg282748 > > Microbenchmark on a simple class with an __int__() method, call int(o): > int(o): Median +- std dev: [ref] 239 ns +- 13 ns -> [patch] 219 ns +- > 14 ns: 1.10x faster (-9%) > > Microbenchmark on a simple class with an __getitem__() method, call o[100]: > o[100]: Median +- std dev: [ref] 211 ns +- 11 ns -> [patch] 172 ns +- > 11 ns: 1.23x faster (-19%) > > > Comparison between Python 2.7, 3.5, 3.7 and 3.7+patch, 3.5 is used as > the reference: > > int(o) > == > > Median +- std dev: [3.5] 271 ns +- 15 ns -> [3.7] 239 ns +- 13 ns: > 1.13x faster (-12%) > Median +- std dev: [3.5] 271 ns +- 15 ns -> [patch] 219 ns +- 14 ns: > 1.24x faster (-19%) > Median +- std dev: [3.5] 271 ns +- 15 ns -> [2.7] 401 ns +- 21 ns: > 1.48x slower (+48%) > > o[100] > == > > Median +- std dev: [3.5] 206 ns +- 5 ns -> [3.7] 211 ns +- 11 ns: > 1.02x slower (+2%) > Not significant! > Median +- std dev: [3.5] 206 ns +- 5 ns -> [patch] 172 ns +- 11 ns: > 1.20x faster (-17%) > Median +- std dev: [3.5] 206 ns +- 5 ns -> [2.7] 254 ns +- 15 ns: > 1.23x slower (+23%) > > Victor > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > annakoppad%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] On time complexity of heapq.heapify
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) # Transform bottom-up. The largest index there's any point to looking at # is the largest with a child index in-range, so must have 2*i + 1 < n, # or i < (n-1)/2. If n is even = 2*j, this is (2*j-1)/2 = j-1/2 so # j-1 is the largest, which is n//2 - 1. If n is odd = 2*j+1, this is # (2*j+1-1)/2 = j so j-1 is the largest, and that's again n//2-1. for i in reversed(range(n//2)): _siftup(x, i) >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 creating a heap by calling heappush multiple times, I believe the time complexity remains the same. Although I had a hard time finding out the exact time complexity for that particular function, I think it is closer to O(log(n!)) than to O(n). I would be very happy to see an explanation as to why the time is O(n) (it does not seem possible to me to create a heap of n numbers in such runtime). However, if no one has a convincing argument, I'd rather omit time complexity information from documentation (given that this analysis is not made for the other functions either). []'s Rafael ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On time complexity of heapq.heapify
> 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 creating a heap by calling heappush multiple times, I believe the time > complexity remains the same. > > Although I had a hard time finding out the exact time complexity for that > particular function, I think it is closer to O(log(n!)) than to O(n). Hello Rafael, 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 algorithm - How can building a heap be O(n) time complexity? - StackOverflow https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=complexity%20of%20heapify Data Structures Heap, Heap Sort & Priority Queue https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=complexity%20of%20heapify Sub tree rooted at i is a max heap. Simple bound: – O(n) calls to MAX-HEAPIFY, – Each of which takes O(lg n), – Complexity: O(n lg n). – Thus, the running time of BUILD-MAX-HEAP is O(n). Here's a more detailed explanation: http://www.cs.umd.edu/~meesh/351/mount/lectures/lect14-heapsort-analysis-part.pdf If you have other follow-ups, please take this discussion to another list. This list is for the development of the Python core and not for general questions about algorithms or use of the language. Raymond Hettinger ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub
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 audit trail). Distros don't do all that extra > work just for the fun of it - it's an essential part of keeping track > of who's ultimately responsible for which pieces in a way that's > transparent to recipients of the software. Ensuring we aren't taking > excessive liberties with the language definition is also one of the > reasons we sometimes seek explicit permission for deviations - it > documents that those particular changes still fit within the bounds of > what counts as "Python". For clarification: By "we" in the above paragraph, you mean Red Hat, not the PSF, right? You have two affiliations. :) ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On time complexity of heapq.heapify
> 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
>
>
> algorithm - How can building a heap be O(n) time complexity? - StackOverflow
> https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=complexity%20of%20heapify
>
> Data Structures Heap, Heap Sort & Priority Queue
> https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=complexity%20of%20heapify
> Sub tree rooted at i is a max heap. Simple bound:
> – O(n) calls to MAX-HEAPIFY,
> – Each of which takes O(lg n), – Complexity: O(n lg n).
> – Thus, the running time of BUILD-MAX-HEAP is O(n).
>
> Here's a more detailed explanation:
> http://www.cs.umd.edu/~meesh/351/mount/lectures/lect14-heapsort-analysis-part.pdf
>
> If you have other follow-ups, please take this discussion to another list.
> This list is for the development of the Python core and not for general
> questions about algorithms or use of the language.
I forgot to attach the measurements that demonstrate the O(n) complexity:
# Python 3 Code
from heapq import heapify
from random import randrange
cmp_cnt = 0
class Int(int):
def __lt__(self, other):
global cmp_cnt
cmp_cnt += 1
return super.__lt__(self, other)
def trial(n):
global cmp_cnt
data = [Int(randrange(100)) for i in range(n)]
cmp_cnt = 0
heapify(data)
return cmp_cnt
for n in [100, 1000, 1, 10, 100, 1000]:
print("n = {:<10d}compares = {}".format(n, trial(n)))
Which outputs:
n = 100 compares = 155
n = 1000 compares = 1620
n = 1 compares = 16446
n = 10compares = 164779
n = 100 compares = 1649165
n = 1000 compares = 16493429
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub
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 (rather than just posting the end >> result without a clear audit trail). Distros don't do all that extra >> work just for the fun of it - it's an essential part of keeping track >> of who's ultimately responsible for which pieces in a way that's >> transparent to recipients of the software. Ensuring we aren't taking >> excessive liberties with the language definition is also one of the >> reasons we sometimes seek explicit permission for deviations - it >> documents that those particular changes still fit within the bounds of >> what counts as "Python". > > For clarification: By "we" in the above paragraph, you mean Red Hat, > not the PSF, right? You have two affiliations. :) You're right, I should be clearer about my pronouns. Technically I'm referring to the Fedora Python SIG here, as I don't have the authority to speak on behalf of Red Hat itself. There may be visible correlations between the redistribution practices of Fedora, RHEL, and CentOS, though :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
