Mailman 3 March 2021 - Python-Dev

Reviving PEP 473
by Sebastian Kreft 16 Mar '21

16 Mar '21

Hi dev-team, I'm reopening the discussion of PEP 473, which was closed due to: *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).* Before the PEP was rejected by the SC, I had submitted https://github.com/python/cpython/pull/6271 and the last response said: *You may propose a newly revised PEP which overcomes the last SC feedback.But without the accepted PEP, this PR can not be merged.* Please clarify how can I proceed with adding some of the specified fields to the mentioned exceptions. Should I create a new PEP as suggested in the PR or should we create individual BPO issues for each exception modification. -- Sebastian Kreft

4 4

Rejecting PEP 637 (Support for indexing with keyword arguments)
by Thomas Wouters 16 Mar '21

16 Mar '21

Hi Stefano, Thank you for submitting PEP 637 (Support for indexing with keyword arguments). The Steering Council has reviewed the PEP and after careful consideration, we have decided to reject the PEP. There are a number of reasons for this, but fundamentally we do not believe the benefit is great enough to outweigh the cost of the new syntax. The benefits of the new syntax as outlined in the PEP are not particularly strong, and community support for the new syntax seems low. The new syntax doesn’t provide an obvious way to do something that is currently error-prone, and doesn’t open up new possibilities that were not possible before. While there are certainly cases that could use the new syntax, for many of them it’s not clear that it would be a win, or that third-party libraries would indeed use the syntax. The Steering Council isn’t really convinced by any of the suggested uses in the PEP. The strongest argument for the new syntax comes from the typing side of Python. The Steering Council is not particularly convinced it is of significant benefit to the static type checking language, but even if it were, at this point we’re reluctant to add general Python syntax that only (or mostly) benefits the static typing language. If the syntax would be of great benefit to static typing, it might be time to discuss letting go of the requirement that the typing language be a subset of Python -- but whether this feature is important enough to consider that is up to the typing community. The SC considers the cost of the new syntax significant. It’s not a natural fit, as shown by the corner cases discussed in the PEP. It’s difficult to teach, as indexing and function calls are not as interchangeable or equivalent as they may appear. Looking at more complex expressions with the new syntax, mentally parsing them is significantly harder than the equivalent without the new syntax, even if it requires more lines of code to do the same thing. In addition to all that, the SC is worried about the performance of indexing in CPython and in other Python implementations, considering it’s a very common operation, and about the suggested new __getitem__ protocol, particularly the confusing corner cases of indexing with keywords and zero or one positional items. These are not, however, the main reason we decided to reject the PEP. With our appreciation, For the whole Python Steering Council, Thomas. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

5 5

Accepting PEP 624 (Remove Py_UNICODE encoder APIs)
by Thomas Wouters 16 Mar '21

16 Mar '21

Hi Inada, Thank you for submitting PEP 624 (Remove Py_UNICODE encoder APIs). The Steering Council is happy to accept it, but we do have two conditions. We want to make sure that the documentation is clear on what is deprecated, and when they are scheduled to be removed. For example, PyUnicode_TransformDecimalToASCII is itself not currently marked as deprecated (although the section header does mention the deprecation, that is easy to miss), PyUnicode_TranslateCharmap is scheduled for removal in 4.0, and PyUnicode_AsUnicode has two deprecation notices, one mentioning removal in 3.10 and one in 3.12. We would also like to make sure users who need to migrate off of these APIs have the information necessary to do so. The PEP currently lists alternatives with caveats, and it's not immediately obvious from the PEP or the API documentation what the right alternative is for those caveats. As a condition of this PEP’s acceptance, we request that you fully document the recommended workarounds for these caveats. We do recognise that PyUnicode_EncodeDecimal is currently entirely undocumented. Documenting at this stage is probably not worth the effort, but perhaps it could be mentioned in a brief ‘porting’ section in the PEP instead. With the Python Steering Council's gratitude, Thomas. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

2 1

Accepting PEP 597 (Add optional EncodingWarning)
by Thomas Wouters 16 Mar '21

16 Mar '21

