Mailman 3 July 2019 - Python-Dev

Removing dead bytecode vs reporting syntax errors
by Pablo Galindo Salgado July 8, 2019

July 8, 2019

Hi, Recently, we moved the optimization for the removal of dead code of the form if 0: .... to the ast so we use JUMP bytecodes instead (being completed in PR14116). The reason is that currently, any syntax error in the block will never be reported. For example: if 0: return if 1: pass else: return while 0: return at module level do not raise any syntax error (just some examples), In https://bugs.python.org/issue37500 it was reported that after that, code coverage will … [View More]

12 17

Steering Council Update for July 2019
by Carol Willing July 8, 2019

July 8, 2019

I've posted an update from the Steering Council to our repo: https://github.com/python/steering-council/blob/master/updates/2019-07-08_s… I will also link to this on python-dev and on Discourse (discuss.python.org ). For completeness, below is the full text. # Steering Council Update ## Date: 2019-07-08 Steering Council updates will be posted irregularly and as needed. We provide these updates to foster open and transparent communication about Steering Council activity. We strive to … [View More]post at least once every month. # Message from the Steering Council Sorry we've been silent for a while! With PyCon in Cleveland, the Language Summit, Sprints, PEP activity, and a Python 3.8 beta release, it's been a busy and productive May and June. Thank you all for your contributions. Below are some of the outcomes of our weekly Steering Council conversations. --- ## Mandate This section organizes Steering Council (SC) activity and projects using the mandates listed in PEP 13. ### Language > Maintain the quality and stability of the Python language and CPython interpreter - Inspired by Russell Keith-Magee's PyCon keynote about Black Swan events, the Steering Council is looking at what may impact Python for the next decade. We have been discussing this within the Steering Council and writing up some thoughts on major challenges facing Python. We'll continue to edit and polish this vision document and share it when we are ready for wider comment. ### Contributors > Make contributing as accessible, inclusive, and sustainable as possible - **Communications channels:** We are very pleased with the move of python-dev, etc. to Mailman 3. We now have a modern UI and easy search across mailing lists. Just a reminder to recap where announcements and conversations are taking place: - To reach core committers specifically, we will use python-committers(a)python.org. - To reach the entire Python developer community, we will use python-dev(a)python.org. - For specific requests to the SC (e.g., PEP reviews), please use our public GitHub tracker at https://github.com/python/steering-council/issues. - To reach just the SC, you can email us at steering-council(a)python.org. - We will also occasionally use Discourse, at https://discuss.python.org (for example, Discourse is useful for polls and votes). ### PEPs > Establish appropriate decision-making processes for PEPs - To request a PEP review, please file an issue on the [SC issue tracker](https://github.com/python/steering-council/issues). PEP highlights include: - PEP 570, "Python Positional-Only Parameters", by Larry Hastings, Pablo Galindo and others. *Appointed Guido van Rossum as BD.* "Completed." - PEP 574, "Pickle protocol 5 with out-of-band data", Antoine Pitrou. *Appointed Nick Coghlan as BD.* "Marked Final." - PEPs 576, 579, 580, 590 (competing PEPs on C function call optimizations by Mark Shannon and Jeroen Demeyer; note that PEP 576 is withdrawn in favor of PEP 590). *Appointed Petr Viktorin as BD.* "Accepted 590." - PEP 578, "Python Runtime Audit Hooks", Steve Dower. *Appointed Christian Heimes as BD.* "Landed, about to be marked Final." ### Interaction with PSF > Formalize and maintain the relationship between the core team and the PSF - We began discussions about fundraising ideas for CPython projects and administrative support. - A [donation page]([https://www.python.org/psf/donations/python-dev/](https://www.python… was created by the PSF and was linked from the [CPython repo]([https://github.com/python/cpython](https://github.com/python/cpython…. Any funds that are donated will be used for Core Developers to attend the core development sprints (to start; future possibilities are dependent on the amount of funds gathered). - At the Steering Council's recommendation, the PSF also is looking at hiring a Project Manager to manage communication and some logistics for the 2020 Python 2.7 End of Life. - The PSF Code of Conduct Workgroup is working on a revision of the CoC and its approval by the PSF board. Brett and Carol serve on the Workgroup. ### Governance > Seek consensus among contributors and the core team before acting in a formal capacity, > Act as a "court of final appeal" for decisions where all other methods have failed. - The weekly SC meeting cadence (Tuesdays 3-4pm US West Coast time) has been working out well. --- ## Reference This reference section summarizes the Steering Council's mandate and powers. ### Mandate (PEP 13) The steering council shall work to: - Maintain the quality and stability of the Python language and CPython interpreter, - Make contributing as accessible, inclusive, and sustainable as possible, - Formalize and maintain the relationship between the core team and the PSF, - Establish appropriate decision-making processes for PEPs, - Seek consensus among contributors and the core team before acting in a formal capacity, - Act as a "court of final appeal" for decisions where all other methods have failed. ### Powers (PEP 13) The council has broad authority to make decisions about the project. For example, they can: - Accept or reject PEPs - Enforce or update the project's code of conduct - Work with the PSF to manage any project assets - Delegate parts of their authority to other subcommittees or processes [View Less]

