Mailman 3 June 2020 - Python-Dev

Mixed Python/C debugging
by Skip Montanaro April 26, 2023

April 26, 2023

Having tried comp.lang.python with no response, I turn here... After at least ten years away from Python's run-time interpreter & byte code compiler, I'm getting set to familiarize myself with that again. This will, I think, entail debugging a mixed Python/C environment. I'm an Emacs user and am aware that GDB since 7.0 has support for debugging at the Python code level. Is Emacs+GDB my best bet? Are there any Python IDEs which support C-level breakpoints and debugging? Thanks, Skip

5 6

PEP 448 review
by Guido van Rossum March 29, 2023

March 29, 2023

I'm back, I've re-read the PEP, and I've re-read the long thread with "(no subject)". I think Georg Brandl nailed it: """ *I like the "sequence and dict flattening" part of the PEP, mostly because itis consistent and should be easy to understand, but the comprehension syntaxenhancements seem to be bad for readability and "comprehending" what the codedoes.The call syntax part is a mixed bag on the one hand it is nice to be consistent with the extended possibilities in literals (flattening), but on the other hand there would be small but annoying inconsistencies anyways (e.g. the duplicate kwarg case above).* """ Greg Ewing followed up explaining that the inconsistency between dict flattening and call syntax is inherent in the pre-existing different rules for dicts vs. keyword args: {'a':1, 'a':2} results in {'a':2}, while f(a=1, a=2) is an error. (This form is a SyntaxError; the dynamic case f(a=1, **{'a': 1}) is a TypeError.) For me, allowing f(*a, *b) and f(**d, **e) and all the other combinations for function calls proposed by the PEP is an easy +1 -- it's a straightforward extension of the existing pattern, and anybody who knows what f(x, *a) does will understand f(x, *a, y, *b). Guessing what f(**d, **e) means shouldn't be hard either. Understanding the edge case for duplicate keys with f(**d, **e) is a little harder, but the error messages are pretty clear, and it is not a new edge case. The sequence and dict flattening syntax proposals are also clean and logical -- we already have *-unpacking on the receiving side, so allowing *x in tuple expressions reads pretty naturally (and the similarity with *a in argument lists certainly helps). From here, having [a, *x, b, *y] is also natural, and then the extension to other displays is natural: {a, *x, b, *y} and {a:1, **d, b:2, **e}. This, too, gets a +1 from me. So that leaves comprehensions. IIRC, during the development of the patch we realized that f(*x for x in xs) is sufficiently ambiguous that we decided to disallow it -- note that f(x for x in xs) is already somewhat of a special case because an argument can only be a "bare" generator expression if it is the only argument. The same reasoning doesn't apply (in that form) to list, set and dict comprehensions -- while f(x for x in xs) is identical in meaning to f((x for x in xs)), [x for x in xs] is NOT the same as [(x for x in xs)] (that's a list of one element, and the element is a generator expression). The basic premise of this part of the proposal is that if you have a few iterables, the new proposal (without comprehensions) lets you create a list or generator expression that iterates over all of them, essentially flattening them: >>> xs = [1, 2, 3] >>> ys = ['abc', 'def'] >>> zs = [99] >>> [*xs, *ys, *zs] [1, 2, 3, 'abc', 'def', 99] >>> But now suppose you have a list of iterables: >>> xss = [[1, 2, 3], ['abc', 'def'], [99]] >>> [*xss[0], *xss[1], *xss[2]] [1, 2, 3, 'abc', 'def', 99] >>> Wouldn't it be nice if you could write the latter using a comprehension? >>> xss = [[1, 2, 3], ['abc', 'def'], [99]] >>> [*xs for xs in xss] [1, 2, 3, 'abc', 'def', 99] >>> This is somewhat seductive, and the following is even nicer: the *xs position may be an expression, e.g.: >>> xss = [[1, 2, 3], ['abc', 'def'], [99]] >>> [*xs[:2] for xs in xss] [1, 2, 'abc', 'def', 99] >>> On the other hand, I had to explore the possibilities here by experimenting in the interpreter, and I discovered some odd edge cases (e.g. you can parenthesize the starred expression, but that seems a syntactic accident). All in all I am personally +0 on the comprehension part of the PEP, and I like that it provides a way to "flatten" a sequence of sequences, but I think very few people in the thread have supported this part. Therefore I would like to ask Neil to update the PEP and the patch to take out the comprehension part, so that the two "easy wins" can make it into Python 3.5 (basically, I am accepting two-thirds of the PEP :-). There is some time yet until alpha 2. I would also like code reviewers (Benjamin?) to start reviewing the patch <http://bugs.python.org/issue2292>, taking into account that the comprehension part needs to be removed. -- --Guido van Rossum (python.org/~guido)

7 17

PEP 1, PEP Purpose and Guidelines
by barry＠zope.com May 18, 2021

May 18, 2021

It has been a while since I posted a copy of PEP 1 to the mailing lists and newsgroups. I've recently done some updating of a few sections, so in the interest of gaining wider community participation in the Python development process, I'm posting the latest revision of PEP 1 here. A version of the PEP is always available on-line at http://www.python.org/peps/pep-0001.html Enjoy, -Barry -------------------- snip snip -------------------- PEP: 1 Title: PEP Purpose and Guidelines Version: $Revision: 1.36 $ Last-Modified: $Date: 2002/07/29 18:34:59 $ Author: Barry A. Warsaw, Jeremy Hylton Status: Active Type: Informational Created: 13-Jun-2000 Post-History: 21-Mar-2001, 29-Jul-2002 What is a PEP? PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, or describing a new feature for Python. The PEP should provide a concise technical specification of the feature and a rationale for the feature. We intend PEPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Python. The PEP author is responsible for building consensus within the community and documenting dissenting opinions. Because the PEPs are maintained as plain text files under CVS control, their revision history is the historical record of the feature proposal[1]. Kinds of PEPs There are two kinds of PEPs. A standards track PEP describes a new feature or implementation for Python. An informational PEP describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementors are free to ignore informational PEPs or follow their advice. PEP Work Flow The PEP editor, Barry Warsaw <peps(a)python.org>, assigns numbers for each PEP and changes its status. The PEP process begins with a new idea for Python. It is highly recommended that a single PEP contain a single key proposal or new idea. The more focussed the PEP, the more successfully it tends to be. The PEP editor reserves the right to reject PEP proposals if they appear too unfocussed or too broad. If in doubt, split your PEP into several well-focussed ones. Each PEP must have a champion -- someone who writes the PEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The PEP champion (a.k.a. Author) should first attempt to ascertain whether the idea is PEP-able. Small enhancements or patches often don't need a PEP and can be injected into the Python development work flow with a patch submission to the SourceForge patch manager[2] or feature request tracker[3]. The PEP champion then emails the PEP editor <peps(a)python.org> with a proposed title and a rough, but fleshed out, draft of the PEP. This draft must be written in PEP style as described below. If the PEP editor approves, he will assign the PEP a number, label it as standards track or informational, give it status 'draft', and create and check-in the initial draft of the PEP. The PEP editor will not unreasonably deny a PEP. Reasons for denying PEP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Python philosophy. The BDFL (Benevolent Dictator for Life, Guido van Rossum) can be consulted during the approval phase, and is the final arbitrator of the draft's PEP-ability. If a pre-PEP is rejected, the author may elect to take the pre-PEP to the comp.lang.python newsgroup (a.k.a. python-list(a)python.org mailing list) to help flesh it out, gain feedback and consensus from the community at large, and improve the PEP for re-submission. The author of the PEP is then responsible for posting the PEP to the community forums, and marshaling community support for it. As updates are necessary, the PEP author can check in new versions if they have CVS commit permissions, or can email new PEP versions to the PEP editor for committing. Standards track PEPs consists of two parts, a design document and a reference implementation. The PEP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the PEP. Standards Track PEPs must include an implementation - in the form of code, patch, or URL to same - before it can be considered Final. PEP authors are responsible for collecting community feedback on a PEP before submitting it for review. A PEP that has not been discussed on python-list(a)python.org and/or python-dev(a)python.org will not be accepted. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include, setting up a separate SIG mailing list for the topic, having the PEP author accept private comments in the early design phases, etc. PEP authors should use their discretion here. Once the authors have completed a PEP, they must inform the PEP editor that it is ready for review. PEPs are reviewed by the BDFL and his chosen consultants, who may accept or reject a PEP or send it back to the author(s) for revision. Once a PEP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the BDFL, the status will be changed to `Final.' A PEP can also be assigned status `Deferred.' The PEP author or editor can assign the PEP this status when no progress is being made on the PEP. Once a PEP is deferred, the PEP editor can re-assign it to draft status. A PEP can also be `Rejected'. Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact. PEPs can also be replaced by a different PEP, rendering the original obsolete. This is intended for Informational PEPs, where version 2 of an API can replace version 1. PEP work flow is as follows: Draft -> Accepted -> Final -> Replaced ^ +----> Rejected v Deferred Some informational PEPs may also have a status of `Active' if they are never meant to be completed. E.g. PEP 1. What belongs in a successful PEP? Each PEP should have the following parts: 1. Preamble -- RFC822 style headers containing meta-data about the PEP, including the PEP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc. 2. Abstract -- a short (~200 word) description of the technical issue being addressed. 3. Copyright/public domain -- Each PEP must either be explicitly labelled as placed in the public domain (see this PEP as an example) or licensed under the Open Publication License[4]. 4. Specification -- The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Python platforms (CPython, JPython, Python .NET). 5. Motivation -- The motivation is critical for PEPs that want to change the Python language. It should clearly explain why the existing language specification is inadequate to address the problem that the PEP solves. PEP submissions without sufficient motivation may be rejected outright. 6. Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. 7. Backwards Compatibility -- All PEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The PEP must explain how the author proposes to deal with these incompatibilities. PEP submissions without a sufficient backwards compatibility treatise may be rejected outright. 8. Reference Implementation -- The reference implementation must be completed before any PEP is given status 'Final,' but it need not be completed before the PEP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for either the Python language reference or the standard library reference. PEP Template PEPs are written in plain ASCII text, and should adhere to a rigid style. There is a Python script that parses this style and converts the plain text PEP to HTML for viewing on the web[5]. PEP 9 contains a boilerplate[7] template you can use to get started writing your PEP. Each PEP must begin with an RFC822 style header preamble. The headers must appear in the following order. Headers marked with `*' are optional and are described below. All other headers are required. PEP: <pep number> Title: <pep title> Version: <cvs version string> Last-Modified: <cvs date string> Author: <list of authors' real names and optionally, email addrs> * Discussions-To: <email address> Status: <Draft | Active | Accepted | Deferred | Final | Replaced> Type: <Informational | Standards Track> * Requires: <pep numbers> Created: <date created on, in dd-mmm-yyyy format> * Python-Version: <version number> Post-History: <dates of postings to python-list and python-dev> * Replaces: <pep number> * Replaced-By: <pep number> The Author: header lists the names and optionally, the email addresses of all the authors/owners of the PEP. The format of the author entry should be address(a)dom.ain (Random J. User) if the email address is included, and just Random J. User if the address is not given. If there are multiple authors, each should be on a separate line following RFC 822 continuation line conventions. Note that personal email addresses in PEPs will be obscured as a defense against spam harvesters. Standards track PEPs must have a Python-Version: header which indicates the version of Python that the feature will be released with. Informational PEPs do not need a Python-Version: header. While a PEP is in private discussions (usually during the initial Draft phase), a Discussions-To: header will indicate the mailing list or URL where the PEP is being discussed. No Discussions-To: header is necessary if the PEP is being discussed privately with the author, or on the python-list or python-dev email mailing lists. Note that email addresses in the Discussions-To: header will not be obscured. Created: records the date that the PEP was assigned a number, while Post-History: is used to record the dates of when new versions of the PEP are posted to python-list and/or python-dev. Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001. PEPs may have a Requires: header, indicating the PEP numbers that this PEP depends on. PEPs may also have a Replaced-By: header indicating that a PEP has been rendered obsolete by a later document; the value is the number of the PEP that replaces the current document. The newer PEP must have a Replaces: header containing the number of the PEP that it rendered obsolete. PEP Formatting Requirements PEP headings must begin in column zero and the initial letter of each word must be capitalized as in book titles. Acronyms should be in all capitals. The body of each section must be indented 4 spaces. Code samples inside body sections should be indented a further 4 spaces, and other indentation can be used as required to make the text readable. You must use two blank lines between the last line of a section's body and the next section heading. You must adhere to the Emacs convention of adding two spaces at the end of every sentence. You should fill your paragraphs to column 70, but under no circumstances should your lines extend past column 79. If your code samples spill over column 79, you should rewrite them. Tab characters must never appear in the document at all. A PEP should include the standard Emacs stanza included by example at the bottom of this PEP. A PEP must contain a Copyright section, and it is strongly recommended to put the PEP in the public domain. When referencing an external web page in the body of a PEP, you should include the title of the page in the text, with a footnote reference to the URL. Do not include the URL in the body text of the PEP. E.g. Refer to the Python Language web site [1] for more details. ... [1] http://www.python.org When referring to another PEP, include the PEP number in the body text, such as "PEP 1". The title may optionally appear. Add a footnote reference that includes the PEP's title and author. It may optionally include the explicit URL on a separate line, but only in the References section. Note that the pep2html.py script will calculate URLs automatically, e.g.: ... Refer to PEP 1 [7] for more information about PEP style ... References [7] PEP 1, PEP Purpose and Guidelines, Warsaw, Hylton http://www.python.org/peps/pep-0001.html If you decide to provide an explicit URL for a PEP, please use this as the URL template: http://www.python.org/peps/pep-xxxx.html PEP numbers in URLs must be padded with zeros from the left, so as to be exactly 4 characters wide, however PEP numbers in text are never padded. Reporting PEP Bugs, or Submitting PEP Updates How you report a bug, or submit a PEP update depends on several factors, such as the maturity of the PEP, the preferences of the PEP author, and the nature of your comments. For the early draft stages of the PEP, it's probably best to send your comments and changes directly to the PEP author. For more mature, or finished PEPs you may want to submit corrections to the SourceForge bug manager[6] or better yet, the SourceForge patch manager[2] so that your changes don't get lost. If the PEP author is a SF developer, assign the bug/patch to him, otherwise assign it to the PEP editor. When in doubt about where to send your changes, please check first with the PEP author and/or PEP editor. PEP authors who are also SF committers, can update the PEPs themselves by using "cvs commit" to commit their changes. Remember to also push the formatted PEP text out to the web by doing the following: % python pep2html.py -i NUM where NUM is the number of the PEP you want to push out. See % python pep2html.py --help for details. Transferring PEP Ownership It occasionally becomes necessary to transfer ownership of PEPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred PEP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the PEP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the PEP. We try to build consensus around a PEP, but if that's not possible, you can always submit a competing PEP. If you are interested assuming ownership of a PEP, send a message asking to take over, addressed to both the original author and the PEP editor <peps(a)python.org>. If the original author doesn't respond to email in a timely manner, the PEP editor will make a unilateral decision (it's not like such decisions can be reversed. :). References and Footnotes [1] This historical record is available by the normal CVS commands for retrieving older revisions. For those without direct access to the CVS tree, you can browse the current and past PEP revisions via the SourceForge web site at http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/python/nondist/peps/?cvsroot=… [2] http://sourceforge.net/tracker/?group_id=5470&atid=305470 [3] http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse [4] http://www.opencontent.org/openpub/ [5] The script referred to here is pep2html.py, which lives in the same directory in the CVS tree as the PEPs themselves. Try "pep2html.py --help" for details. The URL for viewing PEPs on the web is http://www.python.org/peps/ [6] http://sourceforge.net/tracker/?group_id=5470&atid=305470 [7] PEP 9, Sample PEP Template http://www.python.org/peps/pep-0009.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End:

8 14

Boundaries between numbers and identifiers
by Serhiy Storchaka April 15, 2021

April 15, 2021

In Python 2.5 `0or[]` was accepted by the Python parser. It became an error in 2.6 because "0o" became recognizing as an incomplete octal number. `1or[]` still is accepted. On other hand, `1if 2else 3` is accepted despites the fact that "2e" can be recognized as an incomplete floating point number. In this case the tokenizer pushes "e" back and returns "2". Shouldn't it do the same with "0o"? It is possible to make `0or[]` be parseable again. Python implementation is able to tokenize this example: $ echo '0or[]' | ./python -m tokenize 1,0-1,1: NUMBER '0' 1,1-1,3: NAME 'or' 1,3-1,4: OP '[' 1,4-1,5: OP ']' 1,5-1,6: NEWLINE '\n' 2,0-2,0: ENDMARKER '' On other hand, all these examples look weird. There is an assymmetry: `1or 2` is a valid syntax, but `1 or2` is not. It is hard to recognize visually the boundary between a number and the following identifier or keyword, especially if numbers can contain letters ("b", "e", "j", "o", "x") and underscores, and identifiers can contain digits. On both sides of the boundary can be letters, digits, and underscores. I propose to change the Python syntax by adding a requirement that there should be a whitespace or delimiter between a numeric literal and the following keyword.

8 10

pathlib.Path: inconsistent symlink_to() and link_to()
by Barney Gale Jan. 22, 2021

Jan. 22, 2021

Hi, Pathlib's symlink_to() and link_to() methods have different argument orders, so: a.symlink_to(b) # Creates a symlink from A to B a.link_to(b) # Creates a hard link from B to A I don't think link_to() was intended to be implemented this way, as the docs say "Create a hard link pointing to a path named target.". It's also inconsistent with everything else in pathlib, most obviously symlink_to(). Bug report here: https://bugs.python.org/issue39291 This /really/ irks me. Apparently it's too late to fix link_to(), so I'd like to suggest we add a new hardlink_to() method that matches the symlink_to() argument order. link_to() then becomes deprecated/undocumented. Any thoughts? Barney

4 5

PEP 622: Structural Pattern Matching -- followup
by Guido van Rossum July 26, 2020

July 26, 2020

Everyone, If you've commented and you're worried you haven't been heard, please add your issue *concisely* to this new thread. Note that the following issues are already open and will be responded to separately; please don't bother commenting on these until we've done so: - Alternative spellings for '|' - Whether to add an 'else' clause (and how to indent it) - A different token for wildcards instead of '_' - What to do about the footgun of 'case foo' vs. 'case .foo' (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a variable binding and '?' for a wildcard.) -- --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-…>

22 35

PEP 387: backwards compatibility policy
by Brett Cannon July 20, 2020

July 20, 2020

Started at a discussion at https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421 to try to finally resolve this PEP and our backwards compatibility policy.

2 2

Recent PEP-8 change
by Ethan Furman July 7, 2020

July 7, 2020

On 06/29/2020 08:13 AM, Keara Berlin wrote: > Hi all, I didn't mean for there to be significant differences between what I posted here versus in the commit message. Sorry for any confusion around that! Thank you for putting them both in one place here - that is helpful. To be clear, the proposed change: > "When writing English, ensure that your comments are clear and easily understandable to other English speakers." And the commit message: > Instead of requiring that comments be written in Strunk & White Standard English, require instead that English-language comments be clear and easily understandable by other English speakers. This accomplishes the same goal without upholding relics of white supremacy. Many native English speakers do not use Standard English as their native dialect, so requiring conformation to Standard English centers whiteness in an inappropriate and unnecessary way, and can alienate and put up barriers for people of color and those whose native dialect of English is not Standard English. This change is a simple way to correct that while maintaining the original intent of the requirement. I find it difficult to express my horror and outrage with this commit message, but let me try: Picture this scene from a movie I watched a long time ago: towards the end of the US Civil War a small band of deserters approach a large home; only one man, his wife, and their baby are home as the man's father and brothers have left to run errands. The leader of the small band approaches the man and asks for water. The man, happily and cheerfully, obliges and draws a bucket of fresh well water for them. When he turns around to give them the bucket of water, the leader runs him through with his saber (stabs him in his guts all the way to the hilt). That's what it felt like: betrayal. Before the PEP-8 amendment thread I thought Strunk & White was some popular culture reference, and as such I had no interest in it. However, given the brouhaha that ensued I did some digging to discover for myself what it was. Here is what I have found: - it has had at least four editions thus far - it has been modernized as times have changed (the 2000 edition removed the advice to use masculine pronouns whenever possible, and warns that some will find unnecessary masculine usage offensive) - its advice is hotly debated amongst linguists (not surprising) and perhaps the most relevant: - White is the last name of the second author. Of course I don't know if Keara or Guido knew any of this, but it certainly feels to me that the commit message is ostracizing an entire family line because they had the misfortune to have the wrong last name. In fact, it seems like Strunk & White is making changes to be inclusive in its advice -- exactly what I would have thought we wanted on our side ("our side" being the diverse and welcoming side). According to whichever dictionary Google uses, white supremacy is: > noun > the belief that white people are superior to those of all other races, especially the black race, and should therefore dominate society. Does Keara, Guido, or anyone, have any such examples from Strunk & White? Finally, what's wrong with having a standard? Communication, especially in written form, is difficult enough without everyone using whatever style/grammar/colloquialisms happen to suit their fancy at the time. As a silly example: when I started using Python having the first parameter of a class method be `self` irked me, so I used `yo` instead (Spanish word for "I") -- it was shorter, and it tickled my fancy. Two years into using Python and I replaced every instance of `yo` in my libraries to `self`; the cognitive dissonance between my code and everyone else's was an unnecessary distraction. Speaking of unnecessary, I think the change to PEP-8 was unnecessary. I think it was pushed through without any consideration for those against it, and I think the commit message was extremely offensive. To hopefully stave off some attacks against me: - I am not white - I am not Ivy League educated - Black lives do matter - Police are terrifying -- ~Ethan~

36 108

Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
by Paul Sokolovsky July 5, 2020

July 5, 2020

Hello, Shouldn't such feedback be also cross-posted to the python-dev mailing list? Also note the original pull request, https://github.com/python/peps/pull/1470, and differences of what was written in the pull request description and what went in the commit message. On Sun, 28 Jun 2020 22:10:14 +0200 "Giampaolo Rodola'" <g.rodola(a)gmail.com> wrote: > From: > https://github.com/python/peps/commit/0c6427dcec1e98ca0bd46a876a7219ee4a934… > > > Instead of requiring that comments be written in Strunk & White > > Standard > English, require instead that English-language comments be clear and > easily understandable by other English speakers. This accomplishes > the same goal without upholding relics of white supremacy. Many > native English speakers do not use Standard English as their native > dialect, so requiring conformation to Standard English centers > whiteness in an inappropriate and unnecessary way, and can alienate > and put up barriers for people of color and those whose native > dialect of English is not Standard English. This change is a simple > way to correct that while maintaining the original intent of the > requirement. > > This has nothing to do with making the wording "clear and > understandable" (I agree on that). It's about, once again, bringing > race-based politics into Python, and spreading hate towards a > specific group of people: whites. Whether you're aware of it or not, > there is a term for this: it's racism. I want to remind everyone that > most of us here simply want to contribute code. We do it for free, > and don't want to be involved in "this", because frankly it's > disgusting. Doing something out of passion and for free, and at the > same time seeing these sorts of things happening on a regular basis, > looks and feels like an insult, and will only lead to people leaving > this place. > > On Fri, Jun 26, 2020 at 11:27 PM Keara Berlin <kearaberlin(a)gmail.com> > wrote: > > > Hi all, this is a very small change, but I thought I would field it > > here to see if anyone has suggestions or ideas. Instead of > > requiring that comments be written in Strunk & White Standard > > English, PEP-8 should require instead that English-language > > comments be clear and easily understandable by other English > > speakers. This accomplishes the same goal without alienating or > > putting up barriers for people (especially people of color) whose > > native dialect of English is not Standard English. This change is a > > simple way to correct that while maintaining the original intent of > > the requirement. This change may even make the requirement more > > clear to people who are not familiar with Strunk & White, since for > > programmers, the main relevant aspect of that standard is "be clear > > and concise;" simply saying that instead of referencing Strunk & > > White may communicate this more effectively. Here is the current > > line in PEP-8: "When writing English, follow Strunk and White." > > I propose changing this line to "When writing English, ensure that > > your comments are clear and easily understandable to other English > > speakers." _______________________________________________ > > Python-ideas mailing list -- python-ideas(a)python.org > > To unsubscribe send an email to python-ideas-leave(a)python.org > > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > > Message archived at > > https://mail.python.org/archives/list/python-ideas@python.org/message/AE2M7… > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > > -- > Giampaolo - gmpy.dev <https://gmpy.dev/about> -- Best regards, Paul mailto:pmiscml@gmail.com

24 50

When can we remove wchar_t* cache from string?
by Inada Naoki July 3, 2020

July 3, 2020

Hi, all. Py_UNICODE has been deprecated since PEP 393 (Flexible string representation). wchar_t* cache in the string object is used only in deprecated APIs. It waste 1 word (8 bytes on 64bit machine) per string instance. The deprecated APIs are documented as "Deprecated since version 3.3, will be removed in version 4.0." See https://docs.python.org/3/c-api/unicode.html#deprecated-py-unicode-apis But when PEP 393 is implemented, no one expects 3.10 will be released. Can we reschedule the removal? My proposal is, schedule the removal on Python 3.11. But we will postpone the removal if we can not remove its usage until it. I grepped the use of the deprecated APIs from top 4000 PyPI packages. result: https://github.com/methane/notes/blob/master/2020/wchar-cache/deprecated-use step: https://github.com/methane/notes/blob/master/2020/wchar-cache/README.md I noticed: * Most of them are generated by Cython. * I reported it to Cython so Cython 0.29.21 will fix them. I expect more than 1 year between Cython 0.29.21 and Python 3.11rc1. * Most of them are `PyUnicode_FromUnicode(NULL, 0);` * We may be able to keep PyUnicode_FromUnicode, but raise error when length>0. Regards, -- Inada Naoki <songofacandy(a)gmail.com>

9 22

Plan to remove Py_UNICODE APis except PEP 623.
by Inada Naoki July 3, 2020

July 3, 2020

Hi, all. I proposed PEP 623 to remove Unicode APIs deprecated by PEP 393. In this thread, I am proposing removal of Py_UNICODE (not Unicode objects) APIs deprecated by PEP 393. Please reply for any comments. ## Undocumented, have Py_DEPRECATED There is no problem to remove them in Python 3.10. I will just do it. * Py_UNICODE_str*** functions -- already removed in https://github.com/python/cpython/pull/21164 * PyUnicode_GetMax() ## Documented and have Py_DEPRECATED * PyLong_FromUnicode * PyUnicode_AsUnicodeCopy * PyUnicode_Encode * PyUnicode_EncodeUTF7 * PyUnicode_EncodeUTF8 * PyUnicode_EncodeUTF16 * PyUnicode_EncodeUTF32 * PyUnicode_EncodeUnicodeEscape * PyUnicode_EncodeRawUnicodeEscape * PyUnicode_EncodeLatin1 * PyUnicode_EncodeASCII * PyUnicode_EncodeCharmap * PyUnicode_TranslateCharmap * PyUnicode_EncodeMBCS These APIs are documented. The document has ``.. deprecated:: 3.3 4.0`` directive. They have been `Py_DEPRECATED` since Python 3.6 too. Plan: Change the document to ``.. deprecated:: 3.0 3.10`` and remove them in Python 3.10. ## PyUnicode_EncodeDecimal It is not documented. It has not been deprecated by Py_DEPRECATED. Plan: Add Py_DEPRECATED in Python 3.9 and remove it in 3.11. ## PyUnicode_TransformDecimalToASCII It is documented, but doesn't have ``deprecated`` directive. It is not deprecated by Py_DEPRECATED. Plan: Add Py_DEPRECATED and ``deprecated 3.3 3.11`` directive in 3.9, and remove it in 3.11. ## _PyUnicode_ToLowercase, _PyUnicode_ToUppercase They are not deprecated by PEP 393, but bpo-12736. They are documented as deprecated, but don't have ``Py_DEPRECATED``. Plan: Add Py_DEPRECATED in 3.9, and remove them in 3.11. Note: _PyUnicode_ToTitlecase has Py_DEPRECATED. It can be removed in 3.10. -- Inada Naoki <songofacandy(a)gmail.com>

10 30

PEP 620: Hide implementation details from the C API
by Victor Stinner July 2, 2020

July 2, 2020

Hi, PEP available at: https://www.python.org/dev/peps/pep-0620/ <introduction> This PEP is the result of 4 years of research work on the C API: https://pythoncapi.readthedocs.io/ It's the third version. The first version (2017) proposed to add a "new C API" and advised C extensions maintainers to opt-in for it: it was basically the same idea as PEP 384 limited C API but in a different color. Well, I had no idea of what I was doing :-) The second version (April 2020) proposed to add a new Python runtime built from the same code base as the regular Python runtime but in a different build mode, the regular Python would continue to be fully compatible. I wrote the third version, the PEP 620, from scratch. It now gives an explicit and concrete list of incompatible C API changes, and has better motivation and rationale sections. The main PEP novelty is the new pythoncapi_compat.h header file distributed with Python to provide new C API functions to old Python versions, the second novelty is the process to reduce the number of broken C extensions. Whereas PEPs are usually implemented in a single Python version, the implementation of this PEP is expected to be done carefully over multiple Python versions. The PEP lists many changes which are already implemented in Python 3.7, 3.8 and 3.9. It defines a process to reduce the number of broken C extensions when introducing the incompatible C API changes listed in the PEP. The process dictates the rhythm of these changes. </introduction> PEP: 620 Title: Hide implementation details from the C API Author: Victor Stinner <vstinner(a)python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 19-June-2020 Python-Version: 3.10 Abstract ======== Introduce C API incompatible changes to hide implementation details. Once most implementation details will be hidden, evolution of CPython internals would be less limited by C API backward compatibility issues. It will be way easier to add new features. It becomes possible to experiment with more advanced optimizations in CPython than just micro-optimizations, like tagged pointers. Define a process to reduce the number of broken C extensions. The implementation of this PEP is expected to be done carefully over multiple Python versions. It already started in Python 3.7 and most changes are already completed. The `Process to reduce the number of broken C extensions`_ dictates the rhythm. Motivation ========== The C API blocks CPython evolutions ----------------------------------- Adding or removing members of C structures is causing multiple backward compatibility issues. Adding a new member breaks the stable ABI (PEP 384), especially for types declared statically (e.g. ``static PyTypeObject MyType = {...};``). In Python 3.4, the PEP 442 "Safe object finalization" added the ``tp_finalize`` member at the end of the ``PyTypeObject`` structure. For ABI backward compatibility, a new ``Py_TPFLAGS_HAVE_FINALIZE`` type flag was required to announce if the type structure contains the ``tp_finalize`` member. The flag was removed in Python 3.8 (`bpo-32388 <https://bugs.python.org/issue32388>`_). The ``PyTypeObject.tp_print`` member, deprecated since Python 3.0 released in 2009, has been removed in the Python 3.8 development cycle. But the change broke too many C extensions and had to be reverted before 3.8 final release. Finally, the member was removed again in Python 3.9. C extensions rely on the ability to access directly structure members, indirectly through the C API, or even directly. Modifying structures like ``PyListObject`` cannot be even considered. The ``PyTypeObject`` structure is the one which evolved the most, simply because there was no other way to evolve CPython than modifying it. In the C API, all Python objects are passed as ``PyObject*``: a pointer to a ``PyObject`` structure. Experimenting tagged pointers in CPython is blocked by the fact that a C extension can technically dereference a ``PyObject*`` pointer and access ``PyObject`` members. Small "objects" can be stored as a tagged pointer with no concrete ``PyObject`` structure. Replacing Python garbage collector with a tracing garbage collector would also need to remove ``PyObject.ob_refcnt`` reference counter, whereas currently ``Py_INCREF()`` and ``Py_DECREF()`` macros access directly to ``PyObject.ob_refcnt``. Same CPython design since 1990: structures and reference counting ----------------------------------------------------------------- When the CPython project was created, it was written with one principle: keep the implementation simple enough so it can be maintained by a single developer. CPython complexity grew a lot and many micro-optimizations have been implemented, but CPython core design has not changed. Members of ``PyObject`` and ``PyTupleObject`` structures have not changed since the "Initial revision" commit (1990):: #define OB_HEAD \ unsigned int ob_refcnt; \ struct _typeobject *ob_type; typedef struct _object { OB_HEAD } object; typedef struct { OB_VARHEAD object *ob_item[1]; } tupleobject; Only names changed: ``object`` was renamed to ``PyObject`` and ``tupleobject`` was renamed to ``PyTupleObject``. CPython still tracks Python objects lifetime using reference counting internally and for third party C extensions (through the Python C API). All Python objects must be allocated on the heap and cannot be moved. Why is PyPy more efficient than CPython? ---------------------------------------- The PyPy project is a Python implementation which is 4.2x faster than CPython on average. PyPy developers chose to not fork CPython, but start from scratch to have more freedom in terms of optimization choices. PyPy does not use reference counting, but a tracing garbage collector which moves objects. Objects can be allocated on the stack (or even not at all), rather than always having to be allocated on the heap. Objects layouts are designed with performance in mind. For example, a list strategy stores integers directly as integers, rather than objects. Moreover, PyPy also has a JIT compiler which emits fast code thanks to the efficient PyPy design. PyPy bottleneck: the Python C API --------------------------------- While PyPy is way more efficient than CPython to run pure Python code, it is as efficient or slower than CPython to run C extensions. Since the C API requires ``PyObject*`` and allows to access directly structure members, PyPy has to associate a CPython object to PyPy objects and maintain both consistent. Converting a PyPy object to a CPython object is inefficient. Moreover, reference counting also has to be implemented on top of PyPy tracing garbage collector. These conversions are required because the Python C API is too close to the CPython implementation: there is no high-level abstraction. For example, structures members are part of the public C API and nothing prevents a C extension to get or set directly ``PyTupleObject.ob_item[0]`` (the first item of a tuple). See `Inside cpyext: Why emulating CPython C API is so Hard <https://morepypy.blogspot.com/2018/09/inside-cpyext-why-emulating-cpython-c…>`_ (Sept 2018) by Antonio Cuni for more details. Rationale ========= Hide implementation details --------------------------- Hiding implementation details from the C API has multiple advantages: * It becomes possible to experiment with more advanced optimizations in CPython than just micro-optimizations. For example, tagged pointers, and replace the garbage collector with a tracing garbage collector which can move objects. * Adding new features in CPython becomes easier. * PyPy should be able to avoid conversions to CPython objects in more cases: keep efficient PyPy objects. * It becomes easier to implement the C API for a new Python implementation. * More C extensions will be compatible with Python implementations other than CPython. Relationship with the limited C API ----------------------------------- The PEP 384 "Defining a Stable ABI" is in Python 3.4. It introduces the "limited C API": a subset of the C API. When the limited C API is used, it becomes possible to build a C extension only once and use it on multiple Python versions: that's the stable ABI. The main limitation of the PEP 384 is that C extensions have to opt-in for the limited C API. Only very few projects made this choice, usually to ease distribution of binaries, especially on Windows. This PEP moves the C API towards the limited C API. Ideally, the C API will become the limited C API and all C extensions will use the stable ABI, but this is out of this PEP scope. Specification ============= Summary ------- * (**Completed**) Reorganize the C API header files: create ``Include/cpython/`` and ``Include/internal/`` subdirectories. * (**Completed**) Move private functions exposing implementation details to the internal C API. * (**Completed**) Convert macros to static inline functions. * (**Completed**) Add new functions ``Py_SET_TYPE()``, ``Py_SET_REFCNT()`` and ``Py_SET_SIZE()``. The ``Py_TYPE()``, ``Py_REFCNT()`` and ``Py_SIZE()`` macros become functions which cannot be used as l-value. * (**Completed**) New C API functions must not return borrowed references. * (**In Progress**) Provide ``pythoncapi_compat.h`` header file. * (**In Progress**) Make structures opaque, add getter and setter functions. * (**Not Started**) Deprecate ``PySequence_Fast_ITEMS()``. * (**Not Started**) Convert ``PyTuple_GET_ITEM()`` and ``PyList_GET_ITEM()`` macros to static inline functions. Reorganize the C API header files --------------------------------- The first consumer of the C API was Python itself. There is no clear separation between APIs which must not be used outside Python, and API which are public on purpose. Header files must be reorganized in 3 API: * ``Include/`` directory is the limited C API: no implementation details, structures are opaque. C extensions using it get a stable ABI. * ``Include/cpython/`` directory is the CPython C API: less "portable" API, depends more on the Python version, expose some implementation details, few incompatible changes can happen. * ``Internal/internal/`` directory is the internal C API: implementation details, incompatible changes are likely at each Python release. The creation of the ``Include/cpython/`` directory is fully backward compatible. ``Include/cpython/`` header files cannot be included directly and are included automatically by ``Include/`` header files when the ``Py_LIMITED_API`` macro is not defined. The internal C API is installed and can be used for specific usage like debuggers and profilers which must access structures members without executing code. C extensions using the internal C API are tightly coupled to a Python version and must be recompiled at each Python version. **STATUS**: Completed (in Python 3.8) The reorganization of header files started in Python 3.7 and was completed in Python 3.8: * `bpo-35134 <https://bugs.python.org/issue35134>`_: Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details. * `bpo-35081 <https://bugs.python.org/issue35081>`_: Move internal headers to ``Include/internal/`` Move private functions to the internal C API -------------------------------------------- Private functions which expose implementation details must be moved to the internal C API. If a C extension relies on a CPython private function which exposes CPython implementation details, other Python implementations have to re-implement this private function to support this C extension. **STATUS**: Completed (in Python 3.9) Private functions moved to the internal C API in Python 3.8: * ``_PyObject_GC_TRACK()``, ``_PyObject_GC_UNTRACK()`` Macros and functions excluded from the limited C API in Python 3.9: * ``_PyObject_SIZE()``, ``_PyObject_VAR_SIZE()`` * ``PyThreadState_DeleteCurrent()`` * ``PyFPE_START_PROTECT()``, ``PyFPE_END_PROTECT()`` * ``_Py_NewReference()``, ``_Py_ForgetReference()`` * ``_PyTraceMalloc_NewReference()`` * ``_Py_GetRefTotal()`` Private functions moved to the internal C API in Python 3.9: * GC functions like ``_Py_AS_GC()``, ``_PyObject_GC_IS_TRACKED()`` and ``_PyGCHead_NEXT()`` * ``_Py_AddToAllObjects()`` (not exported) * ``_PyDebug_PrintTotalRefs()``, ``_Py_PrintReferences()``, ``_Py_PrintReferenceAddresses()`` (not exported) Public "clear free list" functions moved to the internal C API an renamed to private functions and in Python 3.9: * ``PyAsyncGen_ClearFreeLists()`` * ``PyContext_ClearFreeList()`` * ``PyDict_ClearFreeList()`` * ``PyFloat_ClearFreeList()`` * ``PyFrame_ClearFreeList()`` * ``PyList_ClearFreeList()`` * ``PyTuple_ClearFreeList()`` * Functions simply removed: * ``PyMethod_ClearFreeList()`` and ``PyCFunction_ClearFreeList()``: bound method free list removed in Python 3.9. * ``PySet_ClearFreeList()``: set free list removed in Python 3.4. * ``PyUnicode_ClearFreeList()``: Unicode free list removed in Python 3.3. Convert macros to static inline functions ----------------------------------------- Converting macros to static inline functions have multiple advantages: * Functions have well defined parameter types and return type. * Functions can use variables with a well defined scope (the function). * Debugger can be put breakpoints on functions and profilers can display the function name in the call stacks. In most cases, it works even when a static inline function is inlined. * Functions don't have `macros pitfalls <https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html>`_. Converting macros to static inline functions should only impact very few C extensions which use macros in unusual ways. For backward compatibility, functions must continue to accept any type, not only ``PyObject*``, to avoid compiler warnings, since most macros cast their parameters to ``PyObject*``. Python 3.6 requires C compilers to support static inline functions: the PEP 7 requires a subset of C99. **STATUS**: Completed (in Python 3.9) Macros converted to static inline functions in Python 3.8: * ``Py_INCREF()``, ``Py_DECREF()`` * ``Py_XINCREF()``, ``Py_XDECREF()`` * ``PyObject_INIT()``, ``PyObject_INIT_VAR()`` * ``_PyObject_GC_TRACK()``, ``_PyObject_GC_UNTRACK()``, ``_Py_Dealloc()`` Macros converted to regular functions in Python 3.9: * ``Py_EnterRecursiveCall()``, ``Py_LeaveRecursiveCall()`` (added to the limited C API) * ``PyObject_INIT()``, ``PyObject_INIT_VAR()`` * ``PyObject_GET_WEAKREFS_LISTPTR()`` * ``PyObject_CheckBuffer()`` * ``PyIndex_Check()`` * ``PyObject_IS_GC()`` * ``PyObject_NEW()`` (alias to ``PyObject_New()``), ``PyObject_NEW_VAR()`` (alias to ``PyObject_NewVar()``) * ``PyType_HasFeature()`` (always call ``PyType_GetFlags()``) * ``Py_TRASHCAN_BEGIN_CONDITION()`` and ``Py_TRASHCAN_END()`` macros now call functions which hide implementation details, rather than accessing directly members of the ``PyThreadState`` structure. Make structures opaque ---------------------- All structures of the C API should become opaque: C extensions must use getter or setter functions to get or set structure members. For example, ``tuple->ob_item[0]`` must be replaced with ``PyTuple_GET_ITEM(tuple, 0)``. To be able to move away from reference counting, ``PyObject`` must become opaque. Currently, the reference counter ``PyObject.ob_refcnt`` is exposed in the C API. All structures must become opaque, since they "inherit" from PyObject. For, ``PyFloatObject`` inherits from ``PyObject``:: typedef struct { PyObject ob_base; double ob_fval; } PyFloatObject; Making ``PyObject`` fully opaque requires converting ``Py_INCREF()`` and ``Py_DECREF()`` macros to function calls. This change has an impact on performance. It is likely to be one of the very last changes when making structures opaque. Making ``PyTypeObject`` structure opaque breaks C extensions declaring types statically (e.g. ``static PyTypeObject MyType = {...};``). C extensions must use ``PyType_FromSpec()`` to allocate types on the heap instead. Using heap types has other advantages like being compatible with subinterpreters. Combined with PEP 489 "Multi-phase extension module initialization", it makes a C extension behavior closer to a Python module, like allowing to create more than one module instance. Making ``PyThreadState`` structure opaque requires adding getter and setter functions for members used by C extensions. **STATUS**: In Progress (started in Python 3.8) The ``PyInterpreterState`` structure was made opaque in Python 3.8 (`bpo-35886 <https://bugs.python.org/issue35886>`_) and the ``PyGC_Head`` structure (`bpo-40241 <https://bugs.python.org/issue40241>`_) was made opaque in Python 3.9. Issues tracking the work to prepare the C API to make following structures opaque: * ``PyObject``: `bpo-39573 <https://bugs.python.org/issue39573>`_ * ``PyTypeObject``: `bpo-40170 <https://bugs.python.org/issue40170>`_ * ``PyFrameObject``: `bpo-40421 <https://bugs.python.org/issue40421>`_ * Python 3.9 adds ``PyFrame_GetCode()`` and ``PyFrame_GetBack()`` getter functions, and moves ``PyFrame_GetLineNumber`` to the limited C API. * ``PyThreadState``: `bpo-39947 <https://bugs.python.org/issue39947>`_ * Python 3.9 adds 3 getter functions: ``PyThreadState_GetFrame()``, ``PyThreadState_GetID()``, ``PyThreadState_GetInterpreter()``. Disallow using Py_TYPE() as l-value ----------------------------------- The ``Py_TYPE()`` function gets an object type, its ``PyObject.ob_type`` member. It is implemented as a macro which can be used as an l-value to set the type: ``Py_TYPE(obj) = new_type``. This code relies on the assumption that ``PyObject.ob_type`` can be modified directly. It prevents making the ``PyObject`` structure opaque. New setter functions ``Py_SET_TYPE()``, ``Py_SET_REFCNT()`` and ``Py_SET_SIZE()`` are added and must be used instead. The ``Py_TYPE()``, ``Py_REFCNT()`` and ``Py_SIZE()`` macros must be converted to static inline functions which can not be used as l-value. For example, the ``Py_TYPE()`` macro:: #define Py_TYPE(ob) (((PyObject*)(ob))->ob_type) becomes:: #define _PyObject_CAST_CONST(op) ((const PyObject*)(op)) static inline PyTypeObject* _Py_TYPE(const PyObject *ob) { return ob->ob_type; } #define Py_TYPE(ob) _Py_TYPE(_PyObject_CAST_CONST(ob)) **STATUS**: Completed (in Python 3.10) New functions ``Py_SET_TYPE()``, ``Py_SET_REFCNT()`` and ``Py_SET_SIZE()`` were added to Python 3.9. In Python 3.10, ``Py_TYPE()``, ``Py_REFCNT()`` and ``Py_SIZE()`` can no longer be used as l-value and the new setter functions must be used instead. New C API functions must not return borrowed references ------------------------------------------------------- When a function returns a borrowed reference, Python cannot track when the caller stops using this reference. For example, if the Python ``list`` type is specialized for small integers, store directly "raw" numbers rather than Python objects, ``PyList_GetItem()`` has to create a temporary Python object. The problem is to decide when it is safe to delete the temporary object. The general guidelines is to avoid returning borrowed references for new C API functions. No function returning borrowed functions is scheduled for removal by this PEP. **STATUS**: Completed (in Python 3.9) In Python 3.9, new C API functions returning Python objects only return strong references: * ``PyFrame_GetBack()`` * ``PyFrame_GetCode()`` * ``PyObject_CallNoArgs()`` * ``PyObject_CallOneArg()`` * ``PyThreadState_GetFrame()`` Avoid functions returning PyObject** ------------------------------------ The ``PySequence_Fast_ITEMS()`` function gives a direct access to an array of ``PyObject*`` objects. The function is deprecated in favor of ``PyTuple_GetItem()`` and ``PyList_GetItem()``. ``PyTuple_GET_ITEM()`` can be abused to access directly the ``PyTupleObject.ob_item`` member:: PyObject **items = &PyTuple_GET_ITEM(0); The ``PyTuple_GET_ITEM()`` and ``PyList_GET_ITEM()`` macros are converted to static inline functions to disallow that. **STATUS**: Not Started New pythoncapi_compat.h header file ----------------------------------- Making structures opaque requires modifying C extensions to use getter and setter functions. The practical issue is how to keep support for old Python versions which don't have these functions. For example, in Python 3.10, it is no longer possible to use ``Py_TYPE()`` as an l-value. The new ``Py_SET_TYPE()`` function must be used instead:: #if PY_VERSION_HEX >= 0x030900A4 Py_SET_TYPE(&MyType, &PyType_Type); #else Py_TYPE(&MyType) = &PyType_Type; #endif This code may ring a bell to developers who ported their Python code base from Python 2 to Python 3. Python will distribute a new ``pythoncapi_compat.h`` header file which provides new C API functions to old Python versions. Example:: #if PY_VERSION_HEX < 0x030900A4 static inline void _Py_SET_TYPE(PyObject *ob, PyTypeObject *type) { ob->ob_type = type; } #define Py_SET_TYPE(ob, type) _Py_SET_TYPE((PyObject*)(ob), type) #endif // PY_VERSION_HEX < 0x030900A4 Using this header file, ``Py_SET_TYPE()`` can be used on old Python versions as well. Developers can copy this file in their project, or even to only copy/paste the few functions needed by their C extension. **STATUS**: In Progress (implemented but not distributed by CPython yet) The ``pythoncapi_compat.h`` header file is currently developer at: https://github.com/pythoncapi/pythoncapi_compat Process to reduce the number of broken C extensions =================================================== Process to reduce the number of broken C extensions when introducing C API incompatible changes listed in this PEP: * Estimate how many popular C extensions are affected by the incompatible change. * Coordinate with maintainers of broken C extensions to prepare their code for the future incompatible change. * Introduce the incompatible changes in Python. The documentation must explain how to port existing code. It is recommended to merge such changes at the beginning of a development cycle to have more time for tests. * Changes which are the most likely to break a large number of C extensions should be announced on the capi-sig mailing list to notify C extensions maintainers to prepare their project for the next Python. * If the change breaks too many projects, reverting the change should be discussed, taking in account the number of broken packages, their importance in the Python community, and the importance of the change. The coordination usually means reporting issues to the projects, or even proposing changes. It does not require waiting for a new release including fixes for every broken project. Since more and more C extensions are written using Cython, rather directly using the C API, it is important to ensure that Cython is prepared in advance for incompatible changes. It gives more time for C extension maintainers to release a new version with code generated with the updated Cython (for C extensions distributing the code generated by Cython). Future incompatible changes can be announced by deprecating a function in the documentation and by annotating the function with ``Py_DEPRECATED()``. But making a structure opaque and preventing the usage of a macro as l-value cannot be deprecated with ``Py_DEPRECATED()``. The important part is coordination and finding a balance between CPython evolutions and backward compatibility. For example, breaking a random, old, obscure and unmaintained C extension on PyPI is less severe than breaking numpy. If a change is reverted, we move back to the coordination step to better prepare the change. Once more C extensions are ready, the incompatible change can be reconsidered. Version History =============== * Version 3, June 2020: PEP rewritten from scratch. Python now distributes a new ``pythoncapi_compat.h`` header and a process is defined to reduce the number of broken C extensions when introducing C API incompatible changes listed in this PEP. * Version 2, April 2020: `PEP: Modify the C API to hide implementation details <https://mail.python.org/archives/list/python-dev@python.org/thread/HKM774XK…>`_. * Version 1, July 2017: `PEP: Hide implementation details in the C API <https://mail.python.org/archives/list/python-ideas@python.org/thread/6XATDG…>`_ sent to python-ideas Copyright ========= This document has been placed in the public domain. -- Night gathers, and now my watch begins. It shall not end until my death.

13 37

Please refrain from posting on the PEP 8 threads for 24 hours
by Brett Cannon July 1, 2020

July 1, 2020

Regardless of what side you fall on, I think we can agree that emotions are running very high at the moment. Nothing is going to change in at least the next 24 hours, so I am personally asking folks to step back for at least that long and think about: 1. Is what you want to say going to contribute to the discussion? 2. Is it being phrased in a polite, constructive fashion? If after 24 hours of reflection you feel your email still meets these criteria then I would say it's reasonable to send that email.

4 4

PEP 622: Structural Pattern Matching
by Guido van Rossum June 30, 2020

June 30, 2020

I'm happy to present a new PEP for the python-dev community to review. This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin. Many people have thought about extending Python with a form of pattern matching similar to that found in Scala, Rust, F#, Haskell and other languages with a functional flavor. The topic has come up regularly on python-ideas (most recently yesterday :-). I'll mostly let the PEP speak for itself: - Published: https://www.python.org/dev/peps/pep-0622/ (*) - Source: https://github.com/python/peps/blob/master/pep-0622.rst (*) The published version will hopefully be available soon. I want to clarify that the design space for such a match statement is enormous. For many key decisions the authors have clashed, in some cases we have gone back and forth several times, and a few uncomfortable compromises were struck. It is quite possible that some major design decisions will have to be revisited before this PEP can be accepted. Nevertheless, we're happy with the current proposal, and we have provided ample discussion in the PEP under the headings of Rejected Ideas and Deferred Ideas. Please read those before proposing changes! I'd like to end with the contents of the README of the repo where we've worked on the draft, which is shorter and gives a gentler introduction than the PEP itself: # Pattern Matching This repo contains a draft PEP proposing a `match` statement. Origins ------- The work has several origins: - Many statically compiled languages (especially functional ones) have a `match` expression, for example [Scala]( http://www.scala-lang.org/files/archive/spec/2.11/08-pattern-matching.html), [Rust](https://doc.rust-lang.org/reference/expressions/match-expr.html), [F#]( https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/pattern-m… ); - Several extensive discussions on python-ideas, culminating in a summarizing [blog post]( https://tobiaskohn.ch/index.php/2018/09/18/pattern-matching-syntax-in-pytho… ) by Tobias Kohn; - An independently developed [draft PEP]( https://github.com/ilevkivskyi/peps/blob/pattern-matching/pep-9999.rst) by Ivan Levkivskyi. Implementation -------------- A full reference implementation written by Brandt Bucher is available as a [fork]((https://github.com/brandtbucher/cpython/tree/patma)) of the CPython repo. This is readily converted to a [pull request](https://github.com/brandtbucher/cpython/pull/2)). Examples -------- Some [example code]( https://github.com/gvanrossum/patma/tree/master/examples/) is available from this repo. Tutorial -------- A `match` statement takes an expression and compares it to successive patterns given as one or more `case` blocks. This is superficially similar to a `switch` statement in C, Java or JavaScript (an many other languages), but much more powerful. The simplest form compares a target value against one or more literals: ```py def http_error(status): match status: case 400: return "Bad request" case 401: return "Unauthorized" case 403: return "Forbidden" case 404: return "Not found" case 418: return "I'm a teapot" case _: return "Something else" ``` Note the last block: the "variable name" `_` acts as a *wildcard* and never fails to match. You can combine several literals in a single pattern using `|` ("or"): ```py case 401|403|404: return "Not allowed" ``` Patterns can look like unpacking assignments, and can be used to bind variables: ```py # The target is an (x, y) tuple match point: case (0, 0): print("Origin") case (0, y): print(f"Y={y}") case (x, 0): print(f"X={x}") case (x, y): print(f"X={x}, Y={y}") case _: raise ValueError("Not a point") ``` Study that one carefully! The first pattern has two literals, and can be thought of as an extension of the literal pattern shown above. But the next two patterns combine a literal and a variable, and the variable is *extracted* from the target value (`point`). The fourth pattern is a double extraction, which makes it conceptually similar to the unpacking assignment `(x, y) = point`. If you are using classes to structure your data (e.g. data classes) you can use the class name followed by an argument list resembling a constructor, but with the ability to extract variables: ```py from dataclasses import dataclass @dataclass class Point: x: int y: int def whereis(point): match point: case Point(0, 0): print("Origin") case Point(0, y): print(f"Y={y}") case Point(x, 0): print(f"X={x}") case Point(): print("Somewhere else") case _: print("Not a point") ``` We can use keyword parameters too. The following patterns are all equivalent (and all bind the `y` attribute to the `var` variable): ```py Point(1, var) Point(1, y=var) Point(x=1, y=var) Point(y=var, x=1) ``` Patterns can be arbitrarily nested. For example, if we have a short list of points, we could match it like this: ```py match points: case []: print("No points") case [Point(0, 0)]: print("The origin") case [Point(x, y)]: print(f"Single point {x}, {y}") case [Point(0, y1), Point(0, y2)]: print(f"Two on the Y axis at {y1}, {y2}") case _: print("Something else") ``` We can add an `if` clause to a pattern, known as a "guard". If the guard is false, `match` goes on to try the next `case` block. Note that variable extraction happens before the guard is evaluated: ```py match point: case Point(x, y) if x == y: print(f"Y=X at {x}") case Point(x, y): print(f"Not on the diagonal") ``` Several other key features: - Like unpacking assignments, tuple and list patterns have exactly the same meaning and actually match arbitrary sequences. An important exception is that they don't match iterators or strings. (Technically, the target must be an instance of `collections.abc.Sequence`.) - Sequence patterns support wildcards: `[x, y, *rest]` and `(x, y, *rest)` work similar to wildcards in unpacking assignments. The name after `*` may also be `_`, so `(x, y, *_)` matches a sequence of at least two items without binding the remaining items. - Mapping patterns: `{"bandwidth": b, "latency": l}` extracts the `"bandwidth"` and `"latency"` values from a dict. Unlike sequence patterns, extra keys are ignored. A wildcard `**rest` is also supported. (But `**_` would be redundant, so it not allowed.) - Subpatterns may be extracted using the walrus (`:=`) operator: ```py case (Point(x1, y1), p2 := Point(x2, y2)): ... ``` - Patterns may use named constants. These must be dotted names; a single name can be made into a constant value by prefixing it with a dot to prevent it from being interpreted as a variable extraction: ```py RED, GREEN, BLUE = 0, 1, 2 match color: case .RED: print("I see red!") case .GREEN: print("Grass is green") case .BLUE: print("I'm feeling the blues :(") ``` - Classes can customize how they are matched by defining a `__match__()` method. Read the [PEP]( https://github.com/python/peps/blob/master/pep-0622.rst#runtime-specificati…) for details. -- --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-…>

45 154

Lists placed into Emergency Moderation status
by Ernest W. Durbin III June 30, 2020

June 30, 2020

At the request of the list moderators of python-ideas and python-dev, both lists have been placed into emergency moderation mode. All new posts must be approved before landing on the list. When directed by the list moderators, this moderation will be disabled. -Ernest W. Durbin III Director of Infrastructure Python Software Foundation

3 6

[RELEASE] Python 3.8.4rc1 is now ready for testing
by Łukasz Langa June 30, 2020

June 30, 2020

Python 3.8.4rc1 is the release candidate of the fourth maintenance release of Python 3.8. Go get it here: https://www.python.org/downloads/release/python-384rc1/ <https://www.python.org/downloads/release/python-384rc1/> Assuming no critical problems are found prior to 2020-07-13, the scheduled release date for 3.8.4, no code changes are planned between this release candidate and the final release. That being said, please keep in mind that this is a pre-release and as such its main purpose is testing. Maintenance releases for the 3.8 series will continue at regular bi-monthly intervals, with 3.8.5 planned for mid-September 2020. What’s new? The Python 3.8 series is the newest feature release of the Python language, and it contains many new features and optimizations. See the “What’s New in Python 3.8 <https://docs.python.org/3.8/whatsnew/3.8.html>” document for more information about features included in the 3.8 series. This is the first bugfix release that is considerably smaller than the previous three. There’s 20% less changes at 130 commits than the average of previous three releases. Detailed information about all changes made in version 3.8.4 specifically can be found in its change log <https://docs.python.org/release/3.8.4rc1/whatsnew/changelog.html#python-3-8…>. We hope you enjoy Python 3.8! Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>

1 0

Intended invariants for signals in CPython
by Yonatan Zunger June 29, 2020

June 29, 2020

Hi everyone, I'm in the process of writing some code to defer signals during critical regions, which has involved a good deal of reading through the CPython implementation to understand the behaviors. Something I've found is that there appears to be a lot of thoughtfulness about where the signal handlers can be triggered, but this thoughtfulness is largely undocumented. I've put together a working list of behaviors from staring at the code, but what I'd like to figure out is which of these behaviors the devs think of as intended to be invariants, versus which are just accidents of how the code currently works and might change unpredictably. And if there are things which are intended to be genuine invariants, would it be reasonable to document these formally and make them part of the language, not just for inside the CPython codebase? What appears to be true is this: - Signal handlers are only invoked in the main thread (documented with the signal library) - High-level: Signal handlers may be invoked at any instruction boundary. External C libraries *may* invoke them as well, but there are no general guarantees. (Documented with the signal library) - Low-level: Certain functions can be described as "interruptable," and signal handlers may be invoked whenever these functions are called. - Signal handlers are thus partially reentrant: a signal handler may be interrupted by another signal iff it invokes an interruptable function. In particular, the thing whose intentionality I'm not sure about is whether the notion of an interruptable function or instruction is meant to be an actual property of the language and/or of the CPython runtime, or whether it's actually intended that only the "high-level" rule above be true, and that all signal handlers should be considered to be fully reentrant at all times. The comments in sysmodule.c about avoiding triggering PyErr_CheckSignals() suggest that there definitely is some thinking about this within the CPython code itself. The reason it would be useful to document this is so that if I'm trying to write a fairly generic library that handles signals (like the one I'm doing now) I can reason about where I need to be defensive about an instruction being interrupted by yet another signal, and maybe avoid calls to certain functions which are known to be interruptable, much like I would avoid calling malloc() in a C signal handler. In the current implementation, the interruptable functions and instructions are: Big categories: - Any function which calls PyErr_SetFromErrno, *if* errno == EINTR. (Catalogue needs to be made of these -- it's a much smaller set than the set of all calls to PyErr_SetFromErrno) - Basically any open, read, or write method of a raw or buffered file object. - Likewise, any open, read, or write method on a socket. - In any interactive console readline, or in input(). - object.__str__, object.__repr__, and PyObject_Print, and anything that falls back to these. Specific instructions: - - Multiplication, division, or stringification of long integers. More specific functions: - In `multiprocessing.shared_memory`, SharedMemory.__init__, .close, and .unlink. - In `multiprocessing.semaphore`, Semaphore.acquire. (But interestingly, *not* threading.Semaphore.acquire) - In `signal`, pause, signal, sigwaitinfo, sigtimedwait, pthread_kill, and pthread_sigmask. - In `fcntl`, fcntl and ioctl. - In `traceback`, any of the print methods. - In `faulthandler`, dump_traceback - In `select`, all of the methods. (select, epoll, etc) - In `time`, sleep. - In `curses`, whenever you look for key input. - In `tkinter`, during the main loop of a Tcl/Tk app. - During an SSL handshake. -- Yonatan Zunger Distinguished Engineer and Chief Ethics Officer He / Him zunger(a)humu.com 100 View St, Suite 101 Mountain View, CA 94041 Humu.com <https://www.humu.com> · LinkedIn <https://www.linkedin.com/company/humuhq> · Twitter <https://twitter.com/humuinc>

6 13

[RELEASE] mpdecimal-2.5.0
by Stefan Krah June 29, 2020

June 29, 2020

Hi, I've released mpdecimal-2.5.0: http://www.bytereef.org/mpdecimal/index.html 15417edc8e12a57d1d9d75fa7e3f22b158a3b98f44db9d694cfd2acde8dfa0ca mpdecimal-2.5.0.tar.gz Starting with Python 3.9, this version should be used for an external libmpdec. Python versions 3.7 and 3.8 should use the previous version mpdecimal-2.4.2. libmpdec ======== libmpdec will continue to evolve conservatively. For the few changes, see: http://www.bytereef.org/mpdecimal/changelog.html libmpdec++ ========== mpdecimal now includes libmpdec++. libmpdec++ is a complete C++ implementation of the General Decimal Arithmetic Specification. http://www.bytereef.org/mpdecimal/doc/libmpdec++/index.html The library frees users from manual memory management and has an easy API with inline operators similar to the one in Python's decimal module. Like Python's decimal module, libmpdec++ has a thread local context for inline operators and other functions that use the implicit context. Depending on the compiler, the speed penalty for the C++ features compared to libmpdec is 4-10%. The best compiler I found is gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1), closely followed by the latest Intel compiler. Both produce the fastest libmpdec code and have a speed penalty for C++ of 4%. Like libmpdec, libmpdec++ has a large test suite. In addition to the mpdecimal tests, libmpdec++ has been tested by replacing all libmpdec functions in Python's decimal module with libmpdec++ functions. libmpdec++ passes both the Python test suite and deccheck.py. For a short libmpdec++ introduction, see: http://www.bytereef.org/mpdecimal/quickstart.html Stefan Krah

1 0

Re: PEP 622: Structural Pattern Matching
by Eric Nieuwland June 28, 2020

June 28, 2020

Guido van Rossum wrote: > Eric Nieuwland wrote: > >> I have some doubt about the keyword: ‘match' seems to be at odds with >> 'for', 'while', 'with', 'if' as it is more of an action. >> It's more like 'try' but that statement has a completely different >> structure. > > Well, 'try' is also an action. :-) Many people have tried to come up with a > different keyword here, but nothing has been found that comes even close to > the simplicity of match. Plus, several other languages (Scala, Rust) use it > too (which is further evidence that it's a natural fit). It may also be evidence for not being able to come up with a more accurate keyword. Reading through the PEP once more I noticed I was understanding match X: case Y: Z as when X: matches Y: Z which also to me seems to reflect the close relation to an if-elif-elif… construction. This would almost naturally imply the possibility of: when X: matches Y: Z ... else: Q And maybe also an additional operator: if X matches Y: Z >> Not a native speaker I don't have a reasonable alternative, though. > > Me neither, but I speak it quite fluently now, and 'match' really feels > like it fits well here. Trying ;-)