Hi Inada, Thank you for submitting PEP 597 (Add optional EncodingWarning). The Steering Council is happy with the PEP, and hereby accepts it. The SC is of the opinion that we should move towards making UTF-8 the default encoding, and this PEP will make it easier to do so, and mitigate some of the confusion around the default encoding in the meantime. That being said, the SC would like to invite you and others with interest to work on a PEP for a long term plan to, in fact, change the default encoding to UTF-8. We don't want to make irrevocable decisions until we have a clear, viable plan with a good upgrade path and with community support, but we do believe we need to make that decision sooner rather than later. With thanks from the whole Python Steering Council, Thomas. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

4 3

PEP 647 (type guards) -- final call for comments
by Guido van Rossum 15 Mar '21

15 Mar '21

I think we have reached consensus on PEP 647 in typing-sig. We have implementations for mypy and pyright, not sure about the rest. This PEP does not affect CPython directly except for the addition of one special item (TypeGuard) to typing.py -- it would be nice to get that in the 3.10 stdlib. I'm CC'ing python-dev here to see if there are any further comments; if not, we can initiate the approval process by creating an issue at https://github.com/python/steering-council. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>

17 36

Summary of Python tracker Issues
by Python tracker 12 Mar '21

12 Mar '21

ACTIVITY SUMMARY (2021-03-05 - 2021-03-12) 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 7478 (+34) closed 47738 (+36) total 55216 (+70) Open issues with patches: 2968 Issues opened (56) ================== #43198: Operations on sets more than hundred times less efficient with https://bugs.python.org/issue43198 reopened by rhettinger #43411: wm_manage fails with ttk.Frame https://bugs.python.org/issue43411 opened by mfncooper #43412: object.h -Wcast-qual warning https://bugs.python.org/issue43412 opened by petere #43413: tuple subclasses allow kwargs https://bugs.python.org/issue43413 opened by jaraco #43414: os.get_terminal_size() should use file descriptors in Windows https://bugs.python.org/issue43414 opened by eryksun #43416: Add README files in Include/cpython and Include/internal https://bugs.python.org/issue43416 opened by serhiy.storchaka #43417: ast.unparse: Simplify buffering logic https://bugs.python.org/issue43417 opened by BTaskaya #43418: FTPLib module crashes when server returns byte message instead https://bugs.python.org/issue43418 opened by hugochiaxyz8 #43419: contextvars does not work properly in asyncio REPL. https://bugs.python.org/issue43419 opened by lanfon72 #43420: Optimize rational arithmetics https://bugs.python.org/issue43420 opened by Sergey.Kirpichev #43421: os.device_encoding(fd) should support any console fd in Window https://bugs.python.org/issue43421 opened by eryksun #43422: Revert _decimal C API changes https://bugs.python.org/issue43422 opened by pitrou #43424: Document the `controller.name` field in `webbrowser` module https://bugs.python.org/issue43424 opened by ilyagr #43425: test_peg_generator.test_c_parser emits DeprecationWarning due https://bugs.python.org/issue43425 opened by xtreak #43426: test_importlib.test_windows emits deprecation warning over usa https://bugs.python.org/issue43426 opened by xtreak #43427: Possible error on the descriptor howto guide https://bugs.python.org/issue43427 opened by marcosmodenesi #43428: Sync importlib_metadata enhancements through 3.7. https://bugs.python.org/issue43428 opened by jaraco #43429: mmap.size() raises OSError on Unix for anonymous memory https://bugs.python.org/issue43429 opened by ZackerySpytz #43430: Exception raised when attempting to create Enum via functional https://bugs.python.org/issue43430 opened by suhailsingh247 #43431: Subprocess timeout causes output to be returned as bytes in te https://bugs.python.org/issue43431 opened by macdjord #43432: Add function `clear` to the `os` module https://bugs.python.org/issue43432 opened by parsampsh #43433: xmlrpc.client ignores query in URI ("?action=xmlrpc2") since p https://bugs.python.org/issue43433 opened by OndrejPtak #43434: sqlite3.Connection(...) bypasses 'sqlite3.connect' audit hooks https://bugs.python.org/issue43434 opened by erlendaasland #43437: venv activate bash script has wrong line endings on windows https://bugs.python.org/issue43437 opened by jmoguill2 #43438: [doc] sys.addaudithook() documentation should be more explicit https://bugs.python.org/issue43438 opened by vstinner #43441: [Subinterpreters]: global variable next_version_tag cause meth https://bugs.python.org/issue43441 opened by JunyiXie #43442: multicorevm: guarantee type multi sub interpreters safe https://bugs.python.org/issue43442 opened by JunyiXie #43443: Should shelve support dict union? https://bugs.python.org/issue43443 opened by Dominik V. #43444: [sqlite3] Move MODULE_NAME def from setup.py to module.h https://bugs.python.org/issue43444 opened by erlendaasland #43447: Generate vectorcall code to parse arguments using Argument Cli https://bugs.python.org/issue43447 opened by vstinner #43451: pydoc terminal suboptimal rendering of complex annotations https://bugs.python.org/issue43451 opened by dw #43452: Microoptimize PyType_Lookup for cache hits https://bugs.python.org/issue43452 opened by dino.viehland #43453: docs: runtime_checkable example refers to changed behavior in https://bugs.python.org/issue43453 opened by Henry Schreiner #43454: [sqlite3] Add support for R*Tree callbacks https://bugs.python.org/issue43454 opened by erlendaasland #43455: pathlib mistakenly assumes os.getcwd() is a resolved path in W https://bugs.python.org/issue43455 opened by eryksun #43457: Include simple file loading and saving functions in JSON stand https://bugs.python.org/issue43457 opened by nervecenter #43458: Tutorial should mention about variable scope in try/except/fin https://bugs.python.org/issue43458 opened by deekox #43459: Race conditions when the same source file used to build mutlip https://bugs.python.org/issue43459 opened by mgorny #43460: Exception copy error https://bugs.python.org/issue43460 opened by douglas-raillard-arm #43461: Tottime column for cprofile output does not add up https://bugs.python.org/issue43461 opened by jonathanfrawley #43462: canvas.bbox returns None on 'hidden' items while coords doesn' https://bugs.python.org/issue43462 opened by Vincent #43463: typing.get_type_hints with TYPE_CHECKING imports / getting hin https://bugs.python.org/issue43463 opened by The Compiler #43464: set intersections should short-circuit https://bugs.python.org/issue43464 opened by josh.r #43465: ./configure --help describes what --with-ensurepip does poorly https://bugs.python.org/issue43465 opened by ngie #43466: ssl/hashlib: Add configure option to set or auto-detect rpath https://bugs.python.org/issue43466 opened by christian.heimes #43468: functools.cached_property locking is plain wrong. https://bugs.python.org/issue43468 opened by ztane #43471: Fails to import bz2 on Ubuntu https://bugs.python.org/issue43471 opened by xxm #43472: [security][subinterpreters] Add auditing hooks to subinterpret https://bugs.python.org/issue43472 opened by christian.heimes #43473: Junks in difflib https://bugs.python.org/issue43473 opened by hubertbdlb #43474: http.server.BaseHTTPRequestHandler end_header() fails https://bugs.python.org/issue43474 opened by grumblor #43475: Worst-case behaviour of hash collision with float NaN https://bugs.python.org/issue43475 opened by congma #43476: Enabling access to showsyntaxerror for IDLE's shell https://bugs.python.org/issue43476 opened by aroberge #43477: from x import * behavior inconsistent between module types. https://bugs.python.org/issue43477 opened by kaorihinata #43478: Disallow Mock spec arguments from being Mocks https://bugs.python.org/issue43478 opened by msuozzo #43479: Remove a duplicate comment and assignment in http.client https://bugs.python.org/issue43479 opened by maggyero #43480: Add .path method/property to tempfile.* for a pathlib.Path https://bugs.python.org/issue43480 opened by pxeger Most recent 15 issues with no replies (15) ========================================== #43480: Add .path method/property to tempfile.* for a pathlib.Path https://bugs.python.org/issue43480 #43479: Remove a duplicate comment and assignment in http.client https://bugs.python.org/issue43479 #43478: Disallow Mock spec arguments from being Mocks https://bugs.python.org/issue43478 #43477: from x import * behavior inconsistent between module types. https://bugs.python.org/issue43477 #43476: Enabling access to showsyntaxerror for IDLE's shell https://bugs.python.org/issue43476 #43473: Junks in difflib https://bugs.python.org/issue43473 #43472: [security][subinterpreters] Add auditing hooks to subinterpret https://bugs.python.org/issue43472 #43465: ./configure --help describes what --with-ensurepip does poorly https://bugs.python.org/issue43465 #43464: set intersections should short-circuit https://bugs.python.org/issue43464 #43461: Tottime column for cprofile output does not add up https://bugs.python.org/issue43461 #43459: Race conditions when the same source file used to build mutlip https://bugs.python.org/issue43459 #43458: Tutorial should mention about variable scope in try/except/fin https://bugs.python.org/issue43458 #43455: pathlib mistakenly assumes os.getcwd() is a resolved path in W https://bugs.python.org/issue43455 #43453: docs: runtime_checkable example refers to changed behavior in https://bugs.python.org/issue43453 #43451: pydoc terminal suboptimal rendering of complex annotations https://bugs.python.org/issue43451 Most recent 15 issues waiting for review (15) ============================================= #43466: ssl/hashlib: Add configure option to set or auto-detect rpath https://bugs.python.org/issue43466 #43459: Race conditions when the same source file used to build mutlip https://bugs.python.org/issue43459 #43455: pathlib mistakenly assumes os.getcwd() is a resolved path in W https://bugs.python.org/issue43455 #43454: [sqlite3] Add support for R*Tree callbacks https://bugs.python.org/issue43454 #43452: Microoptimize PyType_Lookup for cache hits https://bugs.python.org/issue43452 #43451: pydoc terminal suboptimal rendering of complex annotations https://bugs.python.org/issue43451 #43444: [sqlite3] Move MODULE_NAME def from setup.py to module.h https://bugs.python.org/issue43444 #43441: [Subinterpreters]: global variable next_version_tag cause meth https://bugs.python.org/issue43441 #43434: sqlite3.Connection(...) bypasses 'sqlite3.connect' audit hooks https://bugs.python.org/issue43434 #43432: Add function `clear` to the `os` module https://bugs.python.org/issue43432 #43429: mmap.size() raises OSError on Unix for anonymous memory https://bugs.python.org/issue43429 #43428: Sync importlib_metadata enhancements through 3.7. https://bugs.python.org/issue43428 #43427: Possible error on the descriptor howto guide https://bugs.python.org/issue43427 #43422: Revert _decimal C API changes https://bugs.python.org/issue43422 #43420: Optimize rational arithmetics https://bugs.python.org/issue43420 Top 10 most discussed issues (10) ================================= #43420: Optimize rational arithmetics https://bugs.python.org/issue43420 15 msgs #43466: ssl/hashlib: Add configure option to set or auto-detect rpath https://bugs.python.org/issue43466 9 msgs #43438: [doc] sys.addaudithook() documentation should be more explicit https://bugs.python.org/issue43438 8 msgs #43353: Document that logging.getLevelName() can return a numeric valu https://bugs.python.org/issue43353 7 msgs #43366: Unclosed bracket bug in code.interact prevents identifying syn https://bugs.python.org/issue43366 7 msgs #43443: Should shelve support dict union? https://bugs.python.org/issue43443 6 msgs #43475: Worst-case behaviour of hash collision with float NaN https://bugs.python.org/issue43475 6 msgs #43413: tuple subclasses allow kwargs https://bugs.python.org/issue43413 5 msgs #43462: canvas.bbox returns None on 'hidden' items while coords doesn' https://bugs.python.org/issue43462 5 msgs #28356: [easy doc] Document os.rename() behavior on Windows when src a https://bugs.python.org/issue28356 4 msgs Issues closed (35) ================== #14678: Update zipimport to support importlib.invalidate_caches() https://bugs.python.org/issue14678 closed by brett.cannon #16322: time.tzname on Python 3.3.0 for Windows is decoded by wrong en https://bugs.python.org/issue16322 closed by eryksun #25741: Usual Installation Directory https://bugs.python.org/issue25741 closed by eryksun #28259: Ctypes bug windows https://bugs.python.org/issue28259 closed by eryksun #31466: No easy way to change float formatting when subclassing encode https://bugs.python.org/issue31466 closed by methane #38033: Use After Free: PyObject_Free (valgrind) https://bugs.python.org/issue38033 closed by vstinner #42382: No easy way to get the distribution which provided a importlib https://bugs.python.org/issue42382 closed by jaraco #43287: Use PEP 590 vectorcall to speed up calls to filter() https://bugs.python.org/issue43287 closed by corona10 #43332: Make http.client._tunnel send one byte string over the network https://bugs.python.org/issue43332 closed by gregory.p.smith #43338: Provide offical installers for security releases https://bugs.python.org/issue43338 closed by terry.reedy #43356: PyErr_SetInterrupt should have an equivalent that takes a sign https://bugs.python.org/issue43356 closed by pitrou #43365: Operation conflict between time package and file https://bugs.python.org/issue43365 closed by terry.reedy #43372: ctypes: test_frozentable fails when make regen-frozen https://bugs.python.org/issue43372 closed by nascheme #43374: Apple refuses apps written in Python https://bugs.python.org/issue43374 closed by ned.deily #43379: Pasting multiple lines in the REPL is broken since 3.9 https://bugs.python.org/issue43379 closed by terry.reedy #43391: The comments have invalid license information (broken Python 2 https://bugs.python.org/issue43391 closed by lemburg #43397: Incorrect conversion path case with german character https://bugs.python.org/issue43397 closed by eryksun #43405: DeprecationWarnings in test_unicode https://bugs.python.org/issue43405 closed by methane #43406: Possible race condition between signal catching and signal.sig https://bugs.python.org/issue43406 closed by pitrou #43407: time.monotonic(): Docs imply comparing call N and call N+M is https://bugs.python.org/issue43407 closed by terry.reedy #43415: Typo in dataclasses documentation https://bugs.python.org/issue43415 closed by eric.smith #43423: Subprocess IndexError possible in _communicate https://bugs.python.org/issue43423 closed by gregory.p.smith #43435: Py_BuildValue("y#".... returns incomplete result https://bugs.python.org/issue43435 closed by dwoodjunkmail #43436: bounded _lru_cache_wrapprer behaves as if typed=True when it w https://bugs.python.org/issue43436 closed by rhettinger #43439: [security] Add audit events on GC functions giving access to a https://bugs.python.org/issue43439 closed by christian.heimes #43440: Enable rtree support in SQLite https://bugs.python.org/issue43440 closed by steve.dower #43445: Add frozen modules to sys.stdlib_module_names https://bugs.python.org/issue43445 closed by vstinner #43446: Wrong character in footnote https://bugs.python.org/issue43446 closed by berker.peksag #43448: exec() ignores scope. https://bugs.python.org/issue43448 closed by mark.dickinson #43449: multiprocessing.Pool - crash in subprocess causes deadlock in https://bugs.python.org/issue43449 closed by jkp #43450: List amnesia https://bugs.python.org/issue43450 closed by christian.heimes #43456: Remove _xxsubinterpreters from sys.stdlib_module_names https://bugs.python.org/issue43456 closed by vstinner #43467: IDLE: horizontal scrollbar https://bugs.python.org/issue43467 closed by terry.reedy #43469: Python 3.6 fails to run on MacOS (Big Sur 11.2.3) https://bugs.python.org/issue43469 closed by ned.deily #43470: Installation of Python 3.6.13 fails on MacOS Big Sur 11.2.3 https://bugs.python.org/issue43470 closed by ned.deily