2 3

Summary of Python tracker Issues
by Python tracker July 5, 2019

July 5, 2019

ACTIVITY SUMMARY (2019-06-28 - 2019-07-05) 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: open 7068 (+14) closed 42192 (+53) total 49260 (+67) Open issues with patches: 2838 Issues opened (49) ================== #29312: Use FASTCALL in dict.update() https://bugs.python.org/issue29312 reopened by inada.naoki #34602: python3 resource.setrlimit strange … [View More]

1 0

Change SystemError to NOT inherit from Exception
by Jeroen Demeyer July 4, 2019

July 4, 2019

A SystemError is typically raised from C to indicate serious bugs in the application which shouldn't normally be caught and handled. It's used for example for NULL arguments where a Python object is expected. So in some sense, SystemError is the Python equivalent of a segmentation fault. Since these exceptions should typically not be handled in a try/except Exeption block, I suggest to make SystemError inherit directly from BaseException instead of Exception.

3 4

strip behavior provides inconsistent results with certain strings
by dan＠bauman.space July 3, 2019

July 3, 2019

Anyone experienced anything like this? The behavior seems consistent but unexpected. python 3.6 on both windows (10) and linux (ubuntu 18.04) seem to exhibit the same odd behavior. something about a docker-image looking string seems to trigger this behavior. The behavior seems as expected for other strings. Python 3.6.5 |Anaconda, Inc.| (default, Mar 29 2018, 13:32:41) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. … [View More]

15 21

[RELEASE] Python 3.7.4rc2 is now available for testing
by Ned Deily July 2, 2019

July 2, 2019

Python 3.7.4rc2 is now available. 3.7.4rc2 is the second release preview of the next maintenance release of Python 3.7, the latest feature release of Python. Assuming no further critical problems are found prior to 2019-07-08, no code changes are planned between this release candidate and the final release. The release candidate is intended to give you the opportunity to test the new security and bug fixes in 3.7.4. Because of the small number of changes between rc1, the original release … [View More]

1 0

[RELEASE] Python 3.6.9 security-fix release is now available
by Ned Deily July 2, 2019

July 2, 2019

Python 3.6.9 is now available. 3.6.9 is the first security-only-fix release of Python 3.6. Python 3.6 has now entered the security fix phase of its life cycle. Only security-related issues are accepted and addressed during this phase. We plan to provide security fixes for Python 3.6 as needed through 2021, five years following its initial release. Security fix releases are produced periodically as needed and only provided in source code form; binary installers are not provided. We urge you to … [View More]

1 0

Annoying user on GitHub
by Guido van Rossum July 2, 2019

July 2, 2019

There's a user on GitHub ('experimentalles') who has created random PRs on several projects (e.g. https://github.com/python/peps/pull/1116). Can we ban them? The PRs look the work of a vandal or a bot, not of a clueless human. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>

9 9

PEP 581 has been updated with "Downsides of GitHub" section
by Mariatta July 2, 2019

July 2, 2019

Hi, I've updated PEP 581 yesterday, adding the "Downsides of GitHub" section. https://www.python.org/dev/peps/pep-0581/#downsides-of-github Other parts of the PEP has also been updated to reflect recent changes to roundup/bpo that happened after PEP 581's acceptance, for example: - ability to automatically close issues when a PR has been merged. This was added to bpo after PEP 581's acceptance. I've also created an issue in devguide so that this can be documented: https://github.com/python/… [View More]

13 14

Re: strip behavior provides inconsistent results with certain strings
by Brian Skinn July 2, 2019

July 2, 2019

It seems to me that the desired behavior is closest to 'str.replace()' out of all the options, just with the constraint of being limited to either the start or the end of the string. (Thus the .lreplace() and .rreplace() option suggested by Glenn earlier in the thread.) The minimal change (which actually also seems pretty general) seems to me to be adding *only_start* and *only_end* keyword arguments to str.replace(), both defaulting to False. If, e.g., *only_start* is passed True, each … [View More]

1 0