2 2

The Anti-PEP
by Mark Shannon June 28, 2020

June 28, 2020

Hi, I'd like to propose the "Anti-PEP". As I'm sure you've all noticed, contentious PEPs like 572, and now 622, generate a lot of email discussion. It's easy to feel that people's opinions are being dismissed and that legitimate criticisms aren't being heard. Conversely, PEP authors may feel they are being bombarded with criticism, which can be overwhelming. The acceptance, or rejection, of a PEP should be a cool technical decision. Whilst there may be considerations of aesthetics and usability that make it difficult to objective, the goal should be to choose what is best for the language in the long term. When deciding on PEP 484, I had to decide between a formally written PEP on one hand, and a mass of emails and informal polls I had done at conferences, on the other. I hope I made the right decision. Whether the ultimate decision is made by the steering committee or by a PEP delegate, it is hard to make a decision between the pros and cons, when the pros are in a single formal document and the cons are scattered across the internet. An Anti-PEP is a way to ensure that those opposed to a PEP can be heard and, if possible, have a coherent voice. Hopefully, it would also make things a lot less stressful for PEP authors. The Anti-PEP ------------ The Anti-PEP is a single document that describes why a particular PEP should be rejected. An Anti-PEP is not a counter PEP. A counter PEP suggests an alternative solution to the same problem and will often share the same motivation as the original PEP. An Anti-PEP would usually reject the motivation or rationale, either as insufficient or as incorrect. An example of a counter PEP is 576, which was a counter to 575. The motivation was the same, but means proposed was quite different. As a result of the ensuing to and fro, we ended up with PEP 590, which was a clear improvement. I don't have an example of an Anti-PEP. We could start with PEP 611, https://www.python.org/dev/peps/pep-0611/. There were many criticisms of it on this mailing list, and I can promise the PEP author won't be upset by an Anti-PEP :) Anyone care to volunteer? Cheers, Mark.

