Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
17.05.18 21:39, Brett Cannon пише: Maybe we should start thinking about flagging PRs or issues as needing a What's New entry to help track when they need one, or always expect it in a PR and ignore that requirement when a 'skip whats new' label is applied. That would at least make it easier to keep track of what needs to be done. The requirement of flagging PRs or issues as needing a What's New entry doesn't differ in principle from the requirement of creating a What's New entry for these changes. The latter is good, and I'm trying always create a What's New entry for significant enhancement or potentially breaking change. And even I sometimes is unsure and don't document some important changes (like in issue30399). Needed a look of yet one pair of eyes. As for requiring a What's New entry by default and introducing a 'skip whats new' label, I suppose this will add much nuisance. Most PRs (except docs and tests changes) need a news entry, but most PRs don't need a What's New entry because their are bug fixes. Therefore a 'skip whats new' label will be required much more times than 'skip news' or 'skip issue' labels. A thing that can help is a tool that makes a structural diff between NEWS files for different versions and between different branches. It will filter out bugfix changes. The simple 'diff' is not well appropriate because entries can be in different order, and news entries now are scattered between several files, and news entries for previous version sometimes should be searched in different files, and sometimes should be searched on a different branch. The text of entries in different versions can also be different because the same issue can change the behavior on the master and backport the part of changes as a bugfix. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why aren't escape sequences in literal strings handled by the tokenizer?
Eric V. Smith wrote: I assume the intent is to not throw away any information in the lexer, and give the parser full access to the original string. But that's just a guess. More likely it's because the lexer is fairly dumb and can basically just recognise regular expressions. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Normalisation of unicode and keywords
Stephan Houben noticed that Python apparently allows identifiers to be keywords, if you use Unicode "mathematical bold" letters. His explanation is that the identifier is normalised, but not until after keywords are checked for. So this works: class Spam: locals()['if'] = 1 Spam.𝐢𝐟# U+1D422 U+1D41F # returns 1 Of course Spam.if fails with SyntaxError. Should this work? Is this a bug, a feature, or an accident of implementation we can ignore? -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On 18.05.2018 10:55, Serhiy Storchaka wrote: 17.05.18 21:39, Brett Cannon пише: Maybe we should start thinking about flagging PRs or issues as needing a What's New entry to help track when they need one, or always expect it in a PR and ignore that requirement when a 'skip whats new' label is applied. That would at least make it easier to keep track of what needs to be done. The requirement of flagging PRs or issues as needing a What's New entry doesn't differ in principle from the requirement of creating a What's New entry for these changes. The latter is good, and I'm trying always create a What's New entry for significant enhancement or potentially breaking change. And even I sometimes is unsure and don't document some important changes (like in issue30399). Needed a look of yet one pair of eyes. As for requiring a What's New entry by default and introducing a 'skip whats new' label, I suppose this will add much nuisance. Most PRs (except docs and tests changes) need a news entry, but most PRs don't need a What's New entry because their are bug fixes. Therefore a 'skip whats new' label will be required much more times than 'skip news' or 'skip issue' labels. Since Python uses semantic versioning (https://semver.org), the criterion for "what's new-worthy" changes is simple: they are _public interface changes_ (which include visible changes to documented behavior). (I maintain that changes to behavior that is not documented -- incl. issue30399 -- are _not_ public interface changes, and whoever relies on them does that on their own risk.) Reading previous What's New, I see that it is structured like this * Entries for major changes: * General design decisions * Changes that fall into a category (more recent What's New's include about a dozen categories) * "Other": the list of the rest So, it makes sense to mark work items as "interface change" or something, and optionally with a caterory if that category is established. You can't make a mistake here 'cuz a public interface change requires an edit to related documentation. A thing that can help is a tool that makes a structural diff between NEWS files for different versions and between different branches. It will filter out bugfix changes. The simple 'diff' is not well appropriate because entries can be in different order, and news entries now are scattered between several files, and news entries for previous version sometimes should be searched in different files, and sometimes should be searched on a different branch. The text of entries in different versions can also be different because the same issue can change the behavior on the master and backport the part of changes as a bugfix. Not all bugs apply to all, or multiple branches, so that wouldn't filter them out reliably. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru -- Regards, Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Normalisation of unicode and keywords
On 18.05.2018 14:46, Steven D'Aprano wrote: Stephan Houben noticed that Python apparently allows identifiers to be keywords, if you use Unicode "mathematical bold" letters. His explanation is that the identifier is normalised, but not until after keywords are checked for. So this works: class Spam: locals()['if'] = 1 Spam.𝐢𝐟# U+1D422 U+1D41F # returns 1 Of course Spam.if fails with SyntaxError. Should this work? Is this a bug, a feature, or an accident of implementation we can ignore? Voting for bug: Either those identifiers should be considered equal, or they shouldn't. They can't be considered "partially" equal. -- Regards, Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On 5/18/18 9:20 AM, Ivan Pozdeev via Python-Dev wrote: > Since Python uses semantic versioning (https://semver.org), the > criterion for "what's new-worthy" changes is simple: they are _public > interface changes_ (which include visible changes to documented behavior). > (I maintain that changes to behavior that is not documented -- incl. > issue30399 -- are _not_ public interface changes, and whoever relies > on them does that on their own risk.) > Python does NOT use semantic versioning as features are allowed to be obsoleted and removed without a major version number change. Also the addition of a new keyword which breaks old code would not be allowed with semantic versioning. The basic rules of semantic versioning is that ANY program that uses documented features of version a.b.c will work on any version a.d.e where (d > b) or (d = b and e > c). If python did use semantic versioning then there would be no need to keep updates to older minor versions, once 3.7.0 was out, there would be no need for keeping the 3.6.x, 3.5.x, 3.4.x branch etc, as any program that was written for those older version would just work with the newer version. The need for those is proof that python does not use semantic versioning. If you wanted to map python version to a semantic versioning concept, the first two numbers of the version would correspond to what semantic versioning call the 'major revision' which is what is allowed to break backwards compatibility with API, with the first digit being major changes and the second minor but not fully backwards compatible changes. -- Richard Damon ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] please help triage VSTS failures
These both look like VSTS infrastructure falling over on PRs: https://python.visualstudio.com/cpython/_build?buildId=522 https://python.visualstudio.com/cpython/_build?buildId=523 I don't see anywhere that gives information about the failures. (*) These CI failures on different platforms are both for the same change, on different branches, for a documentation only change. That passed on the other branches and platforms for the same change. -gps (*) I refuse to "Download logs as a zip file". I'm in a web browser, if the information I might need is potentially buried somewhere in a zip file of logs, that is a waste of my time. I'm not going to do it. The web UI *needs* to find and display the relevant failure info from any logs directly. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2018-05-11 - 2018-05-18) 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: open6686 (+42) closed 38637 (+66) total 45323 (+108) Open issues with patches: 2630 Issues opened (72) == #33466: Distutils does not support the compilation of Objective-C++ (â https://bugs.python.org/issue33466 opened by fish2000 #33467: Python 3.7: profile-opt build errors because a test seems to h https://bugs.python.org/issue33467 opened by Rahul Ravindran #33468: Add try-finally contextlib.contextmanager example https://bugs.python.org/issue33468 opened by ncoghlan #33469: RuntimeError after closing loop that used run_in_executor https://bugs.python.org/issue33469 opened by hniksic #33471: string format with 'n' failling with french locales https://bugs.python.org/issue33471 opened by David Vasseur #33473: build system incorrectly handles CC, CFLAGS, LDFLAGS, and rela https://bugs.python.org/issue33473 opened by eitan.adler #33474: Support immutability per-field in dataclasses https://bugs.python.org/issue33474 opened by Daniel Lindeman #33475: Fix converting AST expression to string and optimize parenthes https://bugs.python.org/issue33475 opened by serhiy.storchaka #33476: String index out of range in get_group(), email/_header_value_ https://bugs.python.org/issue33476 opened by Cacadril #33477: Document that compile(code, 'exec') has different behavior in https://bugs.python.org/issue33477 opened by mbussonn #33479: Document tkinter and threads https://bugs.python.org/issue33479 opened by terry.reedy #33481: configparser.write() does not save comments. https://bugs.python.org/issue33481 opened by pebaudhi #33482: codecs.StreamRecoder.writelines is broken https://bugs.python.org/issue33482 opened by Jelle Zijlstra #33483: build system requires explicit compiler, but should discover i https://bugs.python.org/issue33483 opened by eitan.adler #33484: build system runs when it may merely link https://bugs.python.org/issue33484 opened by eitan.adler #33485: autoconf target does not behave correctly https://bugs.python.org/issue33485 opened by eitan.adler #33486: regen autotools related files https://bugs.python.org/issue33486 opened by eitan.adler #33487: BZ2File(buffering=None) does not emit deprecation warning, dep https://bugs.python.org/issue33487 opened by mbussonn #33489: Newer externals for windows do not always trigger rebuild https://bugs.python.org/issue33489 opened by terry.reedy #33490: pthread auto-detection can use AX_PTHREAD https://bugs.python.org/issue33490 opened by eitan.adler #33491: mistype of method's name https://bugs.python.org/issue33491 opened by Ivan Gushchin #33492: Updating the Evaluation order section to cover *expression in https://bugs.python.org/issue33492 opened by mjpieters #33494: random.choices ought to check that cumulative weights are in a https://bugs.python.org/issue33494 opened by steven.daprano #33498: pathlib.Path wants an rmtree method https://bugs.python.org/issue33498 opened by Aaron Hall #33499: Environment variable to set alternate location for pycache tre https://bugs.python.org/issue33499 opened by carljm #33500: Python TKinter for Mac on latest 2.7.15 still extremely slow v https://bugs.python.org/issue33500 opened by Michael Romero #33501: split existing optimization levels into granular options https://bugs.python.org/issue33501 opened by carljm #33504: configparser should use dict instead of OrderedDict in 3.7+ https://bugs.python.org/issue33504 opened by jreese #33505: Optimize asyncio.ensure_future by reordering if conditions https://bugs.python.org/issue33505 opened by jimmylai #33507: Improving the html rendered by cgitb.html https://bugs.python.org/issue33507 opened by sblondon #33511: Update config.sub https://bugs.python.org/issue33511 opened by eitan.adler #33514: async and await as keywords not mentioned in Whatâs New In P https://bugs.python.org/issue33514 opened by hroncok #33515: subprocess.Popen on a Windows batch file always acts as if she https://bugs.python.org/issue33515 opened by abigail #33516: unittest.mock: Add __round__ to supported magicmock methods https://bugs.python.org/issue33516 opened by mjpieters #33518: Add PEP to glossary https://bugs.python.org/issue33518 opened by adelfino #33519: Should MutableSequence provide .copy()? https://bugs.python.org/issue33519 opened by Jelle Zijlstra #33521: Add 1.32x faster C implementation of asyncio.isfuture(). https://bugs.python.org/issue33521 opened by jimmylai #33523: loop.run_until_complete re-entrancy to support more complicate https://bugs.python.org/issue33523 opened by fried #33524: non-ascii characters in headers causes TypeError on email.poli https://bugs.python.org/issue33524 opened by radical164 #33525: os.spawnvpe() returns error code 127 ins
Re: [Python-Dev] please help triage VSTS failures
On Fri, May 18, 2018 at 10:55 AM, Gregory P. Smith wrote: > These both look like VSTS infrastructure falling over on PRs: > > https://python.visualstudio.com/cpython/_build?buildId=522 > > https://python.visualstudio.com/cpython/_build?buildId=523 > > I don't see anywhere that gives information about the failures. (*) Somewhat non-intuitively, logs are available by clicking something in the tree in the left column (in particular, the inner-most thing with a red X). Do be sure to choose "Logs" in the right pane rather than "Tests"; "Tests" appears to be a separate feature that we don't use. > These CI failures on different platforms are both for the same change, on > different branches, for a documentation only change. That passed on the > other branches and platforms for the same change. The Windows failure appears to be the test_asyncio instability that has been popping up everywhere the past couple of days. The Linux failure looks like a mis-use of Tools/ssl/multissltests.py in the setup, but I thought I'd seen a checkin go by that removed that. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Normalisation of unicode and keywords
It's a canonicalisation error. Steve Holden On Fri, May 18, 2018 at 2:38 PM, Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > On 18.05.2018 14:46, Steven D'Aprano wrote: > >> Stephan Houben noticed that Python apparently allows identifiers to be >> keywords, if you use Unicode "mathematical bold" letters. His >> explanation is that the identifier is normalised, but not until after >> keywords are checked for. So this works: >> >> class Spam: >> locals()['if'] = 1 >> >> >> Spam.𝐢𝐟# U+1D422 U+1D41F >> # returns 1 >> >> >> Of course Spam.if fails with SyntaxError. >> >> Should this work? Is this a bug, a feature, or an accident of >> implementation we can ignore? >> > Voting for bug: > Either those identifiers should be considered equal, or they shouldn't. > They can't be considered "partially" equal. > >> >> >> > -- > Regards, > Ivan > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve% > 40holdenweb.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] bpo-33522: Enable CI builds on Visual Studio Team Services (GH-6865) (GH-6925)
On Thu, May 17, 2018 at 11:32 PM Gregory P. Smith wrote: > Why did this commit modify .py files, unittests, and test.support? > That is inappropriate for something claiming to merely enable a CI platform. I think there is probably an argument to be made that some of the changes will be improvements, but I think such changes belong in separate PRs. Even if that means you have to postpone the core bits of this change until they are merged. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please help triage VSTS failures
Unfamiliar maybe, though I’m a big fan of separating build and test logs. If anyone is motivated enough to make unittest/regrtest generate Junit format XML then we can get a nice breakdown by individual test, too, which would save scrolling through the log entirely. The asyncio instability is apparently really hard to fix. There were 2-3 people looking into it yesterday on one of the other systems, but apparently we haven’t solved it yet (my guess is lingering state from a previous test). The multissl script was my fault for not realising that we don’t use it on 3.6 builds, but that should be fixed already. Close/reopen PR is the best way to trigger a rebuild right now. According to the VSTS dev team, an easy “rerun this build” button and filtering by changed paths are coming soon, which should clean things up. We *could* add our own detection for doc-only changes and skip most steps – I’m happy to add that in if someone can help with the right git incantation. Top-posted from my Windows phone From: Zachary Ware Sent: Friday, May 18, 2018 9:15 To: Python-Dev Subject: Re: [Python-Dev] please help triage VSTS failures On Fri, May 18, 2018 at 10:55 AM, Gregory P. Smith wrote: > These both look like VSTS infrastructure falling over on PRs: > > https://python.visualstudio.com/cpython/_build?buildId=522 > > https://python.visualstudio.com/cpython/_build?buildId=523 > > I don't see anywhere that gives information about the failures. (*) Somewhat non-intuitively, logs are available by clicking something in the tree in the left column (in particular, the inner-most thing with a red X). Do be sure to choose "Logs" in the right pane rather than "Tests"; "Tests" appears to be a separate feature that we don't use. > These CI failures on different platforms are both for the same change, on > different branches, for a documentation only change. That passed on the > other branches and platforms for the same change. The Windows failure appears to be the test_asyncio instability that has been popping up everywhere the past couple of days. The Linux failure looks like a mis-use of Tools/ssl/multissltests.py in the setup, but I thought I'd seen a checkin go by that removed that. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please help triage VSTS failures
On Fri, May 18, 2018 at 4:15 PM Steve Dower wrote: [..] > The asyncio instability is apparently really hard to fix. There were 2-3 people looking into it yesterday on one of the other systems, but apparently we haven’t solved it yet (my guess is lingering state from a previous test). The multissl script was my fault for not realising that we don’t use it on 3.6 builds, but that should be fixed already. Close/reopen PR is the best way to trigger a rebuild right now. I asked Andrew Svetlov to help with asyncio CI triage. Hopefully we'll resolve most of them early next week. Yury ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please help triage VSTS failures
On 5/18/2018 4:13 PM, Steve Dower wrote: Close/reopen PR is the best way to trigger a rebuild right now. It may be the way to retrigger VSTS, but if one want to merge, and either of Travis or AppVeyor pass, tossing the success is a foolish thing to do. Either may fail on a rebuild. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please help triage VSTS failures
On Fri, May 18, 2018 at 1:13 PM, Steve Dower wrote: > According to the VSTS dev team, an easy “rerun this build” button and > filtering by changed paths are coming soon, which should clean things up. If you're talking to them, please ask them to make sure that the "rerun this build" button doesn't erase the old log. (That's what it does on Travis. Appveyor is better.) The problem is that when you have a flaky/intermittent failure, your todo list is always (a) rerun the build so at least it's not blocking whatever this unrelated change is, (b) file some sort of bug, or comment on some existing bug, and link to the log to help track down the intermittent failure. If you click the "rebuild" button on Travis, then it solves (a), while deleting the information you need for (b) – and for rare intermittent bugs you might not have much information to go on besides that build log. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please help triage VSTS failures
Hah, yes, that was un-intuitive for me. I was looking for something labelled "logs" to click on. thanks. (I hope MS is taking notes on UX issues here) So these failures were in fact the known flakes and not infrastructure. good! On the high level view of VSTS output on a failure: "Issues: phase1 Cmd.exe exited with code '2'." is not useful. Can we make that display the tail of the failing phase's log? that'd avoid needing to find the inner most red X and click on it which is what I'll always need to do otherwise as there doesn't appear to be a direct hyperlink to that. It looks like VSTS also had an API for surfacing individual test results into their Tests / Test Results summary pane? Doing something to integrate with that would likely be a nicer UI. We have something similar at work, here's how we make unittest.TestCase emit the JUnit XML files of test results for CI systems to display: https://github.com/abseil/abseil-py/blob/master/absl/testing/xml_reporter.py If there are industry standard format(s) that make Python test suites play nicer for reporting on CI systems such as that, they'd be worthy of stdlib inclusion. -gps On Fri, May 18, 2018 at 5:35 PM Nathaniel Smith wrote: > On Fri, May 18, 2018 at 1:13 PM, Steve Dower > wrote: > > According to the VSTS dev team, an easy “rerun this build” button and > > filtering by changed paths are coming soon, which should clean things up. > > If you're talking to them, please ask them to make sure that the > "rerun this build" button doesn't erase the old log. (That's what it > does on Travis. Appveyor is better.) The problem is that when you have > a flaky/intermittent failure, your todo list is always (a) rerun the > build so at least it's not blocking whatever this unrelated change is, > (b) file some sort of bug, or comment on some existing bug, and link > to the log to help track down the intermittent failure. If you click > the "rebuild" button on Travis, then it solves (a), while deleting the > information you need for (b) – and for rare intermittent bugs you > might not have much information to go on besides that build log. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please help triage VSTS failures
Hmm... I would guess that it would create a new "build” and likely lose the link to the original (though it would still be kept, just harder to find). Then again, the existing support for rerunning a release through VSTS keeps all the previous attempts... I’ll mention it, but the quickest fix here may not be immediately sufficient. Sent from my Windows 10 phone From: Nathaniel Smith Sent: Friday, May 18, 2018 17:34 To: Steve Dower Cc: Zachary Ware; Python-Dev Subject: Re: [Python-Dev] please help triage VSTS failures On Fri, May 18, 2018 at 1:13 PM, Steve Dower wrote: > According to the VSTS dev team, an easy “rerun this build” button and > filtering by changed paths are coming soon, which should clean things up. If you're talking to them, please ask them to make sure that the "rerun this build" button doesn't erase the old log. (That's what it does on Travis. Appveyor is better.) The problem is that when you have a flaky/intermittent failure, your todo list is always (a) rerun the build so at least it's not blocking whatever this unrelated change is, (b) file some sort of bug, or comment on some existing bug, and link to the log to help track down the intermittent failure. If you click the "rebuild" button on Travis, then it solves (a), while deleting the information you need for (b) – and for rare intermittent bugs you might not have much information to go on besides that build log. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
