[Python-Dev] Would somebody like to review issue27573 please?
I have a tiny patch for issue 27573, "code.interact() should print an exit message". http://bugs.python.org/issue27573 Its a one-line change to code.py, plus a dozen or so lines changed in test_code.py. If its not controversial, I think it would be nice to get it into 3.6. Thanks, -- 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] Issues in Python TLS
On Aug 13, 2016, at 04:14 PM, Benjamin Peterson wrote: >Correctness of TLS certificate verification is known to depend deeply on >distribution. Python began to verify certificates by default only in in >version 2.7.9. Many OS distributions (in particular, Ubuntu) did not >enable verification for their stable distributions for backwards >compatibility reasons. You might find looking at distro bugs for >CVE-2014-9365 edifying. In particular, we discussed this issue with the Ubuntu security team and decided that the backward compatibility issues required not enabling this by default for older versions. We did however include the mechanisms from PEP 493 so that end-users and system administrators could make different choices based on their own assessments and needs. Cheers, -Barry ___ 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] Review request: issue 27350, compact ordered dict
On 10/08/2016 17:06, Maciej Fijalkowski wrote: > * there are nice speedups > in this blog post https://morepypy.blogspot.fr/2015/01/faster-more-memory-efficient-and-more.html it is mentioned big speedup only on microbenchmark and small speedups on pypy benchmark. is it what you call nice speedups or does there is other things ? ___ 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] Changing the licence of statistics.py
On 8/14/2016 12:40 AM, Ned Deily wrote: On Aug 14, 2016, at 00:20, Steven D'Aprano wrote: I'm the author of statistics.py, and for historical reasons it was originally included in the standard library under the Apache licence. I now wish to change that and have it licenced under Python's standard licence. Is there anything I need to do other than just remove the Apache licence boilerplate from the file? I am not a lawyer nor an expert on this but you should read the following pages. It's explained there that the standard licenses for code contributed to Python itself *should* be either the Apache 2.0 License or the Academic Free License v2.1. https://www.python.org/psf/contrib/ https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq I believe you selected one of these when you signed the CA. -- Terry Jan Reedy ___ 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] Changing the licence of statistics.py
Please talk to the lawyers (IANAL TINLA). Steven d'Aprano writes: > I now wish to change that and have it licenced under Python's > standard licence. Is there anything I need to do other than just > remove the Apache licence boilerplate from the file? IMHO, no; in fact I would argue that its presence is a (cosmetic) bug.[1] Brett Cannon writes: > Are you the sole author of the statistics module prior to contributing it, > Steve? AFAICT, this doesn't matter. The only legally binding condition on contributors in the CA is choice of contribution license.[2] The CA itself states that this allows the PSF to distribute the contributed code under an open source license of the PSF's choice[3]. I interpret that to mean that any committer can remove language referring to contributors' licenses, implicitly changing the license to the "global" Python license.[4] (Again, IANAL, TINLA, ask VanL!) I don't see any ethical problem with this, as signing the CA implies the contributor approves this action in advance. Of course this is assuming that all authors signed the CA and therefore chose one of the two approved contributor licenses, but if they didn't there are bigger problems here. Footnotes: [1] I don't think there can be legal ramifications for the rest of Python, there are no copyleft licenses in sight. There could be a bit of trouble for the file itself if other contributors chose the AFL but there's no notice of the AFL -- AIUI legally the AFL allows you to do that but ethically it's fishy. [2] I guess there's an implied warranty of provenance, ie, the contributor has the right to contribute the code. [3] IIRC, "PSF's choice" means "Board-approved". [4] Of course these licenses allow *anybody* to sublicense with *any* license. Here the restriction to the Python license is due to the CA. I'm pretty sure that anything in the public repos has to be considered to be "distributed by the PSF" in the legal sense, and I believe that although the contributor license allows the PSF to use *any* license, the CA binds the PSF to distribute under a Board-approved open source license, or the contributor's original license. ___ 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] Review request: issue 27350, compact ordered dict
On Mon, Aug 15, 2016 at 6:02 AM, Xavier Combelle wrote: > > > On 10/08/2016 17:06, Maciej Fijalkowski wrote: >> * there are nice speedups >> > in this blog post > https://morepypy.blogspot.fr/2015/01/faster-more-memory-efficient-and-more.html > it is mentioned big speedup only on microbenchmark and small speedups on > pypy benchmark. is it what you call nice speedups or does there is other > things ? Yes, making dictionaries faster by a bit would not give you huge speedups everywhere. It'll give you a small, measurable speedup a bit everywhere. This is much better than a lot of things that cpython does which is a performance win. Note that there are two PEPs (sorted order in kwargs and sorted order in class names) which would be superseded by just reviewing this patch and merging it. Best regards, Maciej Fijalkowski ___ 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