12 12

[RELEASE] Python 3.7.8 and 3.6.11 now available - last 3.7.x bugfix release
by Ned Deily June 28, 2020

June 28, 2020

https://discuss.python.org/t/python-3-7-8-and-3-6-11-now-available-last-3-7… -- Ned Deily nad(a)python.org -- []

1 0

(PEP 620) C API for efficient loop iterating on a sequence of PyObject** or other C types
by Victor Stinner June 28, 2020

June 28, 2020

Le mar. 23 juin 2020 à 03:47, Neil Schemenauer <nas-python(a)arctrix.com> a écrit : > One final comment: I think even if we manage to cleanup the API and > make it friendly for other Python implementations, there is going to > be a fair amount of overhead. If you look at other "managed > runtimes" that just seems unavoidable (e.g. Java, CLR, V8, etc). > You want to design the API so that you maximize the amount of useful > work done with each API call. Using something like > PyList_GET_ITEM() to iterate over a list is not a good pattern. So > keep in mind that an extension API is going to have some overhead. A large part of the PEP 620 is already implemented: https://www.python.org/dev/peps/pep-0620/#summary So far, I didn't notice any major performance issue, but you're right that the PEP itself can only make performance as good or worse, but not better. The PEP only prevents to specialize code in third party code, CPython continues to have full access to all internals like structures. CPython internals already use specialized code. For example, _PyTuple_ITEMS() gives access to PyObject** which is denied for 3rd party code in the PEP. The question is for extensions like numpy which do rely on internals to emit faster code. -- In HPy, the question was asked as well. If I recall correctly, instead of making assumptions about object layouts depending on its type, new protocols should be added to query access to an object in a specific way. For example, we can consider continuing to provide raw access to a PyObject** array, but an object can reply "sorry, I don't support this PyObject** protocol". Also, I expect to have a function call to notify the object when the PyObject** view is not longer needed. Something like Py_buffer protocol PyBuffer_Release(). Maybe an object can generate a temporary PyObject** view which requires to allocate resources (like memory) and the release function would release these resources. Pseudo-code: void iterate(PyObject *obj) { PyObjectPP_View view; if (PyObjectPP_View_Get(&view, obj)) { // fast-path: the object provides a PyObject** view for (Py_ssize_t i=0; i < view.len; i++ { PyObject *item = view.array[i]; ... } PyObjectPP_View_Release(&view); } else { // slow code path using PySequence_GetItem() or anything else ... } Maybe PyObjectPP_View_Get() should increment the object reference counter to ensure that the object cannot be destroyed in the loop (if the loop calls arbitrary Python code), and PyObjectPP_View_Release() would decrement its reference counter. "PyObjectPP_View" protocol looks like PySequence_Fast() API, but IMO PySequence_Fast() is not generic enough. For example, the first issue is that it cannot reply "no, sorry, the object doesn't support PyObject**". It always creates a temporary list if the object is not a tuple or a list, that may be inefficient for a large sequence. Also, the "view" protocol should be allowed to query other types than just PyObject**. For example, what if I would like to iterate on a sequence of integers? bytes, array.array and memoryview can be seen as sequences of integers. See also HPy notes on these ideas: https://github.com/pyhandle/hpy/blob/master/docs/xxx-unsorted-notes.txt Victor -- Night gathers, and now my watch begins. It shall not end until my death.

5 4

Summary of Python tracker Issues
by Python tracker June 26, 2020

June 26, 2020

