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 (… [View More]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) [View Less]

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: … [View More]$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: [View Less]

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 … [View More]

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. … [View More]

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 … [View More]

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 … [View More]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~ [View Less]

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 … [View More]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 [View Less]

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 … [View More]

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 … [View More]

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 … [View More]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. [View Less]

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-… [View More]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-…> [View Less]

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 … [View More]

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 … [View More]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> [View Less]

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++ … [View More]

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. … [View More]

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 … [View More]

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 … [View More]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. [View Less]

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 … [View More]

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 … [View More]

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_ … [View More]

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 … [View More]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> [View Less]

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 … [View More]

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 … [View More]

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 … [View More]

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, … [View More]

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 … [View More]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. [View Less]

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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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.… [View More]

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 … [View More]

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. … [View More]

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: … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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: … [View More]

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. … [View More]

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: … [View More]

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 … [View More]

5 4