1 0

Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642
by Python Steering Council 12 Mar '21

12 Mar '21

After much deliberation, the Python Steering Council is happy to announce that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, collectively known as the Pattern Matching PEPs. We acknowledge that Pattern Matching is an extensive change to Python and that reaching consensus across the entire community is close to impossible. Different people have reservations or concerns around different aspects of the semantics and the syntax (as does the Steering Council). In spite of this, after much deliberation, reviewing all conversations around these PEPs, as well as competing proposals and existing poll results, and after several in-person discussions with the PEP authors, we are confident that Pattern Matching as specified in PEP 634, et al, will be a great addition to the Python language. We also recognize that such a large new feature needs to be accompanied by comprehensive documentation and specification, both in the tutorial section of the documentation and in the language reference. We consider that the presence of such high-quality documentation must be present on the first release of Python 3.10, and therefore its absence should be considered a release blocker. We do not consider the PEPs or any possible external documentation to be sufficient. At the same time, we’re rejecting PEPs 640 and 642. Both PEPs have received little support from core developers. PEP 642’s proposed syntax does not seem like the right way to solve the jagged edges in PEP 634’s syntax, although the SC understands the desire to improve those aspects of the Pattern Matching proposal. Regarding that, we would also like to mention that changes building on top of PEP 634 (even PEPs 640 and 642 if they now gain support) can still be submitted via the PEP process for review using the regular channels (discussions in python-dev or the https://discuss.python.org/ server), followed by a formal submission to the Steering Council for consideration, taking into account that backwards-incompatible changes can only be made before the feature freeze point of Python 3.10. See PEP 619 (https://www.python.org/dev/peps/pep-0619/) for details on the release schedule for Python 3.10. We know that Pattern Matching has been a challenging feature that has sparked considerable discussions and design conversations, leading to several revisions from feedback stemming from the community, core devs, and the Steering Council. We are very happy to see that the Python developer community remains passionate and respectful, and we are sure that the result has benefited a lot because of it. Congratulations to the PEP(s) authors: Guido, Brandt, Tobias, Daniel, Talin, and everyone that participated in the discussion and implementation of this important new feature! -The Python Steering Council

5 4

Python history: origin of the arrow annotation
by Steven D'Aprano 11 Mar '21

11 Mar '21

I was curious how and why return annotations use the arrow `->` symbol, so I went spelunking into the depths of the Python-Ideas and Python-Dev mailing lists. Much to my surprise, I couldn't find any discussion or debate about it. Eventually I tracked the discussion back to a mailing list I didn't even know existed, Types-Sig, all the way back to 13th Dec 1999, where I found this email by Tim Hochberg: https://mail.python.org/pipermail/types-sig/1999-December/000281.html suggesting the arrow symbol for all type declarations. This appears to be the first suggestion of the arrow symbol for type annotations in Python. I am surprised that type checking was being discussed so long ago. Python was not even a decade old, and if my calculations are correct, the versions at the time would have been 1.5.2 and 1.6.0. But I am especially amazed that the choice of symbol seems to have been accepted with very little argument or debate about alternative colours for the bike-shed. I can't find any suggestions for alternative symbols such as `=>` `-->` `==>` `->>` etc, and very little for keywords such as `as`. The day after Tim posted, Tony Lownds suggested `as` and then immediately suggested using Tim's arrow symbol for the return type only: https://mail.python.org/pipermail/types-sig/1999-December/000335.html and then as far as I can tell, we've never looked back. If there is anyone whose memory reaches back that far, does that sound right? -- Steve

5 4

[Release management] schedule for renaming the default branch
by Pablo Galindo Salgado 11 Mar '21

11 Mar '21

Hi, I am writing on behalf of the Python Release Management team. The Steering Council has requested the RM team to schedule and perform the necessary changes to rename the default branch from master to main. # The changes What follows is the technical description of the changes and the timeline. In order to keep this thread focused on this particular aspect, if you wish to discuss anything related to the change itself, please, open a new email thread or reuse an existing one. - The change will be executed ***when beta 1 is released***, as the beta 1 release requires some branching engineering already to create the 3.10 branch and point 3.11 to the new one as well as changing CI, buildbots...etc ** *This is scheduled for Monday, 2021-05-03**.* - The CI will be adapted to work with the new "main" branch. - The buildbots will be adapted to work with the new "main" branch. - Branch protection rules will be adapted. - The different bots will be adapted by the respective bot maintainer teams. - All the URLs that point to master in the README and other places will be adapted to point to main instead (notice this is not strictly necessary because GitHub redirects automatically). Notice that the renaming will automatically: - Re-target any open pull requests - Update any draft releases based on the branch - Move any branch protection rules that explicitly reference the old name - Show a notice to repository contributors, maintainers, and admins on the repository homepage with instructions to update local copies of the repository - Show a notice to contributors who git push to the old branch - Redirect web requests for the old branch name to the new branch name - Return a "Moved Permanently" response in API requests for the old branch name Check this <https://github.com/github/renaming> for more information. # What you need to do? You just need to update your local clone after the branch name changes. From the local clone of the repository on a computer, run the following commands to update the name of the default branch. $ git branch -m master main $ git fetch origin $ git branch -u origin/main main Apart from that, you should update any local script or command that uses the name "master" to use the name "main". Regards from windy London, Pablo Galindo Salgado

4 6

Steering Council update for February
by Pablo Galindo Salgado 11 Mar '21

11 Mar '21

Hi everyone, The Steering Council just published the community update for February: https://github.com/python/steering-council/blob/main/updates/2021-02-steeri… As a reminder, we'll are trying to keep this up monthly. As you can see we are mainly focusing on clearing the PEP backlog and to address ongoing efforts and time-sensitive issues. Here you can find the text for the update: February 01 - After more deliberation and consideration of all available information, the Steering Council accepted the Pattern Matching PEPs. The Steering Council agreed that high-quality documentation is crucial in this feature and therefore its presence should be required before the release. A response in the name of the Steering Council will be sent to python-dev addressing the decision and the Steering Council view of the process. - The Steering Council discussed Debian's Python distro issues. The Steering Council will collect and communicate where the concerns are to the Debian maintainers. Thomas started a draft of the communication that the Steering Council will review, complete and sign-off. <https://github.com/python/steering-council/blob/main/updates/2021-02-steeri…>February 08 - The Steering Council started the discussion of PEP 651. It was decided that the group will leave this open for next week to better deliberate and consider more information. - The Steering Council discussed the ongoing work on porting types in the standard library to heap-types. It was decided that through Pablo, the Steering Council will ask the core developers driving those changes to create an informational PEP and not to make any more changes in this area after beta 1, as per our general policy. - The Steering Council discussed adding a TOML module to the standard library. It was decided that maintainers should write a PEP. On the topic of the standard library, it was agreed that the Steering Council should present at the PyCon US 2021 Language Summit on the future of the standard library and Brett is going to gather data on what PRs are tied to which module, which modules are imported and used the most, commit churn to help start the planning so we can make data-driven discussions and decisions. - The acceptance notice for PEP 634 will be sent from the Steering Council email, and Thomas will send rejection notices to other competing PEPs that are therefore rejected. <https://github.com/python/steering-council/blob/main/updates/2021-02-steeri…>February 15 [ The SC could not meet this week due to holidays in the US and Canada, and the impossibility to find a common replacement date in the week ] <https://github.com/python/steering-council/blob/main/updates/2021-02-steeri…>February 22 - The Steering Council discussed PEP 651 request and has decided to reject it. An email with the rationale will be sent to the author and python-dev. - Ezio joined the Steering Council meeting today to give an update on the GitHub Migration. GitHub was dormant during the holiday months. Ezio and GH had a productive meeting a couple of weeks ago. He is working on the tool that will convert bpo issues into a format that the GH tool will accept. He will also work on a community update once the test repo is ready. Another sync up has been scheduled between Ezio and the SC on March 29th. - The Steering Council discussed renaming the master branch to main and the consensus was that we should do that. The group is going to discuss the timeline and how to approach this with other repositories under the Python organization in some future meeting. - The Steering Council discussed the Debian situation. The group discussed ways to approach the situation and how to coordinate with Debian maintainers so it can benefit the Python community at large. It was decided that the steering council will email the Debian maintainers to try to reach some common ground and discuss how to proceed. Regards from cloudy London, Pablo Galindo Salgado

25 41