ACTIVITY SUMMARY (2020-06-19 - 2020-06-26) 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 7490 (+14) closed 45380 (+75) total 52870 (+89) Open issues with patches: 3035 Issues opened (62) ================== #15849: PEP 3121, 384 Refactoring applied to xx module https://bugs.python.org/issue15849 reopened by vstinner #35975: Put back the ability to parse files where async/await aren't k https://bugs.python.org/issue35975 reopened by gvanrossum #41041: Multiprocesing Pool borken on macOS REPL https://bugs.python.org/issue41041 opened by mbussonn #41043: Escape the literal part of the path for glob() https://bugs.python.org/issue41043 opened by serhiy.storchaka #41045: f-string's "debug" feature is undocumented https://bugs.python.org/issue41045 opened by eric.smith #41046: unittest: make skipTest a classmethod https://bugs.python.org/issue41046 opened by jameshcorbett #41048: read_mime_types() should read the rule file using UTF-8, not t https://bugs.python.org/issue41048 opened by serhiy.storchaka #41050: class multiprocessing.Value calls set_start_method https://bugs.python.org/issue41050 opened by Kernel Plevitsky #41051: Flush file after warning is written https://bugs.python.org/issue41051 opened by mjacob #41052: Opt out serialization/deserialization for heap type https://bugs.python.org/issue41052 opened by corona10 #41053: open() fails to read app exec links https://bugs.python.org/issue41053 opened by saschanaz #41056: minor NULL pointer and sign issues reported by Coverity https://bugs.python.org/issue41056 opened by gregory.p.smith #41059: Large number of Coverity reports for parser.c https://bugs.python.org/issue41059 opened by gregory.p.smith #41061: Incorrect expressions / assert with side effect in hashtable https://bugs.python.org/issue41061 opened by christian.heimes #41062: Advanced Debugger Support C-API is useless without HEAD_LOCK() https://bugs.python.org/issue41062 opened by pashkin #41063: Avoid using the locale encoding for open() in tests https://bugs.python.org/issue41063 opened by serhiy.storchaka #41064: f-string SyntaxError gives offset within fake line, other issu https://bugs.python.org/issue41064 opened by JNCressey #41065: Use zip-strict in zoneinfo https://bugs.python.org/issue41065 opened by cool-RR #41066: Update documentation for Pathlib https://bugs.python.org/issue41066 opened by thatiparthy #41067: Haiku build fix - posix module https://bugs.python.org/issue41067 opened by devnexen #41073: [C API] PyType_GetSlot() should accept static types https://bugs.python.org/issue41073 opened by vstinner #41075: Make support of navigating through prev. commands in IDLE more https://bugs.python.org/issue41075 opened by wyz23x2 #41076: Pre-feed the parser with the f-string expression location https://bugs.python.org/issue41076 opened by lys.nikolaou #41078: [C API] Convert PyTuple_GET_ITEM() macro to a static inline fu https://bugs.python.org/issue41078 opened by vstinner #41079: _PyAsyncGenWrappedValue_Type is never Readied https://bugs.python.org/issue41079 opened by Tomasz Pytel #41081: Exclude __pycache__ directories from backups using CACHEDIR.TA https://bugs.python.org/issue41081 opened by jstasiak #41082: Error handling and documentation of Path.home() https://bugs.python.org/issue41082 opened by timhoffm #41083: plistlib can't decode date from year 0 https://bugs.python.org/issue41083 opened by shields-fn #41084: Signify that a SyntaxError comes from an fstring in the error https://bugs.python.org/issue41084 opened by lys.nikolaou #41086: Exception for uninstantiated interpolation (configparser) https://bugs.python.org/issue41086 opened by scrummyin #41088: Extend the AST Validator to validate all identifiers https://bugs.python.org/issue41088 opened by BTaskaya #41090: Support for "Universal 2" binary builds https://bugs.python.org/issue41090 opened by ronaldoussoren #41091: Remove recommendation in curses module documentation to initia https://bugs.python.org/issue41091 opened by mjacob #41092: Report actual size from 'os.path.getsize' https://bugs.python.org/issue41092 opened by stephenfin #41093: TCPServer's server_forever() shutdown immediately when calling https://bugs.python.org/issue41093 opened by tontinton #41095: inspect.signature() doesn't parse __text_signature__ containin https://bugs.python.org/issue41095 opened by vstinner #41096: Need command to exit PDB interactive shell https://bugs.python.org/issue41096 opened by Kerrick Staley #41097: confusing BufferError: Existing exports of data: object cannot https://bugs.python.org/issue41097 opened by arigo #41098: Deprecating PyUnicodeEncodeError_Create https://bugs.python.org/issue41098 opened by inada.naoki #41099: Deprecating PyUnicodeTranslateError_Create https://bugs.python.org/issue41099 opened by inada.naoki #41100: Build failure on macOS 11 (beta) https://bugs.python.org/issue41100 opened by ronaldoussoren #41101: Support "arm64" in Mac/Tools/pythonw https://bugs.python.org/issue41101 opened by ronaldoussoren #41102: ZipFile.namelist() does not match the actual files in .zip fil https://bugs.python.org/issue41102 opened by longavailable #41104: IMAPlib debug errors https://bugs.python.org/issue41104 opened by skorpeo #41105: Add some extra content check in configure process for some em https://bugs.python.org/issue41105 opened by Manjusaka #41106: os.scandir() Windows bug dir_entry.stat() not works on file du https://bugs.python.org/issue41106 opened by Cezary.Wagner #41107: Running a generator in a map-like manner https://bugs.python.org/issue41107 opened by natsuwumi #41108: IN module removed in python 3.x; socket doesn't fill in the ga https://bugs.python.org/issue41108 opened by ngie #41109: subclasses of pathlib.PurePosixPath never call __init__ or __n https://bugs.python.org/issue41109 opened by Étienne Pot #41110: 2to3 reports some files as both not changing and having been m https://bugs.python.org/issue41110 opened by AWhetter #41111: Convert a few stdlib extensions to the limited C API https://bugs.python.org/issue41111 opened by vstinner #41114: "TypeError: unhashable type" could often be more clear https://bugs.python.org/issue41114 opened by sfreilich #41115: Codecs should raise precise UnicodeDecodeError or UnicodeEncod https://bugs.python.org/issue41115 opened by pitrou #41116: build on macOS 11 (beta) does not find system-supplied third-p https://bugs.python.org/issue41116 opened by ned.deily #41117: [easy C] GC: Use local variable 'op' when invoking 'traverse' https://bugs.python.org/issue41117 opened by WildCard65 #41119: Wrong error message for list/tuple followed by a colon https://bugs.python.org/issue41119 opened by lys.nikolaou #41122: functools.singledispatchfunction has confusing error message i https://bugs.python.org/issue41122 opened by markgrandi #41123: Remove Py_UNICODE APIs except PEP 623 https://bugs.python.org/issue41123 opened by inada.naoki #41125: Display exit-codes for abruptly terminated processes in concur https://bugs.python.org/issue41125 opened by Epic_Wink #41126: Running test suite gives me - python.exe(14198,0x114352dc0) ma https://bugs.python.org/issue41126 opened by thatiparthy #41127: Executing code in thread or process pools: run_in_executor exa https://bugs.python.org/issue41127 opened by aaraney #41128: Signal handlers should not hang during blocked main thread https://bugs.python.org/issue41128 opened by Josef Havránek Most recent 15 issues with no replies (15) ========================================== #41128: Signal handlers should not hang during blocked main thread https://bugs.python.org/issue41128 #41127: Executing code in thread or process pools: run_in_executor exa https://bugs.python.org/issue41127 #41125: Display exit-codes for abruptly terminated processes in concur https://bugs.python.org/issue41125 #41123: Remove Py_UNICODE APIs except PEP 623 https://bugs.python.org/issue41123 #41122: functools.singledispatchfunction has confusing error message i https://bugs.python.org/issue41122 #41117: [easy C] GC: Use local variable 'op' when invoking 'traverse' https://bugs.python.org/issue41117 #41114: "TypeError: unhashable type" could often be more clear https://bugs.python.org/issue41114 #41110: 2to3 reports some files as both not changing and having been m https://bugs.python.org/issue41110 #41108: IN module removed in python 3.x; socket doesn't fill in the ga https://bugs.python.org/issue41108 #41104: IMAPlib debug errors https://bugs.python.org/issue41104 #41102: ZipFile.namelist() does not match the actual files in .zip fil https://bugs.python.org/issue41102 #41101: Support "arm64" in Mac/Tools/pythonw https://bugs.python.org/issue41101 #41091: Remove recommendation in curses module documentation to initia https://bugs.python.org/issue41091 #41088: Extend the AST Validator to validate all identifiers https://bugs.python.org/issue41088 #41086: Exception for uninstantiated interpolation (configparser) https://bugs.python.org/issue41086 Most recent 15 issues waiting for review (15) ============================================= #41125: Display exit-codes for abruptly terminated processes in concur https://bugs.python.org/issue41125 #41123: Remove Py_UNICODE APIs except PEP 623 https://bugs.python.org/issue41123 #41119: Wrong error message for list/tuple followed by a colon https://bugs.python.org/issue41119 #41117: [easy C] GC: Use local variable 'op' when invoking 'traverse' https://bugs.python.org/issue41117 #41115: Codecs should raise precise UnicodeDecodeError or UnicodeEncod https://bugs.python.org/issue41115 #41101: Support "arm64" in Mac/Tools/pythonw https://bugs.python.org/issue41101 #41100: Build failure on macOS 11 (beta) https://bugs.python.org/issue41100 #41098: Deprecating PyUnicodeEncodeError_Create https://bugs.python.org/issue41098 #41095: inspect.signature() doesn't parse __text_signature__ containin https://bugs.python.org/issue41095 #41093: TCPServer's server_forever() shutdown immediately when calling https://bugs.python.org/issue41093 #41092: Report actual size from 'os.path.getsize' https://bugs.python.org/issue41092 #41091: Remove recommendation in curses module documentation to initia https://bugs.python.org/issue41091 #41090: Support for "Universal 2" binary builds https://bugs.python.org/issue41090 #41088: Extend the AST Validator to validate all identifiers https://bugs.python.org/issue41088 #41086: Exception for uninstantiated interpolation (configparser) https://bugs.python.org/issue41086 Top 10 most discussed issues (10) ================================= #40521: [subinterpreters] Make free lists and unicode caches per-inter https://bugs.python.org/issue40521 14 msgs #41106: os.scandir() Windows bug dir_entry.stat() not works on file du https://bugs.python.org/issue41106 14 msgs #41056: minor NULL pointer and sign issues reported by Coverity https://bugs.python.org/issue41056 11 msgs #41078: [C API] Convert PyTuple_GET_ITEM() macro to a static inline fu https://bugs.python.org/issue41078 11 msgs #41111: Convert a few stdlib extensions to the limited C API https://bugs.python.org/issue41111 11 msgs #40939: Remove the old parser https://bugs.python.org/issue40939 10 msgs #35975: Put back the ability to parse files where async/await aren't k https://bugs.python.org/issue35975 8 msgs #40204: Docs build error with Sphinx 3.0 due to invalid C declaration https://bugs.python.org/issue40204 7 msgs #41005: Permission denied: 'xdg-settings' when executing 'jupyter note https://bugs.python.org/issue41005 7 msgs #39960: Using typename.__setattr__ in extension type with Py_TPFLAGS_H https://bugs.python.org/issue39960 6 msgs Issues closed (72) ================== #6467: PyOS_Readline: treatment of "1234EOF"; behavior of builtin_raw https://bugs.python.org/issue6467 closed by vstinner #8212: A tp_dealloc of a subclassed class cannot resurrect an object https://bugs.python.org/issue8212 closed by vstinner #12861: PyOS_Readline uses single lock https://bugs.python.org/issue12861 closed by vstinner #15652: PEP 3121, 384 refactoring applied to gdbm module https://bugs.python.org/issue15652 closed by vstinner #15654: PEP 384 Refactoring applied to bz2 module https://bugs.python.org/issue15654 closed by vstinner #15655: PEP 384 Refactoring applied to json module https://bugs.python.org/issue15655 closed by vstinner #15666: PEP 3121, 384 refactoring applied to lzma module https://bugs.python.org/issue15666 closed by corona10 #15685: PEP 3121, 384 Refactoring applied to itertools module https://bugs.python.org/issue15685 closed by vstinner #15687: PEP 3121, 384 Refactoring applied to mmap module https://bugs.python.org/issue15687 closed by vstinner #15688: PEP 3121 Refactoring applied to nis module https://bugs.python.org/issue15688 closed by vstinner #15689: PEP 3121, 384 Refactoring applied to operator module https://bugs.python.org/issue15689 closed by vstinner #15690: PEP 3121, 384 Refactoring applied to parser module https://bugs.python.org/issue15690 closed by vstinner #15691: PEP 3121, 384 Refactoring applied to posix module https://bugs.python.org/issue15691 closed by vstinner #15700: PEP 3121, 384 Refactoring applied to resource module https://bugs.python.org/issue15700 closed by vstinner #15703: PEP 3121, 384 Refactoring applied to select module https://bugs.python.org/issue15703 closed by vstinner #15711: PEP 3121, 384 Refactoring applied to time module https://bugs.python.org/issue15711 closed by vstinner #18670: Using read_mime_types function from mimetypes module gives res https://bugs.python.org/issue18670 closed by serhiy.storchaka #25257: In subject line email library inserts unwanted space after a t https://bugs.python.org/issue25257 closed by SilentGhost #26774: Elide Py_atomic fences when WITH_THREAD is disabled? https://bugs.python.org/issue26774 closed by vstinner #30852: _PyObject_GC_UNTRACK corruption when call a lambda function wi https://bugs.python.org/issue30852 closed by vstinner #31282: C APIs called without GIL in PyOS_Readline https://bugs.python.org/issue31282 closed by vstinner #33738: PyIndex_Check conflicts with PEP 384 https://bugs.python.org/issue33738 closed by vstinner #35773: test_bdb fails on non-UTF-8 locale https://bugs.python.org/issue35773 closed by serhiy.storchaka #35949: Move PyThreadState into Include/internal/pycore_pystate.h https://bugs.python.org/issue35949 closed by vstinner #38073: Make pwd module PEP-384 compatible https://bugs.python.org/issue38073 closed by vstinner #38116: Make select module PEP-384 compatible https://bugs.python.org/issue38116 closed by vstinner #38377: test_asyncio.test_events.GetEventLoopTestsMixin.test_get_event https://bugs.python.org/issue38377 closed by vstinner #39503: [security][CVE-2020-8492] Denial of service in urllib.request. https://bugs.python.org/issue39503 closed by larry #39580: Check for COMMAND_LINE_INSTALL variable in Python_Documentatio https://bugs.python.org/issue39580 closed by ned.deily #39891: [difflib] Improve get_close_matches() to better match when cas https://bugs.python.org/issue39891 closed by rhettinger #40400: Mac build-installer.py doesn't support new plist format https://bugs.python.org/issue40400 closed by ned.deily #40636: Provide a strict form of zip (PEP-618) requiring same length i https://bugs.python.org/issue40636 closed by brandtbucher #40704: PyIter_Check fails when compiling in the Limited API https://bugs.python.org/issue40704 closed by scoder #40707: Popen.communicate documentation does not say how to get the re https://bugs.python.org/issue40707 closed by terry.reedy #40773: DOC: Fix rendering for 'retval' on the pdb page https://bugs.python.org/issue40773 closed by eric.araujo #40824: Unexpected errors in __iter__ are masked in "in" and the opera https://bugs.python.org/issue40824 closed by serhiy.storchaka #40965: Segfault when importing unittest module via C API https://bugs.python.org/issue40965 closed by vstinner #40986: Async generators are not garbage collected https://bugs.python.org/issue40986 closed by vytas #41002: HTTPResponse.read with amt is slow https://bugs.python.org/issue41002 closed by inada.naoki #41009: @support.requires_*_version broken for classes https://bugs.python.org/issue41009 closed by ned.deily #41035: zipfile.Path does not work properly with zip archives where pa https://bugs.python.org/issue41035 closed by jaraco #41038: VersionInfo string is corrupted when building on Windows with https://bugs.python.org/issue41038 closed by steve.dower #41039: Simplify python3.dll build https://bugs.python.org/issue41039 closed by steve.dower #41040: Fix test_modulefinder https://bugs.python.org/issue41040 closed by serhiy.storchaka #41042: import searches for package even after file was found successf https://bugs.python.org/issue41042 closed by eric.smith #41044: Pegen: double trailing comma on optional+sequence rules at pyt https://bugs.python.org/issue41044 closed by pablogsal #41047: argparse: misbehavior when combining positionals and choices https://bugs.python.org/issue41047 closed by paul.j3 #41049: Document pointer comparison in PyObject_RichCompareBool() https://bugs.python.org/issue41049 closed by rhettinger #41054: Simplify resource compilation on Windows https://bugs.python.org/issue41054 closed by steve.dower #41055: Remove outdated tests for tp_print https://bugs.python.org/issue41055 closed by serhiy.storchaka #41057: Division error https://bugs.python.org/issue41057 closed by mark.dickinson #41058: pdb reads source files using the locale encoding https://bugs.python.org/issue41058 closed by gregory.p.smith #41060: `with a as b` segfault in new peg parser https://bugs.python.org/issue41060 closed by lys.nikolaou #41068: zipfile: read after write fails for non-ascii files https://bugs.python.org/issue41068 closed by serhiy.storchaka #41069: Use non-ascii file names in tests by default https://bugs.python.org/issue41069 closed by serhiy.storchaka #41070: Simplify pyshellext.dll build https://bugs.python.org/issue41070 closed by steve.dower #41071: from an int to a float , why https://bugs.python.org/issue41071 closed by serhiy.storchaka #41072: Python 3.8.3 passively introduced open source software contain https://bugs.python.org/issue41072 closed by serhiy.storchaka #41074: msilib does not work correctly with non-ASCII names https://bugs.python.org/issue41074 closed by serhiy.storchaka #41077: Make Cookiejar a bit more pythonic https://bugs.python.org/issue41077 closed by thatiparthy #41080: re.sub treats * incorrectly? https://bugs.python.org/issue41080 closed by ezio.melotti #41085: [easy C] array.array.index() method downcasts Py_ssize_t to lo https://bugs.python.org/issue41085 closed by WildCard65 #41087: Argparse int / float default https://bugs.python.org/issue41087 closed by serhiy.storchaka #41089: Filters and other issues in Visual Studio projects https://bugs.python.org/issue41089 closed by steve.dower #41094: Audit does not work with non-ASCII data on non-UTF-8 locale https://bugs.python.org/issue41094 closed by serhiy.storchaka #41103: Removing old buffer support https://bugs.python.org/issue41103 closed by inada.naoki #41112: test_peg_generator fails on non-UTF-8 locale https://bugs.python.org/issue41112 closed by serhiy.storchaka #41113: test_warnings fails on non-Western locales https://bugs.python.org/issue41113 closed by serhiy.storchaka #41118: datetime object does not preserve POSIX timestamp https://bugs.python.org/issue41118 closed by p-ganssle #41120: Possible performance improvement for itertools.product example https://bugs.python.org/issue41120 closed by rhettinger #41121: Path sep. in IDLE on Windows changes https://bugs.python.org/issue41121 closed by terry.reedy #41124: String with encode causing addition of 'b' in the beginning https://bugs.python.org/issue41124 closed by SilentGhost

1 0

Re: The Anti-PEP
by Raymond Hettinger June 26, 2020

June 26, 2020

> it is hard to make a decision between the pros and cons, > when the pros are in a single formal document and the > cons are scattered across the internet. Mark, I support your idea. It is natural for PEP authors to not fully articulate the voices of opposition or counter-proposals. The current process doesn't make it likely that a balanced document is created for decision making purposes. Raymond

5 4

Re: PEP 622: Structural Pattern Matching
by Misha Drachuk June 26, 2020

June 26, 2020

I really dislike the fact that case with is instance check looks like instantiation. case Node(children=[…]) Along with checks for int or enum cases, "is instance” and attribute checks like the one above will be perceived as equality check. Basically what happens is based on context the round brackets () next to the class name mean different things, which will confuse people a lot. If instead the curly brackets {}were used for "match checks” the code would be more explicit about not being an equality check: case Node{children=[…]}

3 3

Re: PEP 622: Structural Pattern Matching
by Anders Munch June 25, 2020

June 25, 2020

