Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython
On Fri, 8 Mar 2019 at 16:52, Karthikeyan wrote: > Personally, I think more people will love it once they get to use it so if > something like 100 issues can be migrated to a sample repo with labels, > content etc. We're already using GitHub issues for pretty much everything in Python core development that *isn't* CPython itself, and even for CPython, folks experience the core issue management interface in the overview page for pull requests. One of the requests we made at the Language Summit discussion last year was for Mariatta to enhance PEP 581 with additional discussion of what would need to change to bring the Roundup instance up to the point of being competitive with the GitHub issues user experience, which she added: * https://www.python.org/dev/peps/pep-0581/#issues-with-roundup-bpo * https://www.python.org/dev/peps/pep-0581/#why-not-focus-on-improving-roundup-bpo There's been plenty of time since then for folks to put forward a competing proposal to modernise the Roundup UI directly instead of migrating to a different issue tracking tool, but so far no such proposal has emerged. One of the other blockers was the fact that the Contributor Licensing Agreement process was tightly coupled to some custom fields in b.p.o [1], and that is now very close to being resolved thanks to Mariatta's efforts (and provides a nice workflow improvement in its own right). Cheers, Nick. [1] https://www.python.org/dev/peps/pep-0581/#update-the-cla-host -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Initial updates to PEP 1 for Steering Council based governance
On Fri, 15 Mar 2019 at 03:01, Victor Stinner wrote: > > Hi, > > Le lun. 11 mars 2019 à 13:26, Nick Coghlan a écrit : > > This is the smallest change to PEP 1 that we consider potentially viable: > > handling all PEPs through the BDFL-Delegate model, with the Steering > > Council's primary involvement being to appoint the delegates (or accept > > their volunteering), once a PEP has reached the point of being actively > > reviewed. > > Does it mean that very controversial PEPs like PEP 572 would have a > BDFL-delegate as well? The delegate will be the only one taking the > final decision? Steering Council members can be BDFL-Delegates, so for particularly controversial PEPs, it's most likely that: 1. the BD will be a Steering Council member 2. they'll be serving as a spokesperson for the SC in relation to that PEP and consulting with the rest of the SC before making any pronouncements, rather than operating independently That seems likely to provide clearer communication both inside and outside the SC than if we leave the responsibility for communicating the status of affected PEPs to the SC as a whole. However, we don't think it makes sense to handle *every* PEP that way, since there's non-trivial overhead in making and communicating decisions as a 5-person team, rather than as a more autonomous individual decision maker. Even when the BD isn't a Steering Council member themselves though, the intent is for them to rely on the SC members for advice and support if they feel they need it, as described in this paragraph from the revised PEP 1: The final authority for PEP approval is the Steering Council. However, whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL-Delegate for that PEP, and they will then have the authority to approve (or reject) that PEP. Individuals taking on this responsibility are free to seek additional guidance from the Steering Council at any time, and are also expected to take the advice and perspectives of other core developers into account. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Rejecting PEP 542 -- Dot Notation Assignment In Function Header
The steering council has decided to reject PEP 542 as the idea never seemed to gain traction. Thanks to Markus Meskanen for taking the time to write the PEP. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deferring PEP 536 -- Final Grammar for Literal String Interpolation
The steering council decided to defer PEP 536 until an implementation is available. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Reject PEP 472: Support for indexing with keyword arguments
The idea never seemed to gain any traction over its near 5 years in existence as a PEP. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Rejecting PEP 473: Adding structured data to built-in exceptions
The steering council felt the PEP was too broad and not focused enough. Discussions about adding more attributes to built-in exceptions can continue on the issue tracker on a per-exception basis (and obviously here for any broader points, e.g. performance implications as I know that has come up before when the idea of storing relevant objects on exceptions). Thanks to Sebastian Kreft for taking the time to write the PEP in the first place. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2019-03-08 - 2019-03-15) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7048 (+17) closed 41009 (+46) total 48057 (+63) Open issues with patches: 2798 Issues opened (48) == #4459: bdist_rpm should enable --fix-python by default https://bugs.python.org/issue4459 reopened by vstinner #10948: Trouble with dir_util created dir cache https://bugs.python.org/issue10948 reopened by eric.araujo #30040: new empty dict can be more small https://bugs.python.org/issue30040 reopened by rhettinger #33376: [pysqlite] Duplicate rows can be returned after rolling back a https://bugs.python.org/issue33376 reopened by benjamin.peterson #36245: PCBuild/build.bat errors, probably from space characters in pa https://bugs.python.org/issue36245 opened by Jess #36246: csv.writer lineterminator affects csv escaping https://bugs.python.org/issue36246 opened by flow2k #36247: zipfile - extract truncates (existing) file when bad password https://bugs.python.org/issue36247 opened by CristiFati #36250: pdb: interaction might cause "ValueError: signal only works in https://bugs.python.org/issue36250 opened by blueyed #36253: Use after free in ctypes test suite https://bugs.python.org/issue36253 opened by btharper #36254: Fix invalid uses of %d in format strings in C https://bugs.python.org/issue36254 opened by serhiy.storchaka #36255: Provide a simple way to delete and edit python's welcome messa https://bugs.python.org/issue36255 opened by benp #36256: parser module fails on legal input https://bugs.python.org/issue36256 opened by A. Skrobov #36257: configure with --with-icc --with-cxx-main=icpc https://bugs.python.org/issue36257 opened by aminiussi #36258: Incorrect docstring of the ssl module https://bugs.python.org/issue36258 opened by Ofekmeister #36259: exception text is being sourced from the wrong file https://bugs.python.org/issue36259 opened by rhubarbdog x #36260: Cpython/Lib vulnerability found and request a patch submission https://bugs.python.org/issue36260 opened by krnick #36261: email examples should not gratuitously mess with preamble https://bugs.python.org/issue36261 opened by era #36263: test_hashlib.test_scrypt() fails on Fedora 29 https://bugs.python.org/issue36263 opened by vstinner #36265: Remove ABCs from collections https://bugs.python.org/issue36265 opened by jwilk #36266: Which module could not be found? https://bugs.python.org/issue36266 opened by phillip.m.feld...@gmail.com #36267: User input to argparse raises Index_Error: "-a=" on a 'store_ https://bugs.python.org/issue36267 opened by paul.j3 #36268: Change default tar format to modern POSIX 2001 (pax) for bette https://bugs.python.org/issue36268 opened by CAM-Gerlach #36270: DOC: Add link to sys.exc_info for "Reference Manual" https://bugs.python.org/issue36270 opened by cheryl.sabella #36271: '_io.TextIOWrapper' object has no attribute 'mode' https://bugs.python.org/issue36271 opened by nemeskeyd #36272: Recursive logging crashes Interpreter in Python 3 https://bugs.python.org/issue36272 opened by Saim Raza #36273: test_thread leaks a core dump on PPC64 AIX 3.x https://bugs.python.org/issue36273 opened by vstinner #36274: http.client cannot send non-ASCII request lines https://bugs.python.org/issue36274 opened by tburke #36275: DOC: venv.create doesn't include prompt parameter https://bugs.python.org/issue36275 opened by cheryl.sabella #36276: Python urllib CRLF injection vulnerability https://bugs.python.org/issue36276 opened by ragdoll.guo #36277: pdb's recursive debug command is not listed in the docs https://bugs.python.org/issue36277 opened by Antony.Lee #36279: os.wait3() leaks some uninitialized stack when no processes ex https://bugs.python.org/issue36279 opened by dw #36281: OSError: handle is closed for ProcessPoolExecutor and run_in_e https://bugs.python.org/issue36281 opened by basnijholt #36283: eval is needlessly limited https://bugs.python.org/issue36283 opened by bup #36285: Integer overflow in array.array.remove() https://bugs.python.org/issue36285 opened by sth #36286: Random failure in test_idle https://bugs.python.org/issue36286 opened by serhiy.storchaka #36287: Make ast.dump() not output optional default fields https://bugs.python.org/issue36287 opened by serhiy.storchaka #36290: _ast.ast_type_init does not handle args and kwargs correctly. https://bugs.python.org/issue36290 opened by remi.lapeyre #36292: Coverity scan: Resource leaks in longobject.c https://bugs.python.org/issue36292 opened by cstratak #36293: Nonblocking read sys.stdin raises error https://bugs.python.org/issue36293 opened by cykerway #36295: Need to yield (sleep(0)) twice in asyncio https://bugs.python.org/issue36295 opened by Assaf Dayan #36297: Remove unicode_internal codec
Re: [Python-Dev] (Licensing question) PSF license
On Tue, 12 Mar 2019 01:27:14 -0400 Terry Reedy wrote: > > First of all, I'm sorry if I'm wrong. I'm not lawyer. > > > > You can use both of GPL and MIT. Users can use your package under it. > > > > On the other hand, when you publish your package, *you* should follow > > PSF license. > > Read this. https://docs.python.org/3/license.html > > > > """ > > 3. In the event Licensee prepares a derivative work that is based on or > > incorporates Python 3.7.2 or any part thereof, and wants to make the > > derivative work available to others as provided herein, then Licensee > > hereby > > agrees to include in any such work a brief summary of the changes > > made to Python > > 3.7.2. > > """ > > > > As you can see, PSF license doesn't force you to use PSF license. (not > > "copyleft") > > In fact, the PSF lawyer says one should not use the 'PSF license' as it > is specilized for the PSF and Python. Interesting. I did use the PSF license for the pickle5 backport and I suspect I'm not the only one to use it (though I don't know how to do a per-license search on PyPI). https://pypi.org/project/pickle5/ Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] int() and math.trunc don't accept objects that only define __index__
Le 15 mars 2019 à 03:49:19, Steven D'Aprano
(st...@pearwood.info(mailto:st...@pearwood.info)) a écrit:
> On Wed, Mar 13, 2019 at 03:21:31AM -0700, Rémi Lapeyre wrote:
>
> > When __index__ is defined it means that there is a lossless conversion
> > to int possible. In this case, this means a lossless conversion to
> > float and complex is also possible
>
> That's not correct:
>
> py> n = 2**64 + 1
> py> n == int(float(n))
> False
Thanks, I should have thought of that. Do you think __index__ should
only define
__int__ then?
> Python floats (C doubles) can lose digits when converting from ints
> over 2**53 or so.
>
>
> > (with the exception of overflows
> > but anyone doing float(var) should expect them).
>
> I don't. I expect float(var) to overflow to infinity, if it is going to
> overflow, and always forget that it can raise.
>
>
> py> float("9e")
> inf
>
> py> float(str(9*10**))
> inf
>
> But:
>
> py> float(9*10**)
> Traceback (most recent call last):
> File "", line 1, in
> OverflowError: int too large to convert to float
>
> This never fails to surprise me.
>
>
>
>
> --
> Steven
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/remi.lapeyre%40henki.fr
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Register-based VM [Was: Possible performance regression]
On Mon, 11 Mar 2019 18:03:26 -0400 David Mertz wrote: > Parrot got rather further along than rattlesnake as a register based VM. I > don't think it every really beat CPython in speed though. > > http://parrot.org/ But Parrot also had a "generic" design that was supposed to cater for all dynamic programming languages. AFAIU, it was heavily over-engineered and under-staffed, and the design documents were difficult to understand. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