Eric Nieuwland <eric.nieuwland(a)gmail.com>: >> I have some doubt about the keyword Guido van Rossum [mailto:guido@python.org]: > Many people have tried to come up with a different keyword here, but nothing > has been found that comes even close to the simplicity of match. Plus, several > other languages (Scala, Rust) use it too (which is further evidence that it's > a natural fit). I was thinking that 'match' and 'case' are reversed: The top line presents the _case_ to be studied. The patterns that follow try to _match_ the presented case. Trying it out on PEP example: case input: match x if x > MAX_INT: print("Got a large number") I think it reads well, in particular when like here there's a condition attached. The second line is almost English: "match x if x greater than max int". Pascal is a precedent for this placement of 'case', although of course Niklaus Wirth is not a native English speaker either. regards, Anders

6 5

Re: PEP 622: Structural Pattern Matching -- followup
by Russell Davis June 25, 2020

June 25, 2020

> '?foo' or 'foo?' to mark a variable binding I like that idea a lot, with a strong inclination for the '?foo' variant. Seeing the '?' first makes it clear right away that it's a special context. And it keeps it more distinct from the None-aware operators (from PEP 505, in case that gets adopted).

1 0

Re: PEP 622: Structural Pattern Matching
by Eric Nieuwland June 24, 2020

June 24, 2020

Great PEP! I have some doubt about the keyword: ‘match’ seems to be at odds with ‘for’, ‘while’, ‘with’, ‘if’ as it is more of an action. It’s more like ‘try’ but that statement has a completely different structure. Not a native speaker I don’t have a reasonable alternative, though.

5 5

Draft PEP: Remove wstr from Unicode
by Inada Naoki June 24, 2020

June 24, 2020

PEP: 9999 Title: Remove wstr from Unicode Author: Inada Naoki <songofacandy(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 18-Jun-2020 Python-Version: TBD Abstract ======== PEP 393 deprecated some unicode APIs, and introduced ``wchar_t *wstr``, and ``Py_ssize_t wstr_length`` in unicode implementation for backward compatibility of these deprecated APIs. [1]_ This PEP is planning removal of ``wstr``, and ``wstr_length`` with deprecated APIs using these members. Motivation ========== Memory usage ------------ ``str`` is one of the most used types in Python. Even most simple ASCII strings have a ``wstr`` member. It consumes 8 bytes on 64bit systems. Runtime overhead ---------------- To support legacy Unicode object created by ``PyUnicode_FromUnicode(NULL, length)``, many Unicode APIs has ``PyUnicode_READY()`` check. When we drop support of legacy unicode object, We can reduce this overhead too. Simplicity ---------- Support of legacy Unicode object makes Unicode implementation complex. Until we drop legacy Unicode object, it is very hard to try other Unicode implementation like UTF-8 based implementation in PyPy. Specification ============= Affected APIs -------------- From the Unicode implementation, ``wstr`` and ``wstr_length`` members are removed. Macros and functions to be removed: * PyUnicode_GET_SIZE * PyUnicode_GET_DATA_SIZE * Py_UNICODE_WSTR_LENGTH * PyUnicode_AS_UNICODE * PyUnicode_AS_DATA * PyUnicode_AsUnicode * PyUnicode_AsUnicodeAndSize Behaviors to be removed: * PyUnicode_FromUnicode -- ``PyUnicode_FromUnicode(NULL, size)`` where ``size > 0`` cause RuntimeError instead of creating legacy Unicode object. While this API is deprecated by PEP 393, this API will be kept when ``wstr`` is removed. This API will be removed later. * PyUnicode_FromStringAndSize -- Like PyUnicode_FromUnicode, ``PyUnicode_FromStringAndSize(NULL, size)`` cause RuntimeError instead of creating legacy unicode object. * PyArg_ParseTuple, PyArg_ParseTupleAndKeywords -- 'u', 'u#', 'Z', and 'Z#' format will be removed. Deprecation ----------- All APIs to be removed should have compiler deprecation warning (e.g. `Py_DEPRECATED(3.3)`) from Python 3.9. [2]_ All APIs to be changed should raise DeprecationWarning for behavior to be removed. Note that ``PyUnicode_FromUnicode`` has both of compiler deprecation warning and runtime DeprecationWarning. [3]_, [4]_. Plan ----- All deprecations will be implemented in Python 3.10. Some deprecations will be backported in Python 3.9. Actual removal will happen in Python 3.12. Alternative Ideas ================= Advanced Schedule ----------------- Backport warnings in 3.9, and do the removal in early development phase in Python 3.11. If many third packages are broken by this change, we will revert the change and back to the regular schedule. Pros: There is a chance to remove ``wstr`` in Python 3.11. Even if we need to revert it, third party maintainers can have more time to prepare the removal and we can get feedback from the community early. Cons: Adding warnings in beta period will make some confusion. Note that we need to avoid the warning from CPython core and stdlib. Use hashtable to store wstr --------------------------- Store the ``wstr`` in a hashtable, instead of Unicode structure. Pros: We can save memory usage even from Python 3.10. We can have more longer timeline to remove the ``wstr``. Cons: This implementation will increase the complexity of Unicode implementation. References ========== A collection of URLs used as references through the PEP. .. [1] PEP 393 -- Flexible String Representation (https://www.python.org/dev/peps/pep-0393/) .. [2] GH-20878 -- Add Py_DEPRECATED to deprecated unicode APIs (https://github.com/python/cpython/pull/20878) .. [3] GH-20933 -- Raise DeprecationWarning when creating legacy Unicode (https://github.com/python/cpython/pull/20933) .. [4] GH-20927 -- Raise DeprecationWarning for getargs with 'u', 'Z' #20927 (https://github.com/python/cpython/pull/20927) Copyright ========= This document has been placed in the public domain. -- Inada Naoki <songofacandy(a)gmail.com>

2 5

Re%3A Re%3A New optional dependency - TkDND&In-Reply-To=<45fe0089-6c26-4238-9e7c-ec38f719d781%40gmail.com>
by Elisha Paine June 23, 2020

June 23, 2020

> What's the advantage of having TkDND bindings in the standard library 1. I think there is enough demand for the feature to make it worth adding to the stdlib (and the actual bindings are not that large so won’t require much maintenance). There are several threads on Stack Overflow where using TkDND with tkinter is discussed and https://stackoverflow.com/questions/14267900, for example, appears to have attracted a fair amount of attention (being viewed 27k times). 2. tkinter is often one of the first Python GUI toolkits learnt and (on most platforms) installing TkDND is not a one-click process. As a result, there are at least a couple of SO threads regarding installing TkDND (I keep mentioning SO as I consider it a good way of understanding the ‘typical’ user). 3. To make the bindings work correctly, they required changes to existing tkinter methods and I try very hard to avoid monkey-patching where possible. 4. This is a small point, but I thought it worth mentioning that the tkinter.dnd docs have said this has been coming for a long time. Even if this change doesn’t go ahead I think it would be worth changing the docs to stop saying that this feature is coming… Thank you, both of you, for the reassurance you have given and I will look into raising third party issues if I notice a distribution hasn’t updated the package information (I won’t raise issues pre-emptively, though).

1 0

New optional dependency
by Elisha Paine June 23, 2020

June 23, 2020

Hi all, I am looking at getting TkDND support into tkinter, and have created issue40893. However, we are currently considering the practicalities of adding a new optional dependency to Python and I was hoping someone could help answer the question of: is there a procedure for this? The problem is that third-party distributors need to be notified of the change and edit the package details accordingly. The current idea is just to make it very clear on the “what’s new” page, however this would not guarantee it would be seen, so I am very open to ideas/opinions. Thanks, Elisha

3 2

Cython and incompatible C API changes
by Victor Stinner June 23, 2020

June 23, 2020

re: [Python-Dev] When can we remove wchar_t* cache from string? Le mar. 16 juin 2020 à 21:19, Steve Dower <steve.dower(a)python.org> a écrit : > On 16Jun2020 1641, Inada Naoki wrote: > > * This change doesn't affect to pure Python packages. > > * Most of the rest uses Cython. Since I already report an issue to Cython, > > regenerating with new Cython release fixes them. > > The precedent set in our last release with tp_print was that > regenerating Cython releases was too much to ask. > > Unless we're going to overrule that immediately, we should leave > everything there and give users/developers a full release cycle with > updated Cython version to make new releases without causing any breakage. I already made changes in Python 3.10 which require again to regenerate C code generated by Cython: https://docs.python.org/dev/whatsnew/3.10.html#id2 Py_TYPE(), Py_REFCNT() and Py_SIZE() can no longer be used as l-value. These changes also broke numpy. I helped to fix Cython and numpy (and they are already fixed). You can expect further incompatible changes in the C API. For example, I would like to make the PyThreadState structure opaque, whereas Cython currently accesses directly to PyThreadState members. There is an ongoing discussion about always requiring to run Cython when installing a C extension which uses Cython. Maybe we can find a way to use pre-generated C files for Python up to version N, but require to run Cython for Python newer than version N? It would prevent to require running Cython on stable Python versions, but help to upgrade to newer Python and also test the "next Python" (current master branch). Note: if the Py_TYPE() & cie changes are causing too many issues, we can also reconsider to postpone/revert these changes. IMO it's important that we remain able to push incompatible changes to the C API, because there are multiple known flaws in the C API. Victor -- Night gathers, and now my watch begins. It shall not end until my death.

5 5

os.add_dll_directory and DLL search order
by Seth G June 22, 2020

June 22, 2020

Hi list, I've been trying to get new Python 3.8 builds for the MapServer project - these are SWIG-generated bindings that require many DLLs to import in Python. Up until now this worked by adding a folder to the top of the Windows PATH. I've read through the discussions at https://bugs.python.org/issue36085 and understand the reasoning behind the change. Is the recommended solution in cases of Python wrappers to create a project-specific environment variable and allow users to set this, which in turn the library adds with add_dll_directory? However, there is one feature of using the Windows PATH that I can't seem to replicate with add_dll_directory. The MapServer DLL builds are linked to sqlite3 3.24.0, whereas Python 3.8.2 is linked to 2.6.0. Building with matching versions is not something I can easily change. When using Windows PATH the folder with the newer version could be added to the front of the list to take priority and import worked correctly. This does not seem to be possible with add_dll_directory - the Python sqlite3.dll in C:\Python38\DLLs always takes priority leading to: ImportError: DLL load failed while importing _mapscript: The specified procedure could not be found. I presume I can't remove the C:\Python38\DLLs path, is there another solution to this issue? Thanks in advance for any help, Seth -- web:http://geographika.co.uk twitter: @geographika

5 7

Should we be making so many changes in pursuit of PEP 554?
by Mark Shannon June 22, 2020

June 22, 2020

Hi, There have been a lot of changes both to the C API and to internal implementations to allow multiple interpreters in a single O/S process. These changes cause backwards compatibility changes, have a negative performance impact, and cause a lot of churn. While I'm in favour of PEP 554, or some similar model for parallelism in Python, I am opposed to the changes we are currently making to support it. What are sub-interpreters? -------------------------- A sub-interpreter is a logically independent Python process which supports inter-interpreter communication built on shared memory and channels. Passing of Python objects is supported, but only by copying, not by reference. Data can be shared via buffers. How can they be implemented to support parallelism? --------------------------------------------------- There are two obvious options. a) Many sub-interpreters in a single O/S process. I will call this the many-to-one model (many interpreters in one O/S process). b) One sub-interpreter per O/S process. This is what we currently have for multiprocessing. I will call this the one-to-one model (one interpreter in one O/S process). There seems to be an assumption amongst those working on PEP 554 that the many-to-one model is the only way to support sub-interpreters that can execute in parallel. This isn't true. The one-to-one model has many advantages. Advantages of the one-to-one model ---------------------------------- 1. It's less bug prone. It is much easier to reason about code working in a single address space. Most code assumes 2. It's more secure. Separate O/S processes provide a much stronger boundary between interpreters. This is why some browsers use separate processes for browser tabs. 3. It can be implemented on top of the multiprocessing module, for testing. A more efficient implementation can be developed once sub-interpreters prove useful. 4. The required changes should have no negative performance impact. 5. Third party modules should continue to work as they do now. 6. It takes much less work :) Performance ----------- Creating O/S processes is usually considered to be slow. Whilst processes are undoubtedly slower to create than threads, the absolute time to create a process is small; well under 1ms on linux. Creating a new sub-interpreter typically requires importing quite a few modules before any useful work can be done. The time spent doing these imports will dominate the time to create an O/S process or thread. If sub-interpreters are to be used for parallelism, there is no need to have many more sub-interpreters than CPU cores, so the overhead should be small. For additional concurrency, threads or coroutines can be used. The one-to-one model is faster as it uses the hardware for interpreter separation, whereas the many-to-one model must use software. Process separation by the hardware virtual memory system has zero cost. Separation done in software needs extra memory reads when doing allocation or deallocation. Overall, for any interpreter that runs for a second or more, it is likely that the one-to-one model would be faster. Timings of multiprocessing & threads on my machine (6-core 2019 laptop) ----------------------------------------------------------------------- #Threads def foo(): pass def spawn_and_join(count): threads = [ Thread(target=foo, args=()) for _ in range(count) ] for t in threads: t.start() for t in threads: t.join() spawn_and_join(1000) # Processes def spawn_and_join(count): processes = [ Process(target=foo, args=()) for _ in range(count) ] for p in processes: p.start() for p in processes: p.join() spawn_and_join(1000) Wall clock time for threads: 86ms. Less than 0.1ms per thread. Wall clock time for processes: 370ms. Less than 0.4ms per process. Processes are slower, but plenty fast enough. Cheers, Mark.

20 50

Accepting PEP 618: zip(strict=True)
by Guido van Rossum June 20, 2020

June 20, 2020

After taking a break to recapitulate from the vigorous debate, Brandt Bucher has revised PEP 618 <https://www.python.org/dev/peps/pep-0618/> and submitted it for review <https://github.com/python/peps/pull/1429>. I volunteered to be PEP-Delegate (the new term for the outdated BDFL-Delegate) and the SC has approved <https://github.com/python/steering-council/issues/28#issuecomment-644280869> me for this role. (Note that Antoine, the PEP's sponsor, declined to be the lightning rod, er, PEP-Delegate.) I have now reviewed the PEP and skimmed some of the more recent discussion about the topic. It is clear that no solution will win everyone over. But most seem to agree that offering *some* solution for the stated problem is better than none. To spare us more heartache, I am hereby accepting PEP 618. I expect that the implementation <https://github.com/python/cpython/pull/20921> will land soon. I have two very minor editorial remarks, which Brandt may address at his leisure: - The "Backward Compatibility" section could be beefed up slightly, e.g. by pointing out that the default remains strict=False and that zip previously did not take keyword arguments at all. - The error messages are somewhat odd: why is the error sometimes that one iterator is too long, and other times that one iterator is too short? All we really know is that not all iterators have the same length, but the current phrasing seems to be assuming that the first iterator is never too short or too long. Congratulations, Brandt! -- --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-…>

8 9

How to specify optional support of arguments
by Serhiy Storchaka June 19, 2020

June 19, 2020

In Python 3.3 a number of functions in the os module got the support of new options, like dir_fd or follow_symlinks. I well remember this because the initial reason of my contribution to CPython was related to this feature. The support of new options was platform dependent. They were supported only on some Posix platforms, but not on Windows. Sets like supports_dir_fd and supports_follow_symlinks was added in the os module to specify which functions support which options. If say os.stat is contained in os.supports_dir_fd, then os.stat() supports keyword argument dir_fd. Now I want to add the support of dir_fd to glob.glob() and some other functions. It will be platform-dependent, it requires os.open() and os.stat() supporting dir_fd and os.scandir supporting the file descriptor argument. How can I specify that glob.glob() supports dir_fd? 1. Add glob.glob in os.supports_dir_fd? It looks strange that importing the glob module modifies the value of the os module. 2. Introduce the glob.supports_dir_fd set and add glob.glob to it? We will need to add sets supports_dir_fd in all modules which contain functions which can support dir_fd. But what if the function is defined in one module, by normally is imported from other module? Should we merge sets supports_dir_fd from different modules? Also, the common problem with two former options is that when we wrap the function, we need to add it to the corresponding set. 3. Or set the attribute glob.glob.supports_dir_fd = True or glob.glob.__supports_dir_fd__ = True (and add similar attributes to all os functions which support)? What are your thoughts?

6 8

Summary of Python tracker Issues
by Python tracker June 19, 2020

June 19, 2020

ACTIVITY SUMMARY (2020-06-12 - 2020-06-19) 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 7476 (+29) closed 45305 (+47) total 52781 (+76) Open issues with patches: 3026 Issues opened (61) ================== #39949: truncating match in regular expression match objects repr https://bugs.python.org/issue39949 reopened by eric.smith #40890: Dict views should be introspectable https://bugs.python.org/issue40890 reopened by serhiy.storchaka #40964: Connection to IMAP server cyrus.andrew.cmu.edu hangs https://bugs.python.org/issue40964 opened by christian.heimes #40965: Segfault when importing unittest module via C API https://bugs.python.org/issue40965 opened by The Comet #40967: asyncio.Task.all_tasks() and asyncio.Task.current_task() must https://bugs.python.org/issue40967 opened by remi.lapeyre #40968: urllib does not send http/1.1 ALPN extension https://bugs.python.org/issue40968 opened by pmenzel #40970: Error in Python Datamodel Documentation https://bugs.python.org/issue40970 opened by chrisyeh96 #40971: Documentation still mentions 'u' string formatting option https://bugs.python.org/issue40971 opened by gphemsley #40974: possible optimization: SHRINK_STACK(n) https://bugs.python.org/issue40974 opened by shrink_stack #40975: contextlib.AsyncExitStack enter_async_context and aclose shoul https://bugs.python.org/issue40975 opened by naglis #40977: asyncio.trsock.TransportSocket says some APIs will be prohibit https://bugs.python.org/issue40977 opened by ronaldoussoren #40978: Document that typing.SupportsXXX protocols are runtime checkab https://bugs.python.org/issue40978 opened by ramalho #40979: typing module docs: keep text, add subsections https://bugs.python.org/issue40979 opened by ramalho #40980: group names of bytes regexes are strings https://bugs.python.org/issue40980 opened by matpi #40982: copytree example in shutil https://bugs.python.org/issue40982 opened by Alberto Torres Barrán #40984: re.compile's repr truncates patterns at 200 characters https://bugs.python.org/issue40984 opened by matpi #40986: Async generators are not garbage collected https://bugs.python.org/issue40986 opened by vytas #40987: Add tests to test_interpreters to import C extension modules c https://bugs.python.org/issue40987 opened by vstinner #40988: singledispatchmethod significantly slower than singledispatch https://bugs.python.org/issue40988 opened by CaselIT #40989: [C API] Remove _Py_NewReference() and _Py_ForgetReference() fr https://bugs.python.org/issue40989 opened by vstinner #40990: Make http.server support SSL https://bugs.python.org/issue40990 opened by remi.lapeyre #40992: Wrong warning in asyncio debug mode https://bugs.python.org/issue40992 opened by Alex Alex #40994: Very confusing documenation for abc.Collections https://bugs.python.org/issue40994 opened by Sydney Pemberton #40995: reprlib.Repr.__init__ should accept arguments https://bugs.python.org/issue40995 opened by remi.lapeyre #40996: urllib should fsdecode percent-encoded parts of file URIs on U https://bugs.python.org/issue40996 opened by mjacob #40998: Compiler warnings in ubsan builds https://bugs.python.org/issue40998 opened by christian.heimes #40999: implicit-int-float-conversion warnings in time and math code https://bugs.python.org/issue40999 opened by christian.heimes #41000: IDLE: only allow single instance https://bugs.python.org/issue41000 opened by epaine #41001: Provide wrapper for eventfd https://bugs.python.org/issue41001 opened by christian.heimes #41002: HTTPResponse.read with amt is slow https://bugs.python.org/issue41002 opened by bmerry #41004: Hash collisions in IPv4Interface and IPv6Interface https://bugs.python.org/issue41004 opened by nnewram #41005: Permission denied: 'xdg-settings' when executing 'jupyter note https://bugs.python.org/issue41005 opened by SBC King #41007: test_importlib logs ResourceWarning: test_path.CommonTests.tes https://bugs.python.org/issue41007 opened by vstinner #41008: multiprocessing.Connection.poll raises BrokenPipeError on Wind https://bugs.python.org/issue41008 opened by zanchey #41009: @support.requires_*_version broken for classes https://bugs.python.org/issue41009 opened by christian.heimes #41010: email.message.EmailMessage.get_body https://bugs.python.org/issue41010 opened by patrick totzke #41011: [venv] record which executable and command were used to create https://bugs.python.org/issue41011 opened by brett.cannon #41012: Some code comments refer to removed initfsencoding() https://bugs.python.org/issue41012 opened by mjacob #41013: test_os.test_memfd_create() fails on AMD64 FreeBSD Shared 3.x https://bugs.python.org/issue41013 opened by vstinner #41014: warning: 'sqlite3_trace' is deprecated https://bugs.python.org/issue41014 opened by svaddi #41015: warning: 'sqlite3_enable_shared_cache' is deprecated https://bugs.python.org/issue41015 opened by svaddi #41016: warning: 'Tk_GetNumMainWindows' is deprecated https://bugs.python.org/issue41016 opened by svaddi #41017: warning: 'Tk_Init' is deprecated: first deprecated https://bugs.python.org/issue41017 opened by svaddi #41018: warning: 'Tk_MainWindow' is deprecated: first deprecated https://bugs.python.org/issue41018 opened by svaddi #41019: The necessary bits to build these optional modules were not fo https://bugs.python.org/issue41019 opened by svaddi #41021: ctypes callback with structure crashes in Python 3.8 on Window https://bugs.python.org/issue41021 opened by itsgk92 #41022: AST sum types is unidentifiable after ast.Constant became a ba https://bugs.python.org/issue41022 opened by BTaskaya #41024: doc: Explicitly mention use of 'enum.Enum' as a valid containe https://bugs.python.org/issue41024 opened by vincent-ferotin #41025: C implementation of ZoneInfo cannot be subclassed https://bugs.python.org/issue41025 opened by p-ganssle #41026: mailbox does not support new Path object https://bugs.python.org/issue41026 opened by LimaAlphaHotel #41027: get_version() fails to return gcc version for gcc-7 https://bugs.python.org/issue41027 opened by mbarbera #41028: Move docs.python.org language and version switcher out of cpyt https://bugs.python.org/issue41028 opened by mdk #41031: Inconsistency in C and python traceback printers https://bugs.python.org/issue41031 opened by msimacek #41032: locale.setlocale example incorrect https://bugs.python.org/issue41032 opened by pintman #41033: readline.c: SEGFAULT on SIGWINCH when loaded twice https://bugs.python.org/issue41033 opened by blueyed #41034: test_builtin: PtyTests fail when run twice https://bugs.python.org/issue41034 opened by vstinner #41035: zipfile.Path does not work properly with zip archives where pa https://bugs.python.org/issue41035 opened by sorrow #41036: Visit the type of instance of heap types if tp_traverse is not https://bugs.python.org/issue41036 opened by vstinner #41037: Add (optional) threadstate to: PyOS_InterruptOccurred() https://bugs.python.org/issue41037 opened by seberg #41038: VersionInfo string is corrupted when building on Windows with https://bugs.python.org/issue41038 opened by nnemkin #41039: Simplify python3.dll build https://bugs.python.org/issue41039 opened by nnemkin Most recent 15 issues with no replies (15) ========================================== #41039: Simplify python3.dll build https://bugs.python.org/issue41039 #41038: VersionInfo string is corrupted when building on Windows with https://bugs.python.org/issue41038 #41036: Visit the type of instance of heap types if tp_traverse is not https://bugs.python.org/issue41036 #41033: readline.c: SEGFAULT on SIGWINCH when loaded twice https://bugs.python.org/issue41033 #41032: locale.setlocale example incorrect https://bugs.python.org/issue41032 #41031: Inconsistency in C and python traceback printers https://bugs.python.org/issue41031 #41027: get_version() fails to return gcc version for gcc-7 https://bugs.python.org/issue41027 #41025: C implementation of ZoneInfo cannot be subclassed https://bugs.python.org/issue41025 #41024: doc: Explicitly mention use of 'enum.Enum' as a valid containe https://bugs.python.org/issue41024 #41019: The necessary bits to build these optional modules were not fo https://bugs.python.org/issue41019 #41018: warning: 'Tk_MainWindow' is deprecated: first deprecated https://bugs.python.org/issue41018 #41017: warning: 'Tk_Init' is deprecated: first deprecated https://bugs.python.org/issue41017 #41016: warning: 'Tk_GetNumMainWindows' is deprecated https://bugs.python.org/issue41016 #41015: warning: 'sqlite3_enable_shared_cache' is deprecated https://bugs.python.org/issue41015 #41014: warning: 'sqlite3_trace' is deprecated https://bugs.python.org/issue41014 Most recent 15 issues waiting for review (15) ============================================= #41039: Simplify python3.dll build https://bugs.python.org/issue41039 #41038: VersionInfo string is corrupted when building on Windows with https://bugs.python.org/issue41038 #41036: Visit the type of instance of heap types if tp_traverse is not https://bugs.python.org/issue41036 #41028: Move docs.python.org language and version switcher out of cpyt https://bugs.python.org/issue41028 #41027: get_version() fails to return gcc version for gcc-7 https://bugs.python.org/issue41027 #41026: mailbox does not support new Path object https://bugs.python.org/issue41026 #41025: C implementation of ZoneInfo cannot be subclassed https://bugs.python.org/issue41025 #41024: doc: Explicitly mention use of 'enum.Enum' as a valid containe https://bugs.python.org/issue41024 #41009: @support.requires_*_version broken for classes https://bugs.python.org/issue41009 #41005: Permission denied: 'xdg-settings' when executing 'jupyter note https://bugs.python.org/issue41005 #41004: Hash collisions in IPv4Interface and IPv6Interface https://bugs.python.org/issue41004 #41002: HTTPResponse.read with amt is slow https://bugs.python.org/issue41002 #41001: Provide wrapper for eventfd https://bugs.python.org/issue41001 #40998: Compiler warnings in ubsan builds https://bugs.python.org/issue40998 #40995: reprlib.Repr.__init__ should accept arguments https://bugs.python.org/issue40995 Top 10 most discussed issues (10) ================================= #40980: group names of bytes regexes are strings https://bugs.python.org/issue40980 26 msgs #39949: truncating match in regular expression match objects repr https://bugs.python.org/issue39949 15 msgs #30064: BaseSelectorEventLoop.sock_{recv,sendall}() don't remove their https://bugs.python.org/issue30064 11 msgs #38377: test_asyncio.test_events.GetEventLoopTestsMixin.test_get_event https://bugs.python.org/issue38377 10 msgs #40984: re.compile's repr truncates patterns at 200 characters https://bugs.python.org/issue40984 7 msgs #40989: [C API] Remove _Py_NewReference() and _Py_ForgetReference() fr https://bugs.python.org/issue40989 7 msgs #41013: test_os.test_memfd_create() fails on AMD64 FreeBSD Shared 3.x https://bugs.python.org/issue41013 7 msgs #36346: Prepare for removing the legacy Unicode C API https://bugs.python.org/issue36346 6 msgs #40511: IDLE: properly handle '(' and ')' within calls https://bugs.python.org/issue40511 5 msgs #40964: Connection to IMAP server cyrus.andrew.cmu.edu hangs https://bugs.python.org/issue40964 5 msgs Issues closed (47) ================== #10118: Tkinter does not find font https://bugs.python.org/issue10118 closed by terry.reedy #28557: error message for bad raw readinto https://bugs.python.org/issue28557 closed by benjamin.peterson #33315: Allow queue.Queue to be used in type annotations https://bugs.python.org/issue33315 closed by rhettinger #33881: dataclasses should use NFKC to find duplicate members https://bugs.python.org/issue33881 closed by eric.smith #34226: cgi.parse_multipart() requires undocumented CONTENT-LENGTH in https://bugs.python.org/issue34226 closed by orsenthil #36020: HAVE_SNPRINTF and MSVC std::snprintf support https://bugs.python.org/issue36020 closed by vstinner #37673: Tkinter won't create 5000 check boxes, stops at 1309. https://bugs.python.org/issue37673 closed by terry.reedy #37674: Is imp module deprecated or pending deprecation? https://bugs.python.org/issue37674 closed by brett.cannon #38488: Update bundled pip to 20.1.1 https://bugs.python.org/issue38488 closed by ned.deily #38783: the window size is bigger than the specific size when create a https://bugs.python.org/issue38783 closed by serhiy.storchaka #39756: Event sequence "KeyRelease-Shift_R" not being fired https://bugs.python.org/issue39756 closed by cheryl.sabella #40119: ensurepip should use different pattern for pip/setuptool wheel https://bugs.python.org/issue40119 closed by ned.deily #40164: Upgrade Windows and macOS installer builds to OpenSSL 1.1.1g https://bugs.python.org/issue40164 closed by steve.dower #40334: PEP 617: new PEG-based parser https://bugs.python.org/issue40334 closed by lys.nikolaou #40353: Add an optional "strict" check to zip https://bugs.python.org/issue40353 closed by brandtbucher #40448: ensurepip uses cache directory https://bugs.python.org/issue40448 closed by ned.deily #40498: Holding spacebar on button widget permanently makes it SUNKEN https://bugs.python.org/issue40498 closed by ned.deily #40680: thread_cputime isn't supported by AIX5 https://bugs.python.org/issue40680 closed by vstinner #40808: test_venv fails with HOME=/ on AMD64 FreeBSD Non-Debug 3.x https://bugs.python.org/issue40808 closed by ned.deily #40834: sending str via channel caused truncate on last character https://bugs.python.org/issue40834 closed by cheryl.sabella #40836: logging.fatal() and logging.Logger.fatal() should raise a Depr https://bugs.python.org/issue40836 closed by remi.lapeyre #40855: statistics.stdev ignore xbar argument https://bugs.python.org/issue40855 closed by rhettinger #40873: Something wrong with html.unescape() https://bugs.python.org/issue40873 closed by serhiy.storchaka #40914: tarfile creates output that appears to omit files https://bugs.python.org/issue40914 closed by zach.ware #40925: Remove redundant macros used for stack manipulation in interpr https://bugs.python.org/issue40925 closed by Mark.Shannon #40943: PEP 353: Drop support for PyArg_ParseTuple() "#" formats when https://bugs.python.org/issue40943 closed by vstinner #40945: TKinter.Tk.geometry(Tk.winfo_geometry()) should be idempotent https://bugs.python.org/issue40945 closed by serhiy.storchaka #40953: PyConfig_Clear() doesn't clear _orig_argv member (_PyWideStrin https://bugs.python.org/issue40953 closed by vstinner #40957: _Py_fopen_obj leaks reference on audit error https://bugs.python.org/issue40957 closed by corona10 #40958: ASAN/UBSAN: heap-buffer-overflow in pegen.c https://bugs.python.org/issue40958 closed by pablogsal #40966: Remove redundant var in PyErr_NewException https://bugs.python.org/issue40966 closed by corona10 #40969: Python 3.8.3 And Now For Something CompletelyDifferent https://bugs.python.org/issue40969 closed by cheryl.sabella #40972: Add a recurse flag to Path.rmdir() https://bugs.python.org/issue40972 closed by serhiy.storchaka #40973: platform.platform() in Python 3.8 does not report detailed Lin https://bugs.python.org/issue40973 closed by SilentGhost #40976: Clarify motivation for `chain.from_iterable` https://bugs.python.org/issue40976 closed by rhettinger #40981: increment is wrong in 3.7 but not in 2.7 https://bugs.python.org/issue40981 closed by serhiy.storchaka #40983: urllib.request.url2pathname() unconditionally uses utf-8 encod https://bugs.python.org/issue40983 closed by mjacob #40985: PEG Parser: SyntaxError text empty when last line has a LINECO https://bugs.python.org/issue40985 closed by lys.nikolaou #40991: Can't open more than on .py file with IDLE https://bugs.python.org/issue40991 closed by terry.reedy #40993: Don't run Python and C coverage jobs of Travis CI on pull requ https://bugs.python.org/issue40993 closed by vstinner #40997: python 3.8.2: datetime.datetime(1969,1,1).timestamp() yields O https://bugs.python.org/issue40997 closed by SilentGhost #41003: test_copyreg: importing numpy changes warnings filters https://bugs.python.org/issue41003 closed by vstinner #41006: Reduce number of modules imported by runpy https://bugs.python.org/issue41006 closed by vstinner #41020: Could not build the ssl module! https://bugs.python.org/issue41020 closed by christian.heimes #41023: smtplib does not handle Unicode characters https://bugs.python.org/issue41023 closed by r.david.murray #41029: parallel sftp from local to remote file creates empty director https://bugs.python.org/issue41029 closed by christian.heimes #41030: Provide toList() method on iterators/generators (`list()` is a https://bugs.python.org/issue41030 closed by zach.ware

1 0

[RELEASE] Python 3.7.8rc1 and 3.6.11rc1 are now available for testing
by Ned Deily June 18, 2020

June 18, 2020

Details here: https://discuss.python.org/t/python-3-7-8rc1-and-3-6-11rc1-are-now-availabl… https://www.python.org/downloads/release/python-378rc1/ https://www.python.org/downloads/release/python-3611rc1/ -- Ned Deily nad(a)python.org -- []

1 0

Improving inspect capabilities for classes
by Thomas Viehmann June 17, 2020

June 17, 2020

Hello, thank you for making Python and the neat inspect module. I would love to hear your opinion on the following aspect of inspect that I believe might be worth improving: Consider the following program saved in a file (say hello.py): import inspect def hello(): print("Hello World") print(inspect.getsource(hello)) class Hello: def __init__(self): print("Hello World") print(inspect.getsource(Hello)) Running hello.py will, unsurprisingly, print the source of hello and Hello. Now, some of us use an Jupyter (with the capabilities provided by IPython) notebooks, which are a great tool and awesome match with Python. These notebooks can be large and complex enough to want to use introspection on methods defined in itself (also, I'm prototyping things I might want to use as a library in Notebooks a lot, and I think I'm not alone). IPython enhances the interactive console to enable introspection (by providing "files" for the cells). As a result, the following will work as expected: def hello(): print("Hello World") print(inspect.getsource(hello)) However, it does not work for classes: class Hello: def __init__(self): print("Hello World") print(inspect.getsource(Hello)) will run into an error in a Jupyter notebook, more precisely TypeError: <class '__main__.Hello'> is a built-in class The reason why the latter does not work is because inspect cannot find a source file. The technical background is that for a function hello, inspect.getfile finds the file through hello.__code__.co_filename which IPython can arrange for, while for the class Hello, it tries `Hello.__module__`, which is `__main__` and then would see if sys.modules[Hello.__module__] has a __file__ attribute, which it does not (and which could not be disambiguated into cell-level). I once made a PR in github #13894 and earlier https://bugs.python.org/issue33826 but got, let's say, reactions that were not entirely encouraging. I still think that it is a useful feature and I don't think that there are readily available solutions and after another year has passed, I humbly submit this for your considerations. Best regards and thank you. Thomas

5 8

Design and Architecture of python
by Shakil Khan June 17, 2020

June 17, 2020

I am well versed in Python and now trying to understand and learn the Design philosophy of Python as a Programming Language. Is there any document related to Design/Archoitecture of Python language itself where I can learn about implementation of garbage collection, top level of python objects and different other features. Bottom line is I want to understand and get hold of the Python source code itself in C. Any document or pointer towards that would be very much appreciated. Thanks Shakil

2 2

type() does not call __prepare__?
by Ethan Furman June 17, 2020

June 17, 2020

From stackoverflow [1] # metaprepare.py class Meta1(type): @classmethod def __prepare__(mcs, name, bases): print('call prepare') return {} def __new__(mcs, name, bases, parameters): return super().__new__(mcs, name, bases, parameters) class A(metaclass=Meta1): pass type('C', (A, ), {}) output is: call prepare (just the once, not twice) The behavior of `type()` not calling `__prepare__()` has been constant since 3.3. Is it a bug? -- ~Ethan~ [1] https://stackoverflow.com/q/62128254/208880

3 2

Are extension types allowed to implement both nb_add and sq_concat?
by Eric Wieser June 16, 2020

June 16, 2020

Hi all, In the `operator` module, both `operator.concat` and `operator.add` are described as performing `a + b`. When defining a type in pure python, it is not possible to give these different meanings. However, when defining a C extension type, it is possible to fill both `tp_as_number->nb_add` and `tp_as_sequence->sq_concat` with different implementations to obtain different behaviors. Is the fact that `operator.concat` (`PySequence_Concat`) and `operator.add` (`PyNumber_Add`) can have different behaviors an implementation detail of CPython, or is it intended behavior in the language itself? I ask because [a recent PR for numpy][1] proposes implementing both of these slots, and discussion turned to whether it was intended to be possible to do this in the first place, and if so whether a patch will be needed to PyPy. It seems that there was at least some vague intent for this to be possible - In bpo-29139, Serhiy said > Third-party classes (maybe NumPy arrays, I don't know) can have different implementations of `sq_concat` and `nb_add`. It seems to me there are at least three stances that could be taken here: * Specifying both is considered invalid: python should consider emitting a warning in `Type_READY` if both are filled. * Specifying both is considered an implementation detail specific to CPython: the [C API docs for the type slots][2] should indicate this * Specifying both is explicitly allowed and considered a language feature. `__concat__` should be added as a slot_wrapper around `sq_concat` to allow the language feature to be accessed without writing C extensions. Eric Wieser Apologies if this is not the right list - this didn't feel right for python-ideas or bpo. I'm more than happy to repost this elsewhere if asked. [1]: https://github.com/numpy/numpy/issues/16489 [2]: https://docs.python.org/3/c-api/typeobj.html

4 5

REPL output bug
by Rob Cliffe June 16, 2020

June 16, 2020

If I run the following program (using Python 3.8.3 on a Windows 10 laptop): import sys, time for i in range(1,11): sys.stdout.write('\r%d' % i) time.sleep(1) As intended, it displays '1', replacing it at 1-second intervals with '2', '3' ... '10'. Now run the same code inside the REPL: Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, time >>> for i in range(1,11): ... sys.stdout.write('\r%d' % i) ... time.sleep(1) ... 12 22 32 42 52 62 72 82 92 103 >>> It appears that the requested characters are output, *followed by* the number of characters output (which is the value returned by sys.stdout.write) and a newline. Surely this is not the intended behaviour. sys.stderr behaves the same as sys.stdout. Python 2 does NOT exhibit this behaviour: Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, time >>> for i in range(1,11): ... sys.stdout.write('\r%d' % i) ... time.sleep(1) ... 10>>> # displays '1', '2' ... '10' as intended. Best wishes Rob Cliffe

9 9

Re: Proposed release schedule for 3.5.9
by John Thorvald Wodder II June 16, 2020

June 16, 2020

3.5.9 was already released back in November. Yes, it's (almost) the same code as 3.5.8, but its version number (as reported by `python -V` etc.) is still 3.5.9. Releasing another 3.5.9 would just lead to confusion at best. I feel that the July release should be numbered 3.5.10 instead. -- John Wodder

2 1

Removal of _Py_ForgetReference from public header in 3.9 issue
by cpython＠nicwatson.org June 15, 2020

June 15, 2020

Please excuse if this is the wrong mailing list. I couldn't find one for module maintainers. I maintain an open source Python module in C. I'm trying to verify for the first time that the module still works with cpython 3.9. This module does *not* use the "limited" C API. In building my module against 3.9b3, I'm getting a missing declaration warning on _Py_ForgetReference. My module builds and passes test fine, this is just a compiler warning issue. The change that caused this was made in: commit f58bd7c1693fe041f7296a5778d0a11287895648 Author: Victor Stinner <vstinner(a)python.org> Date: Wed Feb 5 13:12:19 2020 +0100 bpo-39542: Make PyObject_INIT() opaque in limited C API (GH-18363) ... I definitely need the _Py_ForgetReference call for a particularly hairy error condition (https://github.com/jnwatson/py-lmdb/blob/master/lmdb/cpython.c#L888 if you're curious). In fact, my tests will seg fault if I don't have that call and trace refs is enabled. Should I put an #ifdef Py_TRACE_REFS around the call? Ignore it? What do you think is the proper resolution? Nic Watson

3 2

Cycles in the __context__ chain
by Serhiy Storchaka June 15, 2020

June 15, 2020

It is possible to create a loop by setting the __context__ attribute of the raised exception, either explicitly, or implicitly, using "raise ... from ...". Creating a loop can leads to the hanging in infinite loop or crash due to stack overflow. Several years ago we did have issues related to ExitStack and contextmanager() [1] [2], and recently we have found other issue related to asynccontextmanager() [3]. There may be other issues in the stdlib or third-party libraries. To solve all such issues we can prevent creating the loop in the __context__ setter. Unfortunately there is no way to return an error in PyException_SetContext(), so it is always success. So we should break a loop at some point. There was proposed several options. If we have a chain A -> B -> C -> D -> E -> NULL after raising C in the context of A ("raise C from A") or setting C.__context__ = A we will get a chain: 0. C -> A -> B -> C -> A -> B -> ... A loop. This is the current behavior. 1. C -> D -> E -> NULL The operation is no-op. We lose information about exceptions preceding C: A and B. 2. C -> NULL Lose all context. 3. C -> A -> B -> D -> E -> NULL C is moved at the front of the chain. No exception is lost, but their order is changed. 4. C -> A -> B -> NULL Remove C from the chain and rewrite its context. We lose information about the old context of C: D and E. 5. C -> A -> B -> C' -> D -> E -> NULL Create a copy of C (how?) and replace C with its copy in the chain. But what to do with other references to C? There may be other options. We need to solve this issue, otherwise we will continue to stick with other bugs related to the exceptions loop. [1] https://bugs.python.org/issue25779 [2] https://bugs.python.org/issue25786 [3] https://bugs.python.org/issue40696 [4] https://bugs.python.org/issue25782

3 2

Proposed release schedule for 3.5.9
by Larry Hastings June 14, 2020

June 14, 2020

Gosh how time flies. 3.5 is nearing the end of its security maintenance period, and as such the patches have slowed down. But we got a couple recently--all having to do with web technologies--so it's probably time to make another release. I propose to release rc1 in two weeks, and final two weeks after that. Specifically: Sunday Jun 28 - 3.5.9rc1 Sunday Jul 12 - 3.5.9 final Of course, since we're in the security-fixes-only period, these will all be source-code only releases. Let me know if this is too soon for you. My suspicion is it's no problem. It's mainly one developer filing security patches for 3.5 anyway (hi Victor!) and I'll contact him directly to make sure. 3.5 will be 5 years old this August, at which point we'll formally end 3.5 support. I expect there'll be only one more release after that, 3.5.10, and that'll be it. At which point, at last! you'll be rid of me as a release manager! Surely on that day the programming world will breathe a collective sigh of relief. Best wishes, //arry/

1 0

Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x
by Ned Deily June 13, 2020

June 13, 2020

We will be accecpting commits to the 3.7 branch until this coming Monday 06-15 23:59 AOE. At that time, 3.7 will effectively enter security-fix mode. That will also be the deadline for any additional security-fixes for release in 3.6.11. Release candidates will follow shortly thereafter. Assuming no release-blocker issues arise during the release candidate testing, 3.7.8 and 3.6.11 will release on 06-27. https://discuss.python.org/t/upcoming-cutoffs-for-3-9-3-8-3-7-and-3-6-relea… -- Ned Deily nad(a)python.org -- []

4 7

Summary of Python tracker Issues
by Python tracker June 12, 2020

June 12, 2020

ACTIVITY SUMMARY (2020-06-05 - 2020-06-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 7447 ( +3) closed 45258 (+78) total 52705 (+81) Open issues with patches: 3009 Issues opened (57) ================== #29782: Use __builtin_clzl for bits_in_digit if available https://bugs.python.org/issue29782 reopened by vstinner #40878: Use c99 on the aixtools bot https://bugs.python.org/issue40878 opened by skrah #40882: memory leak in multiprocessing.shared_memory.SharedMemory in W https://bugs.python.org/issue40882 opened by eryksun #40884: Added defaults parameter for logging.Formatter https://bugs.python.org/issue40884 opened by bar.harel #40885: Cannot pipe GzipFile into subprocess https://bugs.python.org/issue40885 opened by Nehal Patel #40886: Add PYTHONLOGGING environment variable and -L cmdline argument https://bugs.python.org/issue40886 opened by bar.harel #40891: Use pep573 in functools https://bugs.python.org/issue40891 opened by shihai1991 #40892: IDLE: use rlcompleter suffixed for completions https://bugs.python.org/issue40892 opened by terry.reedy #40893: tkinter integrate TkDND support https://bugs.python.org/issue40893 opened by epaine #40894: asyncio.gather() cancelled() always False https://bugs.python.org/issue40894 opened by timmwagener #40896: Missing links to Source Code in Documentation pages https://bugs.python.org/issue40896 opened by edison.abahurire #40897: Inheriting from class that defines __new__ causes inspect.sign https://bugs.python.org/issue40897 opened by ezyang #40899: Document exceptions raised by importlib.import https://bugs.python.org/issue40899 opened by j13r #40900: uuid module build fix on FreeBSD proposal https://bugs.python.org/issue40900 opened by devnexen #40901: It's not clear what "interface name" means in socket if_namein https://bugs.python.org/issue40901 opened by jstasiak #40905: IDLE relabel Save on close https://bugs.python.org/issue40905 opened by terry.reedy #40906: Unable to import module due to python unable to resolve depend https://bugs.python.org/issue40906 opened by sabakauser #40912: _PyOS_SigintEvent is never closed on Windows https://bugs.python.org/issue40912 opened by steve.dower #40913: time.sleep ignores errors on Windows https://bugs.python.org/issue40913 opened by steve.dower #40914: tarfile creates output that appears to omit files https://bugs.python.org/issue40914 opened by mcr314 #40915: multiple problems with mmap.resize() in Windows https://bugs.python.org/issue40915 opened by eryksun #40916: Proposed tweak to allow for per-task async generator semantics https://bugs.python.org/issue40916 opened by Joshua Oreman #40923: Thread safety : disable intel’s compiler autopar where it� https://bugs.python.org/issue40923 opened by Laël Cellier #40924: Recent importlib change breaks most recent certifi == 2020.4.5 https://bugs.python.org/issue40924 opened by ned.deily #40925: Remove redundant macros used for stack manipulation in interpr https://bugs.python.org/issue40925 opened by Mark.Shannon #40926: command line interface of symtable module is broken https://bugs.python.org/issue40926 opened by BTaskaya #40927: ./python -m test test___all__ test_binhex fails https://bugs.python.org/issue40927 opened by remi.lapeyre #40928: OS X: malloc(): set default diagnostics to DEBUG_WRITE_ON_CRAS https://bugs.python.org/issue40928 opened by remi.lapeyre #40930: zoneinfo gives incorrect dst() in Pacific/Rarotonga between 19 https://bugs.python.org/issue40930 opened by p-ganssle #40931: zoneinfo gives incorrect dst() in Europe/Madrid in 1938 https://bugs.python.org/issue40931 opened by p-ganssle #40932: subprocess docs should warn of shlex use on Windows https://bugs.python.org/issue40932 opened by Stephen Farris #40933: zoneinfo may give incorrect dst() in Europe/Minsk in 1942 https://bugs.python.org/issue40933 opened by p-ganssle #40934: Default RLock does not work well for Manager Condition https://bugs.python.org/issue40934 opened by Misko Dzamba #40935: Links to Python3 docs for some libs return 404 https://bugs.python.org/issue40935 opened by edison.abahurire #40936: Remove deprecated functions from gettext https://bugs.python.org/issue40936 opened by remi.lapeyre #40937: Remove deprecated functions marked for removal in 3.10 https://bugs.python.org/issue40937 opened by remi.lapeyre #40938: urllib.parse.urlunsplit makes relative path to absolute (http: https://bugs.python.org/issue40938 opened by op368 #40939: Remove the old parser https://bugs.python.org/issue40939 opened by pablogsal #40941: Merge generator.gi_running and frame executing flag into singl https://bugs.python.org/issue40941 opened by Mark.Shannon #40942: BaseManager cannot start with local manager https://bugs.python.org/issue40942 opened by Mike Jarvis #40943: PEP 353: Drop support for PyArg_ParseTuple() "#" formats when https://bugs.python.org/issue40943 opened by vstinner #40944: email.message.EmailMessage address parser fails to handle 'exa https://bugs.python.org/issue40944 opened by Ivan Savin #40945: TKinter.Tk.geometry(Tk.winfo_geometry()) should be idempotent https://bugs.python.org/issue40945 opened by Ben Li-Sauerwine #40946: SuppressCrashReport should set SEM_FAILCRITICALERRORS in Windo https://bugs.python.org/issue40946 opened by eryksun #40948: Better identify Windows installer as installer only, not runne https://bugs.python.org/issue40948 opened by terry.reedy #40949: test_socket: threading_cleanup() failed to cleanup 0 threads ( https://bugs.python.org/issue40949 opened by vstinner #40951: csv skipinitialspace no longer working https://bugs.python.org/issue40951 opened by Rudolfo Munguia #40952: GCC overflow warnings (format-overflow, stringop-overflow) https://bugs.python.org/issue40952 opened by christian.heimes #40953: _PyWideStringList_Copy breaks asan builds https://bugs.python.org/issue40953 opened by christian.heimes #40954: freeze.py aborts on macOS https://bugs.python.org/issue40954 opened by 小本健司 #40956: Use Argument Clinic in sqlite3 https://bugs.python.org/issue40956 opened by erlendaasland #40957: _Py_fopen_obj leaks reference on audit error https://bugs.python.org/issue40957 opened by christian.heimes #40958: ASAN/UBSAN: heap-buffer-overflow in pegen.c https://bugs.python.org/issue40958 opened by christian.heimes #40959: Remove unused and unneeded function declaration from sqlite3 h https://bugs.python.org/issue40959 opened by erlendaasland #40961: os.putenv should be documented as not affecting os.getenv's re https://bugs.python.org/issue40961 opened by Daniel Martin #40962: Add documentation for asyncio._set_running_loop() https://bugs.python.org/issue40962 opened by eugenhu #40963: distutils make_zipfile uses random order https://bugs.python.org/issue40963 opened by ghost43 Most recent 15 issues with no replies (15) ========================================== #40963: distutils make_zipfile uses random order https://bugs.python.org/issue40963 #40962: Add documentation for asyncio._set_running_loop() https://bugs.python.org/issue40962 #40961: os.putenv should be documented as not affecting os.getenv's re https://bugs.python.org/issue40961 #40959: Remove unused and unneeded function declaration from sqlite3 h https://bugs.python.org/issue40959 #40957: _Py_fopen_obj leaks reference on audit error https://bugs.python.org/issue40957 #40956: Use Argument Clinic in sqlite3 https://bugs.python.org/issue40956 #40953: _PyWideStringList_Copy breaks asan builds https://bugs.python.org/issue40953 #40952: GCC overflow warnings (format-overflow, stringop-overflow) https://bugs.python.org/issue40952 #40951: csv skipinitialspace no longer working https://bugs.python.org/issue40951 #40949: test_socket: threading_cleanup() failed to cleanup 0 threads ( https://bugs.python.org/issue40949 #40946: SuppressCrashReport should set SEM_FAILCRITICALERRORS in Windo https://bugs.python.org/issue40946 #40944: email.message.EmailMessage address parser fails to handle 'exa https://bugs.python.org/issue40944 #40942: BaseManager cannot start with local manager https://bugs.python.org/issue40942 #40938: urllib.parse.urlunsplit makes relative path to absolute (http: https://bugs.python.org/issue40938 #40937: Remove deprecated functions marked for removal in 3.10 https://bugs.python.org/issue40937 Most recent 15 issues waiting for review (15) ============================================= #40959: Remove unused and unneeded function declaration from sqlite3 h https://bugs.python.org/issue40959 #40957: _Py_fopen_obj leaks reference on audit error https://bugs.python.org/issue40957 #40956: Use Argument Clinic in sqlite3 https://bugs.python.org/issue40956 #40944: email.message.EmailMessage address parser fails to handle 'exa https://bugs.python.org/issue40944 #40943: PEP 353: Drop support for PyArg_ParseTuple() "#" formats when https://bugs.python.org/issue40943 #40941: Merge generator.gi_running and frame executing flag into singl https://bugs.python.org/issue40941 #40939: Remove the old parser https://bugs.python.org/issue40939 #40937: Remove deprecated functions marked for removal in 3.10 https://bugs.python.org/issue40937 #40936: Remove deprecated functions from gettext https://bugs.python.org/issue40936 #40927: ./python -m test test___all__ test_binhex fails https://bugs.python.org/issue40927 #40926: command line interface of symtable module is broken https://bugs.python.org/issue40926 #40925: Remove redundant macros used for stack manipulation in interpr https://bugs.python.org/issue40925 #40924: Recent importlib change breaks most recent certifi == 2020.4.5 https://bugs.python.org/issue40924 #40901: It's not clear what "interface name" means in socket if_namein https://bugs.python.org/issue40901 #40894: asyncio.gather() cancelled() always False https://bugs.python.org/issue40894 Top 10 most discussed issues (10) ================================= #40958: ASAN/UBSAN: heap-buffer-overflow in pegen.c https://bugs.python.org/issue40958 28 msgs #40928: OS X: malloc(): set default diagnostics to DEBUG_WRITE_ON_CRAS https://bugs.python.org/issue40928 22 msgs #40939: Remove the old parser https://bugs.python.org/issue40939 19 msgs #39791: New `files()` api from importlib_resources. https://bugs.python.org/issue39791 11 msgs #40924: Recent importlib change breaks most recent certifi == 2020.4.5 https://bugs.python.org/issue40924 9 msgs #17013: Allow waiting on a mock https://bugs.python.org/issue17013 8 msgs #40275: test.support has way too many imports https://bugs.python.org/issue40275 8 msgs #40923: Thread safety : disable intel’s compiler autopar where it� https://bugs.python.org/issue40923 8 msgs #23427: Add sys.orig_argv: original command line arguments passed to t https://bugs.python.org/issue23427 6 msgs #40065: py39: remove deprecation note for xml.etree.cElementTree https://bugs.python.org/issue40065 6 msgs Issues closed (71) ================== #6171: IDLE - TreeWidget draw and double-click (Ubuntu) https://bugs.python.org/issue6171 closed by terry.reedy #7949: IDLE: avoid no-contrast popups and dialogs. https://bugs.python.org/issue7949 closed by terry.reedy #13504: Meta-issue for "Invent with Python" IDLE feedback https://bugs.python.org/issue13504 closed by terry.reedy #14304: Implement utf-8-bmp codec https://bugs.python.org/issue14304 closed by terry.reedy #16123: IDLE - deprecate running without a subprocess https://bugs.python.org/issue16123 closed by terry.reedy #17737: test_gdb fails on armv7hl https://bugs.python.org/issue17737 closed by vstinner #18330: Fix idlelib.PyShell.build_subprocess_arglist use of __import_ https://bugs.python.org/issue18330 closed by terry.reedy #18822: poor proxyval() coverage in test_gdb https://bugs.python.org/issue18822 closed by vstinner #19042: Idle: run from editor without explicit save https://bugs.python.org/issue19042 closed by terry.reedy #19468: Relax the type restriction on reloaded modules https://bugs.python.org/issue19468 closed by brett.cannon #20403: Idle options dialog: add help https://bugs.python.org/issue20403 closed by terry.reedy #22209: Idle: add better access to extension information https://bugs.python.org/issue22209 closed by terry.reedy #22554: Idle: optionally auto-pop-up completion window for names https://bugs.python.org/issue22554 closed by terry.reedy #24860: Can IDLE's query box be improved https://bugs.python.org/issue24860 closed by terry.reedy #24914: Python: Not just OO style but this is not mentioned on python. https://bugs.python.org/issue24914 closed by brett.cannon #25352: Add 'make this my default python' to windows installs for Pyth https://bugs.python.org/issue25352 closed by terry.reedy #26788: test_gdb fails all tests on a profile-opt build configured --w https://bugs.python.org/issue26788 closed by vstinner #27732: IDLE tests should be quiet https://bugs.python.org/issue27732 closed by terry.reedy #27965: Automatic .py extension when saving with IDLE on OSX https://bugs.python.org/issue27965 closed by terry.reedy #28068: Error in freeze.py due to unguarded sys.abiflags usage under W https://bugs.python.org/issue28068 closed by ned.deily #29242: Crash on GC when compiling PyPy https://bugs.python.org/issue29242 closed by ned.deily #29620: unittest.TestCase.assertWarns raises RuntimeEror if sys.module https://bugs.python.org/issue29620 closed by akuchling #29633: MSI installer does not pass values as SecureProperty from UI https://bugs.python.org/issue29633 closed by steve.dower #29685: test_gdb failed https://bugs.python.org/issue29685 closed by vstinner #29857: Provide `sys.executable_argv` for host application's command l https://bugs.python.org/issue29857 closed by vstinner #32834: test_gdb fails with Posix locale in 3.7 https://bugs.python.org/issue32834 closed by vstinner #34023: timedelta(seconds=x) strange results when type(x) == np.int32 https://bugs.python.org/issue34023 closed by inada.naoki #34401: Make test_gdb work on HP-UX https://bugs.python.org/issue34401 closed by vstinner #35885: configparser: indentation https://bugs.python.org/issue35885 closed by lukasz.langa #38160: [subinterpreters] Add a "PyInterpreterState *" field to PyType https://bugs.python.org/issue38160 closed by vstinner #40614: ast.parse doesn't respect feature_version for debug f-strings https://bugs.python.org/issue40614 closed by lys.nikolaou #40626: application/x-hdf5 mime type missing from mimetypes library https://bugs.python.org/issue40626 closed by akuchling #40684: make install doesn't respect configure --with-platlibdir=lib64 https://bugs.python.org/issue40684 closed by vstinner #40724: Support buffer protocol with type specs https://bugs.python.org/issue40724 closed by scoder #40743: [CMake] It's 2020, where is CMake? https://bugs.python.org/issue40743 closed by ned.deily #40802: AbstractEventLoop.shutdown_default_executor breaks backwards c https://bugs.python.org/issue40802 closed by yselivanov #40807: Codeop: Show warnings once during _maybe_compile https://bugs.python.org/issue40807 closed by terry.reedy #40830: Certain uses of dictionary unpacking raise TypeError https://bugs.python.org/issue40830 closed by pablogsal #40847: New parser considers empty line following a backslash to be a https://bugs.python.org/issue40847 closed by pablogsal #40854: Allow overriding sys.platlibdir: add PYTHONPLATLIBDIR env var https://bugs.python.org/issue40854 closed by vstinner #40861: On Windows, liblzma is always built without optimization https://bugs.python.org/issue40861 closed by steve.dower #40862: argparse.BooleanOptionalAction accept and silently discard its https://bugs.python.org/issue40862 closed by rhettinger #40867: Remove unused include in Module/_randommodule.c https://bugs.python.org/issue40867 closed by rhettinger #40870: Custom AST can crash Python (debug build) https://bugs.python.org/issue40870 closed by pablogsal #40876: Clarify error message in csv module https://bugs.python.org/issue40876 closed by nanjekyejoannah #40879: Strange regex cycle https://bugs.python.org/issue40879 closed by tim.peters #40880: Invalid read in pegen.c https://bugs.python.org/issue40880 closed by pablogsal #40881: --with-valgrind broken https://bugs.python.org/issue40881 closed by vstinner #40883: parse_string.c: free "str" https://bugs.python.org/issue40883 closed by pablogsal #40887: Free lists are still used after being finalized (cleared) https://bugs.python.org/issue40887 closed by vstinner #40888: Add close method to queue https://bugs.python.org/issue40888 closed by rhettinger #40889: Symmetric difference on dict_views is inefficient https://bugs.python.org/issue40889 closed by inada.naoki #40890: Dict views should be introspectable https://bugs.python.org/issue40890 closed by rhettinger #40895: weakref documentation contains cautions about dictionary mutat https://bugs.python.org/issue40895 closed by pitrou #40898: Remove redundant if statements in tp_traverse https://bugs.python.org/issue40898 closed by inada.naoki #40902: Speed up PEG parser by using operator precedence for binary op https://bugs.python.org/issue40902 closed by pablogsal #40903: Segfault in new PEG parser https://bugs.python.org/issue40903 closed by pablogsal #40904: Segfault from new PEG parser handling yield withing f-strings https://bugs.python.org/issue40904 closed by pablogsal #40907: cpython/lib/queue.py: put() does not acquire not_empty before https://bugs.python.org/issue40907 closed by r n2 #40908: datetime strftime with %Y and 2 digit years https://bugs.python.org/issue40908 closed by p-ganssle #40909: unittest assertCountEqual doesn't filter on values in dict https://bugs.python.org/issue40909 closed by steven.daprano #40910: Py_GetArgcArgv() is no longer exported by the C API https://bugs.python.org/issue40910 closed by vstinner #40911: Unexpected behaviour for += assignment to list inside tuple https://bugs.python.org/issue40911 closed by steven.daprano #40917: pickle exceptions with mandatory keyword args will traceback https://bugs.python.org/issue40917 closed by a.badger #40929: Multiprocessing. Instance of the custom class is missing in su https://bugs.python.org/issue40929 closed by cyberlis #40940: How to update pip permanently for new venv? https://bugs.python.org/issue40940 closed by ned.deily #40947: Replace PLATLIBDIR macro with config->platlibdir https://bugs.python.org/issue40947 closed by vstinner #40950: PEP 3121 applied to nis module https://bugs.python.org/issue40950 closed by corona10 #40955: subprocess_fork_exec leaks memory when extra_groups are suppli https://bugs.python.org/issue40955 closed by christian.heimes #40960: Fix the example in hashlib documentarion https://bugs.python.org/issue40960 closed by cheryl.sabella #1074333: On linux, numeric pad input is ignored when numlock off https://bugs.python.org/issue1074333 closed by terry.reedy

1 0

[RELEASE] Python 3.9.0b3 is now available for testing
by Łukasz Langa June 9, 2020

June 9, 2020

On behalf of the entire Python development community, and the currently serving Python release team in particular, I’m pleased to announce the release of Python 3.9.0b3. Get it here: https://www.python.org/downloads/release/python-390b3/ <https://www.python.org/downloads/release/python-390b3/> Wait, Beta 3? What happened to Beta 2? Beta 2? Speak of him no more. We disappeared him. He was a bad release. Truly awful. I get shivers just thinking about it. Never mention that name again in this house. I mean, long story short, in Beta 2 you couldn’t do urllib.request.urlopen("https://www.python.org").read() because it wouldn’t find root certificates due to a bug <https://bugs.python.org/issue40924>. Since this was a problem only apparent on an installed Python, it wasn’t identified by unit tests and was only found by Ned while he was testing his Mac installer. By the time we learned of the severity of the bug I already tagged and published the release on python.org <http://python.org/>. That’s why we couldn’t just re-do the release under the same version. Sorry for the trouble. We’re tweaking our release process to catch this problem sooner in future releases. Now, back to regular programming… This is a beta preview of Python 3.9 Python 3.9 is still in development. This release, 3.9.0b3, is the third of five planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. Call to action We strongly encourage maintainers of third-party Python projects to test with 3.9 during the beta phase and report issues found to the Python bug tracker <https://bugs.python.org/> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2020-08-10). Our goal is have no ABI changes after beta 5 and as few code changes as possible after 3.9.0rc1, the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.9 as possible during the beta phase. Please keep in mind that this is a preview release and its use is not recommended for production environments. Major new features of the 3.9 series, compared to 3.8 Some of the new major new features and changes in Python 3.9 are: PEP 584 <https://www.python.org/dev/peps/pep-0584/>, Union Operators in dict PEP 585 <https://www.python.org/dev/peps/pep-0585/>, Type Hinting Generics In Standard Collections PEP 593 <https://www.python.org/dev/peps/pep-0593/>, Flexible function and variable annotations PEP 602 <https://www.python.org/dev/peps/pep-0602/>, Python adopts a stable annual release cadence PEP 616 <https://www.python.org/dev/peps/pep-0616/>, String methods to remove prefixes and suffixes PEP 617 <https://www.python.org/dev/peps/pep-0617/>, New PEG parser for CPython BPO 38379 <https://bugs.python.org/issue38379>, garbage collection does not block on resurrected objects; BPO 38692 <https://bugs.python.org/issue38692>, os.pidfd_open added that allows process management without races and signals; BPO 39926 <https://bugs.python.org/issue39926>, Unicode support updated to version 13.0.0; BPO 1635741 <https://bugs.python.org/issue1635741>, when Python is initialized multiple times in the same process, it does not leak memory anymore; A number of Python builtins (range, tuple, set, frozenset, list, dict) are now sped up using PEP 590 <https://www.python.org/dev/peps/pep-0590> vectorcall; A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, _functools, _json, _locale, operator, resource, time, _weakref) now use multiphase initialization as defined by PEP 489 <https://www.python.org/dev/peps/pep-0489/>; A number of standard library modules (audioop, ast, grp, _hashlib, pwd, _posixsubprocess, random, select, struct, termios, zlib) are now using the stable ABI defined by PEP 384 <https://www.python.org/dev/peps/pep-0384/>. (Hey, fellow core developer, if a feature you find important is missing from this list, let Łukasz know <mailto:lukasz@python.org>.) The next pre-release, the fourth beta release of Python 3.9, will be 3.9.0b4. It is currently scheduled for 2020-06-29. More resources Online Documentation <https://docs.python.org/3.9/> PEP 596 <https://www.python.org/dev/peps/pep-0596/>, 3.9 Release Schedule Report bugs at https://bugs.python.org <https://bugs.python.org/>. Help fund Python and its community <https://discuss.python.org/psf/donations/>. Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>

2 1

Making asyncio more thread-friendly
by Celelibi June 6, 2020

June 6, 2020

Hello world, I always knew asynchronous programming is awesome. And having a language support for it really help its adoption by limiting the existence of incompatible event frameworks which would be a pain to use together. However, the asynchronousness is very contaminating. This makes it difficult to make threads and asyncio coexist in a single application as a transition period while the thread model is replaced with the async one. And a smooth transition is of course needed because a series of smaller changes that are separately testable for correctness is a lot easier to develop that one large chunk of rewrite. Unless I'm mistaken, there's no obvious way to have a function run a coroutine in a given event loop, no matter if the loop in running or not, no matter if it's running in the current context or not. There are at least 3 cases that I can see: 1) The loop isn't running -> run_until_complete is the solution. 2) The loop is running in another context -> we might use call_soon_threadsafe and wait for the result. 3) The loop is running in the current context but we're not in a coroutine -> there's currently not much we can do without some major code change. What I'd like to propose is that run_until_complete handle all three cases. Including the third, which imply that the event loop could be run recursively. I also found out that the loop argument to most standard asyncio classes has been deprecated. I think it's pretty crazy as it prevent objects from being instanciated in one thread and used in another. Which would again imply significant code change in one single go for applications trying to switch from threads to asyncio. Did I miss an obvious way to make the migration from threads to asyncio easier? It becomes harder and harder to not believe that python is purposfully trying to make this kind of migration more painful. Best regards, Celelibi

1 0

Upcoming cutoffs for 3.9, 3.8, 3.7, and 3.6 releases! Last chance for 3.7 bugfixes!
by Ned Deily June 6, 2020

June 6, 2020

https://discuss.python.org/t/upcoming-cutoffs-for-3-9-3-8-3-7-and-3-6-relea… -- Ned Deily nad(a)python.org -- []

1 0

Summary of Python tracker Issues
by Python tracker June 5, 2020

June 5, 2020

ACTIVITY SUMMARY (2020-05-29 - 2020-06-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 7444 (-43) closed 45180 (+100) total 52624 (+57) Open issues with patches: 3008 Issues opened (49) ================== #25782: CPython hangs on error __context__ set to the error itself https://bugs.python.org/issue25782 reopened by serhiy.storchaka #37483: Add PyObject_CallOneArg() https://bugs.python.org/issue37483 reopened by vstinner #40679: show class name in method invocation TypeError https://bugs.python.org/issue40679 reopened by vstinner #40805: Can no longer patch flask.g https://bugs.python.org/issue40805 reopened by cjw296 #40821: os.getlogin() not working https://bugs.python.org/issue40821 opened by Manickaraja Kumarappan #40822: Drop support for SQLite pre 3.7.15 https://bugs.python.org/issue40822 opened by erlendaasland #40823: Don't use obsolete unittest.makeSuite() in sqlite3 tests https://bugs.python.org/issue40823 opened by erlendaasland #40824: Unexpected errors in __iter__ are masked in "in" and the opera https://bugs.python.org/issue40824 opened by serhiy.storchaka #40825: Add a "strict" parameter to csv.writer and csv.DictWriter https://bugs.python.org/issue40825 opened by eric.smith #40826: PyOS_InterruptOccurred() now requires to hold the GIL: PyOS_Re https://bugs.python.org/issue40826 opened by Jelle Zijlstra #40827: os.readlink should support getting the target's printname in W https://bugs.python.org/issue40827 opened by eryksun #40828: shared memory problems with multiprocessing.Pool https://bugs.python.org/issue40828 opened by trapezoid677 #40830: Certain uses of dictionary unpacking raise TypeError https://bugs.python.org/issue40830 opened by Kodiologist #40832: hi param in bisect module should not accept negative values https://bugs.python.org/issue40832 opened by samuel72 #40833: Clarify docstring of Path.rename https://bugs.python.org/issue40833 opened by cool-RR #40834: sending str via channel caused truncate on last character https://bugs.python.org/issue40834 opened by asaka #40835: Incorrect handling for msgctxt in msgfmt.py https://bugs.python.org/issue40835 opened by da1910 #40836: logging.fatal() and logging.Logger.fatal() should raise a Depr https://bugs.python.org/issue40836 opened by remi.lapeyre #40837: email.utils.encode_rfc2231(string, None, None) returns broken https://bugs.python.org/issue40837 opened by spaceone #40838: inspect.getsourcefile documentation doesn't mention it can ret https://bugs.python.org/issue40838 opened by pekka.klarck #40840: lzma.h file not found building on macOS https://bugs.python.org/issue40840 opened by jaraco #40841: Provide mimetypes.sniff API as stdlib https://bugs.python.org/issue40841 opened by corona10 #40842: _Pickler_CommitFrame() always returns 0 and its return code is https://bugs.python.org/issue40842 opened by remi.lapeyre #40843: tarfile: ignore_zeros = True exceedingly slow on a sparse tar https://bugs.python.org/issue40843 opened by mxmlnkn #40846: Misleading line in documentation https://bugs.python.org/issue40846 opened by J Arun Mani #40847: New parser considers empty line following a backslash to be a https://bugs.python.org/issue40847 opened by adamwill #40849: Expose X509_V_FLAG_PARTIAL_CHAIN ssl flag https://bugs.python.org/issue40849 opened by l0x #40851: subprocess.Popen: impossible to show console window when shell https://bugs.python.org/issue40851 opened by akdor1154 #40854: [Patch] Allow overriding sys.platlibdir https://bugs.python.org/issue40854 opened by smani #40855: statistics.stdev ignore xbar argument https://bugs.python.org/issue40855 opened by Folket #40856: IDLE line numbering should be light gray https://bugs.python.org/issue40856 opened by rhettinger #40857: tempfile.TemporaryDirectory() context manager can fail to prop https://bugs.python.org/issue40857 opened by granchester #40858: ntpath.realpath fails for broken symlinks with rooted target p https://bugs.python.org/issue40858 opened by eryksun #40859: Update Windows build to use xz-5.2.5 https://bugs.python.org/issue40859 opened by Ma Lin #40860: Exception in multiprocessing/context.py under load https://bugs.python.org/issue40860 opened by Arkady M #40861: On Windows, liblzma is always built without optimization https://bugs.python.org/issue40861 opened by nnemkin #40862: argparse.BooleanOptionalAction accept and silently discard its https://bugs.python.org/issue40862 opened by remi.lapeyre #40864: spec_set/autospec/spec seems to not be reading attributes defi https://bugs.python.org/issue40864 opened by efagerberg #40866: Use PyModule_AddType() in posix module initialisation https://bugs.python.org/issue40866 opened by erlendaasland #40867: Remove unused include in Module/_randommodule.c https://bugs.python.org/issue40867 opened by erlendaasland #40868: io.TextIOBase.buffer is not necessarily a buffer https://bugs.python.org/issue40868 opened by mjacob #40869: errno missing descriptions https://bugs.python.org/issue40869 opened by YoSTEALTH #40870: Custom AST can crash Python (debug build) https://bugs.python.org/issue40870 opened by BTaskaya #40871: threading.Event.wait_unset() https://bugs.python.org/issue40871 opened by Jacob Kunnappally #40872: multiprocess.Lock is missing the locked() method https://bugs.python.org/issue40872 opened by remi.lapeyre #40873: Something wrong with html.unescape() https://bugs.python.org/issue40873 opened by Валентин Dreyk #40874: Update to libmpdec-2.5.0 https://bugs.python.org/issue40874 opened by skrah #40875: Implement __repr__ for classes in csv module https://bugs.python.org/issue40875 opened by cool-RR #40876: Clarify error message in csv module https://bugs.python.org/issue40876 opened by cool-RR Most recent 15 issues with no replies (15) ========================================== #40876: Clarify error message in csv module https://bugs.python.org/issue40876 #40875: Implement __repr__ for classes in csv module https://bugs.python.org/issue40875 #40873: Something wrong with html.unescape() https://bugs.python.org/issue40873 #40872: multiprocess.Lock is missing the locked() method https://bugs.python.org/issue40872 #40871: threading.Event.wait_unset() https://bugs.python.org/issue40871 #40869: errno missing descriptions https://bugs.python.org/issue40869 #40868: io.TextIOBase.buffer is not necessarily a buffer https://bugs.python.org/issue40868 #40867: Remove unused include in Module/_randommodule.c https://bugs.python.org/issue40867 #40866: Use PyModule_AddType() in posix module initialisation https://bugs.python.org/issue40866 #40861: On Windows, liblzma is always built without optimization https://bugs.python.org/issue40861 #40859: Update Windows build to use xz-5.2.5 https://bugs.python.org/issue40859 #40858: ntpath.realpath fails for broken symlinks with rooted target p https://bugs.python.org/issue40858 #40847: New parser considers empty line following a backslash to be a https://bugs.python.org/issue40847 #40843: tarfile: ignore_zeros = True exceedingly slow on a sparse tar https://bugs.python.org/issue40843 #40842: _Pickler_CommitFrame() always returns 0 and its return code is https://bugs.python.org/issue40842 Most recent 15 issues waiting for review (15) ============================================= #40876: Clarify error message in csv module https://bugs.python.org/issue40876 #40874: Update to libmpdec-2.5.0 https://bugs.python.org/issue40874 #40872: multiprocess.Lock is missing the locked() method https://bugs.python.org/issue40872 #40870: Custom AST can crash Python (debug build) https://bugs.python.org/issue40870 #40867: Remove unused include in Module/_randommodule.c https://bugs.python.org/issue40867 #40866: Use PyModule_AddType() in posix module initialisation https://bugs.python.org/issue40866 #40862: argparse.BooleanOptionalAction accept and silently discard its https://bugs.python.org/issue40862 #40859: Update Windows build to use xz-5.2.5 https://bugs.python.org/issue40859 #40854: [Patch] Allow overriding sys.platlibdir https://bugs.python.org/issue40854 #40846: Misleading line in documentation https://bugs.python.org/issue40846 #40836: logging.fatal() and logging.Logger.fatal() should raise a Depr https://bugs.python.org/issue40836 #40835: Incorrect handling for msgctxt in msgfmt.py https://bugs.python.org/issue40835 #40834: sending str via channel caused truncate on last character https://bugs.python.org/issue40834 #40833: Clarify docstring of Path.rename https://bugs.python.org/issue40833 #40830: Certain uses of dictionary unpacking raise TypeError https://bugs.python.org/issue40830 Top 10 most discussed issues (10) ================================= #40826: PyOS_InterruptOccurred() now requires to hold the GIL: PyOS_Re https://bugs.python.org/issue40826 23 msgs #17005: Add a topological sort algorithm https://bugs.python.org/issue17005 18 msgs #40521: [subinterpreters] Make free lists and unicode caches per-inter https://bugs.python.org/issue40521 13 msgs #40825: Add a "strict" parameter to csv.writer and csv.DictWriter https://bugs.python.org/issue40825 9 msgs #40805: Can no longer patch flask.g https://bugs.python.org/issue40805 7 msgs #40807: Codeop: Show warnings once during _maybe_compile https://bugs.python.org/issue40807 7 msgs #22167: iglob() has misleading documentation (does indeed store names https://bugs.python.org/issue22167 6 msgs #27580: CSV Null Byte Error https://bugs.python.org/issue27580 6 msgs #39573: [C API] Make PyObject an opaque structure in the limited C API https://bugs.python.org/issue39573 6 msgs #40403: pdb does not drop into debugger upon SyntaxError caused by ast https://bugs.python.org/issue40403 5 msgs Issues closed (93) ================== #2481: locale.strxfrm does not work with Unicode strings https://bugs.python.org/issue2481 closed by serhiy.storchaka #5184: Add -3 warning for extension types that implement tp_compare b https://bugs.python.org/issue5184 closed by serhiy.storchaka #8387: use universal newline mode in csv module examples https://bugs.python.org/issue8387 closed by serhiy.storchaka #8502: support plurals in pygettext https://bugs.python.org/issue8502 closed by serhiy.storchaka #8893: file.{read,readlines} behaviour on Solaris https://bugs.python.org/issue8893 closed by serhiy.storchaka #9196: Improve docs for string interpolation "%s" re Unicode strings https://bugs.python.org/issue9196 closed by serhiy.storchaka #9326: Error message for incorrect number of (function) args is incor https://bugs.python.org/issue9326 closed by serhiy.storchaka #9751: _PyInstance_Lookup() defeats its purpose https://bugs.python.org/issue9751 closed by serhiy.storchaka #10631: ZipFile and current directory change https://bugs.python.org/issue10631 closed by serhiy.storchaka #11309: #include <wctype.h> in Objects/unicodetype_db.h and Objects/un https://bugs.python.org/issue11309 closed by serhiy.storchaka #11315: unicode support in Cookie module https://bugs.python.org/issue11315 closed by serhiy.storchaka #11722: mingw64 does not link when building extensions https://bugs.python.org/issue11722 closed by serhiy.storchaka #11767: Maildir iterator leaks file descriptors by default https://bugs.python.org/issue11767 closed by serhiy.storchaka #12398: Sending binary data with a POST request in httplib can cause U https://bugs.python.org/issue12398 closed by serhiy.storchaka #13171: Bug in file.read(), can access unknown data. https://bugs.python.org/issue13171 closed by serhiy.storchaka #14847: AttributeError: NoneType has no attribute 'utf_8_decode' https://bugs.python.org/issue14847 closed by serhiy.storchaka #14978: distutils Extension fails to be created with unicode package n https://bugs.python.org/issue14978 closed by serhiy.storchaka #15276: unicode format does not really work in Python 2.x https://bugs.python.org/issue15276 closed by serhiy.storchaka #15918: subprocess.Popen reads errpipe_read incorrectly, can result in https://bugs.python.org/issue15918 closed by serhiy.storchaka #15951: string.Formatter returns str for empty unicode template https://bugs.python.org/issue15951 closed by serhiy.storchaka #15952: format(value) and value.__format__() behave differently with u https://bugs.python.org/issue15952 closed by serhiy.storchaka #16125: open accepts arbitrary mode strings as long as they contain U https://bugs.python.org/issue16125 closed by serhiy.storchaka #16891: Fix docs about module search order https://bugs.python.org/issue16891 closed by serhiy.storchaka #17112: Some doctest-based tests fail when run with python -OO https://bugs.python.org/issue17112 closed by serhiy.storchaka #17191: pdb list shows unexpected code when stack frame includes a try https://bugs.python.org/issue17191 closed by serhiy.storchaka #17387: Error in C API documentation of PySequenceMethods https://bugs.python.org/issue17387 closed by serhiy.storchaka #17420: bdist_wininst does not play well with unicode descriptions https://bugs.python.org/issue17420 closed by serhiy.storchaka #17544: regex code re-raises exceptions on success https://bugs.python.org/issue17544 closed by serhiy.storchaka #18695: os.statvfs() not working well with unicode paths https://bugs.python.org/issue18695 closed by serhiy.storchaka #20192: pprint chokes on set containing frozenset https://bugs.python.org/issue20192 closed by serhiy.storchaka #20296: PyArg_ParseTuple 2.X docs mention int for "t#", but "Py_ssize_ https://bugs.python.org/issue20296 closed by serhiy.storchaka #20686: Confusing statement about unicode strings in tutorial introduc https://bugs.python.org/issue20686 closed by serhiy.storchaka #20785: Missing symbols in Python27.lib (Windows 64bit) https://bugs.python.org/issue20785 closed by serhiy.storchaka #20989: XML File I/O Misbehavior with open() when the flag is 'r+' https://bugs.python.org/issue20989 closed by serhiy.storchaka #21547: '!s' formatting documentation bug https://bugs.python.org/issue21547 closed by serhiy.storchaka #21561: help() on enum34 enumeration class creates only a dummy docume https://bugs.python.org/issue21561 closed by serhiy.storchaka #21785: __getitem__ and __setitem__ try to be smart when invoked with https://bugs.python.org/issue21785 closed by serhiy.storchaka #21796: tempfile.py", line 83, in <module> once_lock = _allocate_lock( https://bugs.python.org/issue21796 closed by serhiy.storchaka #21889: https://docs.python.org/2/library/multiprocessing.html#process https://bugs.python.org/issue21889 closed by serhiy.storchaka #21929: Rounding properly https://bugs.python.org/issue21929 closed by serhiy.storchaka #22052: Comparison operators called in reverse order for subclasses wi https://bugs.python.org/issue22052 closed by serhiy.storchaka #22666: email.Header no encoding of unicode strings containing newline https://bugs.python.org/issue22666 closed by serhiy.storchaka #22720: Obscure error w/ windows online-only file https://bugs.python.org/issue22720 closed by serhiy.storchaka #22750: xmlapp.py display bug when validate XML by DTD https://bugs.python.org/issue22750 closed by serhiy.storchaka #23315: tempfile.mkdtemp fails with non-ascii paths on Python 2 https://bugs.python.org/issue23315 closed by serhiy.storchaka #23514: multiprocessing documentation - little more examples for paral https://bugs.python.org/issue23514 closed by serhiy.storchaka #23567: os.stat() tuple access vs named attribute access int vs float https://bugs.python.org/issue23567 closed by serhiy.storchaka #23850: Missing documentation for Py_TPFLAGS_HAVE_NEWBUFFER https://bugs.python.org/issue23850 closed by serhiy.storchaka #24126: newlines attribute does not get set after calling readline() https://bugs.python.org/issue24126 closed by serhiy.storchaka #24256: threading.Timer is not a class https://bugs.python.org/issue24256 closed by serhiy.storchaka #24341: Test suite emits many DeprecationWarnings about sys.exc_clear( https://bugs.python.org/issue24341 closed by serhiy.storchaka #24880: ctypeslib patch for regular expression for symbols to include https://bugs.python.org/issue24880 closed by serhiy.storchaka #25511: multiprocessing pool blocks SIGTERM from being handled https://bugs.python.org/issue25511 closed by serhiy.storchaka #25661: tokenize.untokenize does not maintain the order of tabbed inde https://bugs.python.org/issue25661 closed by serhiy.storchaka #25714: Consider isinstance(..., numbers.Integral) instead of isinstan https://bugs.python.org/issue25714 closed by serhiy.storchaka #26369: unicode.decode and str.encode are unnecessarily confusing for https://bugs.python.org/issue26369 closed by serhiy.storchaka #26433: urllib.urlencode() does not explain how to handle unicode https://bugs.python.org/issue26433 closed by serhiy.storchaka #26543: [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode https://bugs.python.org/issue26543 closed by vstinner #27037: Universal newline support for zipFile.ZipExtFile.read() is not https://bugs.python.org/issue27037 closed by serhiy.storchaka #28403: Porting guide: disabling & warning on implicit unicode convers https://bugs.python.org/issue28403 closed by serhiy.storchaka #29017: Docs: PySide is provided by 'The Qt Company' and not by 'Nokia https://bugs.python.org/issue29017 closed by benjamin.peterson #29236: 'an ASCII string of one or more PEM-encoded certificates' need https://bugs.python.org/issue29236 closed by serhiy.storchaka #29323: Wrong documentation (Library) for unicode and str comparison https://bugs.python.org/issue29323 closed by serhiy.storchaka #31869: commentary on ssl.PROTOCOL_TLS https://bugs.python.org/issue31869 closed by christian.heimes #33491: mistype of method's name https://bugs.python.org/issue33491 closed by serhiy.storchaka #33618: Support TLS 1.3 https://bugs.python.org/issue33618 closed by christian.heimes #33725: Python crashes on macOS after fork with no exec https://bugs.python.org/issue33725 closed by barry #33740: PyByteArray_AsString C-API description lacks the assurance, th https://bugs.python.org/issue33740 closed by serhiy.storchaka #35151: Python 2 xml.etree.ElementTree documentation tutorial uses und https://bugs.python.org/issue35151 closed by serhiy.storchaka #36724: Clear _PyRuntime at exit https://bugs.python.org/issue36724 closed by vstinner #39583: Remove superfluous "extern C" bits from Include/cpython/*.h https://bugs.python.org/issue39583 closed by vstinner #39593: ctypes s_set() uses strlen() and so truncates string at null c https://bugs.python.org/issue39593 closed by vstinner #40061: Possible refleak in _asynciomodule.c future_add_done_callback( https://bugs.python.org/issue40061 closed by aeros #40244: AIX: build: _PyObject_GC_TRACK Asstertion failure https://bugs.python.org/issue40244 closed by vstinner #40759: Deprecate the symbol module https://bugs.python.org/issue40759 closed by BTaskaya #40762: Writing bytes using CSV module results in b prefixed strings https://bugs.python.org/issue40762 closed by terry.reedy #40767: Allow pure Wayland to get default XDG webbrowser https://bugs.python.org/issue40767 closed by orsenthil #40788: Build issue Solaris 10 Sparc https://bugs.python.org/issue40788 closed by munocat #40798: The deprecated-removed Sphinx extension need to change the err https://bugs.python.org/issue40798 closed by mdk #40829: Add a what's new entry about deprecation of random.shuffle's r https://bugs.python.org/issue40829 closed by BTaskaya #40831: Wrong statement that bytes paths are deprecated under Windows https://bugs.python.org/issue40831 closed by steve.dower #40839: Disallow calling PyDict_GetItem() with the GIL released https://bugs.python.org/issue40839 closed by vstinner #40844: Alternate ways of running coroutines https://bugs.python.org/issue40844 closed by yselivanov #40845: idna encoding fails for Cherokee symbols https://bugs.python.org/issue40845 closed by christian.heimes #40848: compile() can compile a bare starred expression with `PyCF_ONL https://bugs.python.org/issue40848 closed by pablogsal #40850: Programming FAQ - variables local to the lambdas https://bugs.python.org/issue40850 closed by rhettinger #40852: Dictionary created with dict.fromkeys have issues (all explain https://bugs.python.org/issue40852 closed by christian.heimes #40853: "set() in set()" should raise TypeError: unhashable type: 'set https://bugs.python.org/issue40853 closed by rhettinger #40863: bytes.decode changes/destroys line endings on windows https://bugs.python.org/issue40863 closed by eryksun #40865: Remove unused insint() macro from the hash modules https://bugs.python.org/issue40865 closed by christian.heimes #40877: Code coverage is blocking a merge again https://bugs.python.org/issue40877 closed by skrah #1294232: Error in metaclass search order https://bugs.python.org/issue1294232 closed by serhiy.storchaka #1706039: Added clearerr() to clear EOF state https://bugs.python.org/issue1706039 closed by serhiy.storchaka

1 0

Can we stop adding to the C API, please?
by Mark Shannon June 5, 2020

June 5, 2020

Hi, The size of the C API, as measured by `git grep PyAPI_FUNC | wc -l` has been steadily increasing over the last few releases. 3.5 1237 3.6 1304 3.7 1408 3.8 1478 3.9 1518 For reference the 2.7 branch has "only" 973 functions I've heard many criticisms of Python 2 over the years, but that it needed a bigger C API wasn't one of them ;) Why are these functions being added? Wasn't 1000 C functions enough? Every one of these functions represents a maintenance burden. Removing them is painful and takes a lot of effort, but adding them is done casually, without a PEP or, in many cases, even a review. We need to address what to do about the C API in the long term, but for now can we just stop making it larger? Please. Also, can we remove all the new API functions added in 3.9 before the release and it is too late? Cheers, Mark.

9 12

Summary of Python tracker Issues
by Python tracker June 5, 2020

June 5, 2020

ACTIVITY SUMMARY (2020-05-22 - 2020-05-29) 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 7487 ( +9) closed 45080 (+80) total 52567 (+89) Open issues with patches: 3011 Issues opened (58) ================== #39343: Travis CI: documentation job fails in library/nntplib.rst with https://bugs.python.org/issue39343 reopened by chris.jerdonek #40133: Provide additional matchers for unittest.mock https://bugs.python.org/issue40133 reopened by gregory.p.smith #40733: Make IDLE doc more visible, mention in main python docs page https://bugs.python.org/issue40733 opened by phr #40734: /usr/bin surprisingly in sys.path under IDLE https://bugs.python.org/issue40734 opened by phr #40735: test_nntplib: sporadic failures, NetworkedNNTP_SSLTests.test_w https://bugs.python.org/issue40735 opened by chris.jerdonek #40736: better message for re.search TypeError ("expected string or by https://bugs.python.org/issue40736 opened by chris.jerdonek #40739: find_library broken for binutils >= 2.32 / 2.34 https://bugs.python.org/issue40739 opened by Frederik Rietdijk #40741: Upgrade to SQLite v3.32.1 in Windows and macOS builds https://bugs.python.org/issue40741 opened by erlendaasland #40742: Doc: Parallel build break audit table https://bugs.python.org/issue40742 opened by mdk #40743: [CMake] It's 2020, where is CMake? https://bugs.python.org/issue40743 opened by TheUltimatePineapple #40744: Explicitly drop support for SQLite version < 3.7.3 https://bugs.python.org/issue40744 opened by erlendaasland #40745: Typo in library/typing https://bugs.python.org/issue40745 opened by hectorcanto #40746: test_gdb failing on Raspbian on 3.9, regression from 3.8 https://bugs.python.org/issue40746 opened by gregory.p.smith #40747: sysconfig.get_config_var("py_version_nodot") should return 3_1 https://bugs.python.org/issue40747 opened by mattip #40748: Tutorial 4.7 More on Defining Functions missing screen prompts https://bugs.python.org/issue40748 opened by Chas Belov #40749: Consider adding decorator for required inner class https://bugs.python.org/issue40749 opened by Elijah Rippeth #40754: ModuleNotFoundError: No module named '_testinternalcapi' under https://bugs.python.org/issue40754 opened by honglei.jiang #40756: Second argument of LoggerAdapter.__init__ should default to No https://bugs.python.org/issue40756 opened by arturoescaip #40757: tarfile: ignore_zeros = True won't raise exception even on inv https://bugs.python.org/issue40757 opened by mxmlnkn #40758: For 7.2.7. Code Examples, distinguish between the Tutorial and https://bugs.python.org/issue40758 opened by Chas Belov #40759: Deprecate the symbol module https://bugs.python.org/issue40759 opened by BTaskaya #40762: Writing bytes using CSV module results in b prefixed strings https://bugs.python.org/issue40762 opened by sidhant #40763: zipfile.extractall is safe by now https://bugs.python.org/issue40763 opened by VA #40766: Add support for SQLITE_DIRECTONLY and SQLITE_INNOCUOUS for use https://bugs.python.org/issue40766 opened by erlendaasland #40767: Allow pure Wayland to get default XDG webbrowser https://bugs.python.org/issue40767 opened by Jeremy Attali #40769: Pegen: cover extra surrounding parentheses for invalid annotat https://bugs.python.org/issue40769 opened by BTaskaya #40770: RFE: Run linkchecker on documentation on the CI https://bugs.python.org/issue40770 opened by hroncok #40771: python3 fromtimestamp generates OSError https://bugs.python.org/issue40771 opened by jamercee #40772: module 'resource' has no attribute 'RLIMIT_VMEM' https://bugs.python.org/issue40772 opened by Titusz Ban #40773: DOC: Fix rendering for 'retval' on the pdb page https://bugs.python.org/issue40773 opened by cheryl.sabella #40775: Fix missing dot in sqlite3 Node type name https://bugs.python.org/issue40775 opened by erlendaasland #40777: _datetimemodule.c:3328:16: error: initializer element is not c https://bugs.python.org/issue40777 opened by smani #40782: AbstactEventLoop.run_in_executor is listed as an async method, https://bugs.python.org/issue40782 opened by jamesba #40785: `mmap.mmap(..., 0)` doesn't work as advertised in docs (fails https://bugs.python.org/issue40785 opened by ngie #40786: madvise should be accessible outside of mmap instance https://bugs.python.org/issue40786 opened by ngie #40788: Build issue Solaris 10 Sparc https://bugs.python.org/issue40788 opened by munocat #40791: hmac.compare_digest could try harder to be constant-time. https://bugs.python.org/issue40791 opened by Devin Jeanpierre #40794: dataclass signatures and docstrings w/future-annotations https://bugs.python.org/issue40794 opened by BTaskaya #40797: multiprocessing.Semaphore has undocumented get_value() method https://bugs.python.org/issue40797 opened by remi.lapeyre #40798: The deprecated-removed Sphinx extension need to change the err https://bugs.python.org/issue40798 opened by remi.lapeyre #40799: Create Lib/_pydatetime.py file to optimize "import datetime" w https://bugs.python.org/issue40799 opened by vstinner #40800: asyncio.sleep(0) should "yield" back to the event loop, but it https://bugs.python.org/issue40800 opened by Davy Durham #40801: Expose PyFloat_AsDouble at Python level: operator.as_float? https://bugs.python.org/issue40801 opened by mark.dickinson #40802: AbstractEventLoop.shutdown_default_executor breaks backwards c https://bugs.python.org/issue40802 opened by petr.viktorin #40804: Bug report in python3.6.8 using argparse module https://bugs.python.org/issue40804 opened by amansi26 #40805: Can no longer patch flask.g https://bugs.python.org/issue40805 opened by Rob Taft #40807: CODEOP: Show warnings once during _maybe_compile https://bugs.python.org/issue40807 opened by cheryl.sabella #40808: test_venv fails with HOME=/ on AMD64 FreeBSD Non-Debug 3.x https://bugs.python.org/issue40808 opened by vstinner #40810: sqlite3 test CheckTraceCallbackContent fails for sqlite v3.7.3 https://bugs.python.org/issue40810 opened by erlendaasland #40811: Allow to create new Event Loops on Threads https://bugs.python.org/issue40811 opened by Christian Exposito #40813: Output SyntaxError is not defective https://bugs.python.org/issue40813 opened by timofej #40814: Update typing module documentation based on PEP 585 https://bugs.python.org/issue40814 opened by Matúš Valo #40815: Multiprocessing docs don't describe thread-safety https://bugs.python.org/issue40815 opened by bjs #40816: Add missed AsyncContextDecorator to contextlib https://bugs.python.org/issue40816 opened by heckad #40817: Document the asyncio shell https://bugs.python.org/issue40817 opened by remi.lapeyre #40818: Run sys.__interactivehook__ for asyncio REPLs https://bugs.python.org/issue40818 opened by remi.lapeyre #40819: Idle Context Menu Copy/Cut Grayed Out https://bugs.python.org/issue40819 opened by BevInTX #40820: Mock Call attributes args and kwargs have no changeversion https://bugs.python.org/issue40820 opened by Andrius Gobis Most recent 15 issues with no replies (15) ========================================== #40820: Mock Call attributes args and kwargs have no changeversion https://bugs.python.org/issue40820 #40819: Idle Context Menu Copy/Cut Grayed Out https://bugs.python.org/issue40819 #40818: Run sys.__interactivehook__ for asyncio REPLs https://bugs.python.org/issue40818 #40816: Add missed AsyncContextDecorator to contextlib https://bugs.python.org/issue40816 #40815: Multiprocessing docs don't describe thread-safety https://bugs.python.org/issue40815 #40814: Update typing module documentation based on PEP 585 https://bugs.python.org/issue40814 #40808: test_venv fails with HOME=/ on AMD64 FreeBSD Non-Debug 3.x https://bugs.python.org/issue40808 #40807: CODEOP: Show warnings once during _maybe_compile https://bugs.python.org/issue40807 #40805: Can no longer patch flask.g https://bugs.python.org/issue40805 #40802: AbstractEventLoop.shutdown_default_executor breaks backwards c https://bugs.python.org/issue40802 #40800: asyncio.sleep(0) should "yield" back to the event loop, but it https://bugs.python.org/issue40800 #40797: multiprocessing.Semaphore has undocumented get_value() method https://bugs.python.org/issue40797 #40788: Build issue Solaris 10 Sparc https://bugs.python.org/issue40788 #40786: madvise should be accessible outside of mmap instance https://bugs.python.org/issue40786 #40775: Fix missing dot in sqlite3 Node type name https://bugs.python.org/issue40775 Most recent 15 issues waiting for review (15) ============================================= #40818: Run sys.__interactivehook__ for asyncio REPLs https://bugs.python.org/issue40818 #40816: Add missed AsyncContextDecorator to contextlib https://bugs.python.org/issue40816 #40811: Allow to create new Event Loops on Threads https://bugs.python.org/issue40811 #40810: sqlite3 test CheckTraceCallbackContent fails for sqlite v3.7.3 https://bugs.python.org/issue40810 #40807: CODEOP: Show warnings once during _maybe_compile https://bugs.python.org/issue40807 #40801: Expose PyFloat_AsDouble at Python level: operator.as_float? https://bugs.python.org/issue40801 #40799: Create Lib/_pydatetime.py file to optimize "import datetime" w https://bugs.python.org/issue40799 #40798: The deprecated-removed Sphinx extension need to change the err https://bugs.python.org/issue40798 #40791: hmac.compare_digest could try harder to be constant-time. https://bugs.python.org/issue40791 #40777: _datetimemodule.c:3328:16: error: initializer element is not c https://bugs.python.org/issue40777 #40775: Fix missing dot in sqlite3 Node type name https://bugs.python.org/issue40775 #40769: Pegen: cover extra surrounding parentheses for invalid annotat https://bugs.python.org/issue40769 #40767: Allow pure Wayland to get default XDG webbrowser https://bugs.python.org/issue40767 #40766: Add support for SQLITE_DIRECTONLY and SQLITE_INNOCUOUS for use https://bugs.python.org/issue40766 #40762: Writing bytes using CSV module results in b prefixed strings https://bugs.python.org/issue40762 Top 10 most discussed issues (10) ================================= #40762: Writing bytes using CSV module results in b prefixed strings https://bugs.python.org/issue40762 15 msgs #30064: BaseSelectorEventLoop.sock_{recv,sendall}() don't remove their https://bugs.python.org/issue30064 13 msgs #40794: dataclass signatures and docstrings w/future-annotations https://bugs.python.org/issue40794 11 msgs #38605: [typing] PEP 563: Postponed evaluation of annotations: enable https://bugs.python.org/issue38605 10 msgs #40701: tempfile mixes str and bytes in an inconsistent manner https://bugs.python.org/issue40701 10 msgs #40801: Expose PyFloat_AsDouble at Python level: operator.as_float? https://bugs.python.org/issue40801 9 msgs #40217: The garbage collector doesn't take in account that objects of https://bugs.python.org/issue40217 8 msgs #40748: Tutorial 4.7 More on Defining Functions missing screen prompts https://bugs.python.org/issue40748 8 msgs #2897: PyMemberDef missing in limited API / Deprecate structmember.h https://bugs.python.org/issue2897 7 msgs #40275: test.support has way too many imports https://bugs.python.org/issue40275 7 msgs Issues closed (78) ================== #13097: [easy C issue] ctypes: segfault with large number of callback https://bugs.python.org/issue13097 closed by vstinner #14562: urllib2 maybe blocks too long with small chunks https://bugs.python.org/issue14562 closed by benjamin.peterson #17050: argparse.REMAINDER doesn't work as first argument https://bugs.python.org/issue17050 closed by rhettinger #23082: pathlib relative_to() can give confusing error message https://bugs.python.org/issue23082 closed by steve.dower #23721: Set up a daily test coverage run https://bugs.python.org/issue23721 closed by brett.cannon #25247: Tkinter modules built successfully but removed because they co https://bugs.python.org/issue25247 closed by ned.deily #25920: PyOS_AfterFork should reset socketmodule's lock https://bugs.python.org/issue25920 closed by vstinner #26415: Excessive peak memory consumption by the Python parser https://bugs.python.org/issue26415 closed by pablogsal #29882: Add an efficient popcount method for integers https://bugs.python.org/issue29882 closed by mark.dickinson #30986: Add --include-py argument to Tools/msi/make_zip.py https://bugs.python.org/issue30986 closed by cheryl.sabella #32398: OSX C++ linking workaround in distutils breaks other packages https://bugs.python.org/issue32398 closed by cheryl.sabella #33111: Merely importing tkinter breaks parallel code (multiprocessing https://bugs.python.org/issue33111 closed by ned.deily #33388: Support PEP 566 metadata in distutils https://bugs.python.org/issue33388 closed by eric.araujo #34397: remove redundant overflow checks in tuple and list implementat https://bugs.python.org/issue34397 closed by cheryl.sabella #35545: asyncio.base_events.create_connection doesn't handle scoped IP https://bugs.python.org/issue35545 closed by cheryl.sabella #36290: _ast.ast_type_init does not handle args and kwargs correctly. https://bugs.python.org/issue36290 closed by pablogsal #37129: Add os.RWF_APPEND flag for os.pwritev https://bugs.python.org/issue37129 closed by vstinner #37218: Default hmac.new() digestmod has not been removed from documen https://bugs.python.org/issue37218 closed by cheryl.sabella #37973: improve docstrings of sys.float_info https://bugs.python.org/issue37973 closed by mark.dickinson #37999: No longer use implicit convertion to int with loss https://bugs.python.org/issue37999 closed by serhiy.storchaka #38580: select()'s documentation claims only sequences are accepted, b https://bugs.python.org/issue38580 closed by taleinat #39244: multiprocessing.get_all_start_methods() wrong default on macOS https://bugs.python.org/issue39244 closed by taleinat #39685: Python 3.8 regression Socket operation on non-socket https://bugs.python.org/issue39685 closed by christian.heimes #39686: add dump_json to ast module https://bugs.python.org/issue39686 closed by cheryl.sabella #40160: documentation example of os.walk should be less destructive https://bugs.python.org/issue40160 closed by serhiy.storchaka #40327: list(sys.modules.items()) can throw RuntimeError: dictionary c https://bugs.python.org/issue40327 closed by rhettinger #40367: ImportError: libffi.so.6 https://bugs.python.org/issue40367 closed by YoSTEALTH #40373: urlunparse does not escape slash (/) for http+unix:// in netlo https://bugs.python.org/issue40373 closed by taleinat #40439: Error in an external reference https://bugs.python.org/issue40439 closed by cheryl.sabella #40474: Code coverage report not entirely accurate https://bugs.python.org/issue40474 closed by brett.cannon #40552: Enhance for loop and copy example in tutorial https://bugs.python.org/issue40552 closed by nanjekyejoannah #40558: update CONTRIBUTING.rst docs https://bugs.python.org/issue40558 closed by zach.ware #40586: Pydoc should support https for hyperlinks. https://bugs.python.org/issue40586 closed by cheryl.sabella #40611: Add MAP_POPULATE to the mmap library https://bugs.python.org/issue40611 closed by vstinner #40646: Builtins in doc show signature in documentation https://bugs.python.org/issue40646 closed by terry.reedy #40654: shutil.copyfile mutates symlink for absolute path https://bugs.python.org/issue40654 closed by steve.dower #40663: Wrong generated annotation on subscripting https://bugs.python.org/issue40663 closed by pablogsal #40667: [Windows] Add global python and python3 commands https://bugs.python.org/issue40667 closed by steve.dower #40678: Full list of Python lexical rules https://bugs.python.org/issue40678 closed by cool-RR #40679: show class name in method invocation TypeError https://bugs.python.org/issue40679 closed by chris.jerdonek #40688: PEG Generator: Fix scripts to always use the correct parser https://bugs.python.org/issue40688 closed by lys.nikolaou #40719: Add pt-br to the language switcher at the Python 3.6 and 2.7 d https://bugs.python.org/issue40719 closed by rffontenelle #40722: test_ttk_guionly times out on Ubuntu CI https://bugs.python.org/issue40722 closed by terry.reedy #40730: Odd sentence in 3.9 What's New https://bugs.python.org/issue40730 closed by eric.smith #40731: CWI url's protocol on LICENSE file from http to https https://bugs.python.org/issue40731 closed by gvanrossum #40732: New realpath breaks setuptools_scm https://bugs.python.org/issue40732 closed by jaraco #40737: Fix possible reference leak for sqlite3 initialization https://bugs.python.org/issue40737 closed by corona10 #40738: backspace character \b not processed by IDLE https://bugs.python.org/issue40738 closed by terry.reedy #40740: Missing api-ms-win-core-path-l1-1.0.dll for python-3.9.0b1-amd https://bugs.python.org/issue40740 closed by steve.dower #40750: Support -d flag in the new parser https://bugs.python.org/issue40750 closed by pablogsal #40751: command 'elif' does not work https://bugs.python.org/issue40751 closed by terry.reedy #40752: Implement PurePath.__len__ https://bugs.python.org/issue40752 closed by serhiy.storchaka #40753: Remove Python 2 compatibility code from pathlib https://bugs.python.org/issue40753 closed by brett.cannon #40755: Add missing multiset predicates to collections.Counter https://bugs.python.org/issue40755 closed by rhettinger #40760: Dictionary comprehension using older division behavior https://bugs.python.org/issue40760 closed by Amol Sharma #40761: unittest.TestCase.assertTrue return True even if the expr is F https://bugs.python.org/issue40761 closed by zach.ware #40764: Conflation of Counter with Multiset https://bugs.python.org/issue40764 closed by rhettinger #40765: clear screen in idle https://bugs.python.org/issue40765 closed by terry.reedy #40768: pyaudio https://bugs.python.org/issue40768 closed by SilentGhost #40774: "Important" block in documentation of asyncio.create_subproces https://bugs.python.org/issue40774 closed by benjamin.peterson #40776: Python 3.7.6 installation issue on mac os x 10.6.8 https://bugs.python.org/issue40776 closed by ned.deily #40778: Updating Py_REFCNT and Py_SIZE to use _PyObject_CAST_CONS https://bugs.python.org/issue40778 closed by corona10 #40779: incorrect end column for single argument generator function ca https://bugs.python.org/issue40779 closed by pablogsal #40780: float.__format__() handles trailing zeros inconsistently in � https://bugs.python.org/issue40780 closed by mark.dickinson #40781: Remove sys._debugmallocstats() function and PYTHONMALLOCSTATS https://bugs.python.org/issue40781 closed by vstinner #40783: test_interpreters test_interpreters leaked [216, 216, 216] ref https://bugs.python.org/issue40783 closed by pablogsal #40784: test_sqlite: CheckFuncDeterministic() fails with SQLite 3.32 https://bugs.python.org/issue40784 closed by berker.peksag #40787: Mysql + unittest crash https://bugs.python.org/issue40787 closed by lgerosa #40789: C-level destructor in PySide2 breaks gen_send_ex, which assume https://bugs.python.org/issue40789 closed by njs #40790: Python should enable computed gotos on Mac by default https://bugs.python.org/issue40790 closed by benjamin.peterson #40792: Make PyNumber_Index() always returning an exact int instance https://bugs.python.org/issue40792 closed by serhiy.storchaka #40793: print() performance problem with very large numbers https://bugs.python.org/issue40793 closed by mark.dickinson #40795: ctypes: PyErr_WriteUnraisable() called with no exception set o https://bugs.python.org/issue40795 closed by vstinner #40796: dataclasses.make_dataclass: Exception when called with differe https://bugs.python.org/issue40796 closed by Darrick Yee #40803: Unable to execute python.exe from zip in wine https://bugs.python.org/issue40803 closed by clanmills #40806: itertools.product not lazy https://bugs.python.org/issue40806 closed by rhettinger #40809: list.Count() isn't working as expected for the series of same https://bugs.python.org/issue40809 closed by steven.daprano #40812: _tkinter build failed when install Python-3.6.10 https://bugs.python.org/issue40812 closed by ned.deily

2 1

PEP 618: Add Optional Length-Checking To zip
by Brandt Bucher June 2, 2020

June 2, 2020

I have pushed a second draft of PEP 618: https://www.python.org/dev/peps/pep-0618 Please let me know what you think – I'd love to hear any new feedback that hasn't yet been addressed in the PEP! Brandt

23 60

Repr: where to place the address and additional info?
by Serhiy Storchaka June 1, 2020

June 1, 2020

The default repr of Python object is formatted using the following pattern: <{typename} object at {address:#x}> And many custom reprs use similar patterns, but add some additional type specific information. The type name first, followed by details and address. All is surrounded by angle quotes. The question is in what order to show address and other details? Should the address be at rear or in the middle? <{typename} {details} at {address:#x}> <{typename} at {address:#x} {details}> There are examples of both ways in the stdlib. I am going to add new custom reprs [1] and need to know what pattern looks better. Also, is "object" mandatory after the type name? <{typename} object {details} at {address:#x}> <{typename} object at {address:#x} {details}> [1] https://bugs.python.org/issue24391

5 4