Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)
Hi all, Do the accepted PEP were 552, not 550? Thanks, Louie. 2017-09-29 22:40 GMT+08:00 Guido van Rossum : > It's Friday! > > There have been no further comments. PEP 550 is now accepted. > > Congrats, Benjamin! Go ahead and send your implementation for review. > > --Guido > > On Tue, Sep 26, 2017 at 1:47 PM, Guido van Rossum wrote: >> >> I've read the current version of PEP 552 over and I think everything looks >> good for acceptance. I believe there are no outstanding objections (or they >> have been adequately addressed in responses). >> >> Therefore I intend to accept PEP 552 this Friday, unless grave objections >> are raised on this mailing list (python-dev). >> >> Congratulations Benjamin. Gotta love those tristate options! >> >> -- >> --Guido van Rossum (python.org/~guido) > > > > > -- > --Guido van Rossum (python.org/~guido) > > ___ > 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/me%40louie.lu > ___ 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] Is there any docstring format used inside CPython core?
Hi everyone, Is there any docstring format used inside CPython core? e.g. Doxygen. During the tour to know more about CPython, I found that some part of the internal function didn't comment that intuitive, for example, `tok_get` return value, `tok_decimal_tail` description, ...etc. If there is a exist docstring format or style, I can help to complete it. If not, is there any plan to introduce the docstring format into the core. (or maybe some discuss has there before, I can't found inside the python-dev archive) Thanks, Louie. ___ 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] API for bugs.python.org or some statistic about lib/module merge rate?
Hi all, After reading some topic at python-committers mailing list, some of the topics are around not enough reviewers to review patches, cause the develop process slowing down or the patch can't merge into the codebase. I would like to make some analysis about module / library patch merge rate (maybe fine-grained to per file?), and make a statistic list that can point out which module / library need more people to contribute to it. Are there any API for bugs.python.org can be used, or there is a existing thing just doing what I want to do. (Or maybe Python tracker, who sent the summary can add this kind of function.) Thanks, Louie. ___ 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] API for bugs.python.org or some statistic about lib/module merge rate?
I used the download CSV function, and make some change about it. The demo of the site is here: https://bpo-mergerate.louie.lu/ To used, just need to enter the prefix of dictionary to search bar, for now, its resolution is to the second folder or files, e.g., Lib/unittest, Python/ceval.c 2017-04-20 5:04 GMT+08:00 Brett Cannon : > I don't think there's any API. Your best bet will probably be to analyze > the GitHub data. > > On Tue, 18 Apr 2017 at 09:09 Louie Lu wrote: > >> Hi all, >> >> After reading some topic at python-committers mailing list, some of the >> topics are around not enough reviewers to review patches, cause the develop >> process slowing down or the patch can't merge into the codebase. >> >> I would like to make some analysis about module / library patch merge >> rate (maybe fine-grained to per file?), and make a statistic list that can >> point out which module / library need more people to contribute to it. >> >> Are there any API for bugs.python.org can be used, or there is a >> existing thing just doing what I want to do. (Or maybe Python tracker, who >> sent the summary can add this kind of function.) >> >> Thanks, >> Louie. >> ___ >> 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/ >> brett%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
[Python-Dev] Request review of cProfile/profile series issue
Hi all, I'm now looking for cProfile/profile lib's issue, and have solve a series of dependent problem, here is the list: #9285 - Add a profile decorator to profile and cProfile #30113 - Allow helper functions to wrap sys.setprofile #18971 - Use argparse in the profile/cProfile modules #30118 - Add unittest for cProfile/profile command line interface It can divide into two categories, first is the context manager problem, and the second is optparse to argparse problem. 1. context manager problem: Relative issue: #9285, #30113 Relative PR: #287, #1212, #1253 This is an issue since 2010, and stop at profile can't simply add a __enter__ and __exit__ to make it a context manager. The main problem is, sys.setprofile() will hit the return and get bad return in profile dispatch_return function. The solution is to insert a simulate call in the helper function, to provide the context between helper frame and where the profile is defined. 2. optparse to argparse problem: Relative issue: #18971, #30118 Relative PR: #1232 Relative patch: profile_argparse.patch Serhiy have provide the patch of replace optparse to argparse in the profile and cProfile, but block by Ezio request of unittest for command line interface. The unittest is provide at #1232, and need to be reivew. If the unittest is add and argparse patch is apply, we can then solve more problem, e.g.: #23420, #29238, #21862 This is what I've investigated for cProfile / profile library now, to be move on, it will need others to review the work. Thanks! Best Regards, Louie. ___ 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] API for bugs.python.org or some statistic about lib/module merge rate?
Hi all, thanks for all your reply, since roundup didn't contain JSON REST API, and I'm not sure did roundup robot have deal with "patched but still open" situation, thus I do some change to bpo-mergerate and have some result. GitHub repo: https://github.com/lulouie/bpo-mergerate Demo site: https://bpo-mergerate.louie.lu Now bpo-mergerate using SQLite database and no more CSV file, and an update.py script was added, on my host, it will automatically update the bpo patch status hourly. For the site, it is now using ajax and can deal with fuzzy search. The merge rate calculate is now find-grained to per-file, and will automatically count the prefix merge rate, for example: Searching: Lib/test Result: path merged open totalrate /Lib/test 3013 1359 4372 68.916 Lib/test/test_ssl.py 60 15 75 80.000 Lib/test/test_inspect.py 56 12 68 82.353 I think the site function is complete now, welcome for any suggestion. (maybe like speed.python.org make a timeline for the merge rate?) Best Regards, Louie. 2017-04-24 12:08 GMT+08:00 Nick Coghlan : > On 21 April 2017 at 06:04, Wes Turner wrote: > > Roundup has an xmlrpc API: > > > > - https://sourceforge.net/p/roundup/code/ci/default/tree/ > roundup/xmlrpc.py > > - https://sourceforge.net/p/roundup/code/ci/default/tree/ > test/test_xmlrpc.py > > There's also a pending patch to add a HTTPS+JSON REST API to our > Roundup instance: > http://psf.upfronthosting.co.za/roundup/meta/issue581 > > Definite +1 for the general idea of collecting and publishing these > kinds of statistics, though - I can see them being quite useful to a > variety of audiences. > > Cheers, > Nick. > > P.S. The upstream Roundup project is also interested in offering that > capability by default: http://issues.roundup-tracker.org/issue2550734 > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ 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] API for bugs.python.org or some statistic about lib/module merge rate?
Hi all, Current merge rate is count in a mixed way (patch + PR). After reading Bertt's post "The history behind the decision to move Python to GitHub", I would like to separate the count of merge rate to hg and GitHub. It may check that did migrate to GitHub get the better process of CPython development. Best Regards, Louie. 2017-04-24 23:55 GMT+08:00 Louie Lu : > Hi all, > > thanks for all your reply, since roundup didn't contain JSON REST API, and > I'm not sure did roundup robot have deal with "patched but still open" > situation, thus I do some change to bpo-mergerate and have some result. > > GitHub repo: https://github.com/lulouie/bpo-mergerate > Demo site: https://bpo-mergerate.louie.lu > > Now bpo-mergerate using SQLite database and no more CSV file, and an > update.py script was added, on my host, it will automatically update the > bpo patch status hourly. > For the site, it is now using ajax and can deal with fuzzy search. > > The merge rate calculate is now find-grained to per-file, and will > automatically count the prefix merge rate, for example: > > Searching: Lib/test > Result: > path merged open totalrate > /Lib/test 3013 1359 4372 68.916 > Lib/test/test_ssl.py 60 15 75 80.000 > Lib/test/test_inspect.py 56 12 68 82.353 > > > I think the site function is complete now, welcome for any suggestion. > (maybe like speed.python.org make a timeline for the merge rate?) > > Best Regards, > Louie. > > 2017-04-24 12:08 GMT+08:00 Nick Coghlan : > >> On 21 April 2017 at 06:04, Wes Turner wrote: >> > Roundup has an xmlrpc API: >> > >> > - https://sourceforge.net/p/roundup/code/ci/default/tree/round >> up/xmlrpc.py >> > - https://sourceforge.net/p/roundup/code/ci/default/tree/test/ >> test_xmlrpc.py >> >> There's also a pending patch to add a HTTPS+JSON REST API to our >> Roundup instance: >> http://psf.upfronthosting.co.za/roundup/meta/issue581 >> >> Definite +1 for the general idea of collecting and publishing these >> kinds of statistics, though - I can see them being quite useful to a >> variety of audiences. >> >> Cheers, >> Nick. >> >> P.S. The upstream Roundup project is also interested in offering that >> capability by default: http://issues.roundup-tracker.org/issue2550734 >> >> -- >> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia >> > > ___ 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] API for bugs.python.org or some statistic about lib/module merge rate?
Hi all, Fix some pr counting issue, and now the bpo-mergerate can choose hg (the old process), git, or all for mergerate counting. Also, relative bpo issue can be expand by clicking row for more detail. demo site: https://bpo-mergerate.louie.lu Best Regards, Louie. 2017-04-25 16:18 GMT+08:00 Louie Lu : > Hi all, > > Current merge rate is count in a mixed way (patch + PR). > > After reading Bertt's post "The history behind the decision to move Python > to GitHub", I would like to separate the count of merge rate to hg and > GitHub. > > It may check that did migrate to GitHub get the better process of CPython > development. > > > Best Regards, > Louie. > > > > 2017-04-24 23:55 GMT+08:00 Louie Lu : > >> Hi all, >> >> thanks for all your reply, since roundup didn't contain JSON REST API, >> and I'm not sure did roundup robot have deal with "patched but still open" >> situation, thus I do some change to bpo-mergerate and have some result. >> >> GitHub repo: https://github.com/lulouie/bpo-mergerate >> Demo site: https://bpo-mergerate.louie.lu >> >> Now bpo-mergerate using SQLite database and no more CSV file, and an >> update.py script was added, on my host, it will automatically update the >> bpo patch status hourly. >> For the site, it is now using ajax and can deal with fuzzy search. >> >> The merge rate calculate is now find-grained to per-file, and will >> automatically count the prefix merge rate, for example: >> >> Searching: Lib/test >> Result: >> path merged open totalrate >> /Lib/test 3013 1359 4372 68.916 >> Lib/test/test_ssl.py 60 15 75 80.000 >> Lib/test/test_inspect.py 56 12 68 82.353 >> >> >> I think the site function is complete now, welcome for any suggestion. >> (maybe like speed.python.org make a timeline for the merge rate?) >> >> Best Regards, >> Louie. >> >> 2017-04-24 12:08 GMT+08:00 Nick Coghlan : >> >>> On 21 April 2017 at 06:04, Wes Turner wrote: >>> > Roundup has an xmlrpc API: >>> > >>> > - https://sourceforge.net/p/roundup/code/ci/default/tree/round >>> up/xmlrpc.py >>> > - https://sourceforge.net/p/roundup/code/ci/default/tree/test/ >>> test_xmlrpc.py >>> >>> There's also a pending patch to add a HTTPS+JSON REST API to our >>> Roundup instance: >>> http://psf.upfronthosting.co.za/roundup/meta/issue581 >>> >>> Definite +1 for the general idea of collecting and publishing these >>> kinds of statistics, though - I can see them being quite useful to a >>> variety of audiences. >>> >>> Cheers, >>> Nick. >>> >>> P.S. The upstream Roundup project is also interested in offering that >>> capability by default: http://issues.roundup-tracker.org/issue2550734 >>> >>> -- >>> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia >>> >> >> > ___ 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] API for bugs.python.org or some statistic about lib/module merge rate?
Thanks for the reply, 2017-04-27 14:14 GMT+08:00 Terry Reedy : > On 4/26/2017 1:17 AM, Louie Lu wrote: > >> Fix some pr counting issue, and now the bpo-mergerate can choose hg (the >> old process), git, or all for mergerate counting. Also, relative bpo issue >> can be expand by clicking row for more detail. > > > Details do not seem to be correct. I searched for 'Lib/idlelib'. > For pyshell.py, it says 3 merged, 1 open. > I clicked and got bpo issues: 29162 29581 29919 30067 > The 'open' one is https://bugs.python.org/issue29581, patch at > https://github.com/python/cpython/pull/527/commits/de5d514e649729a1f9e6f3e132d8ffb872d38b08 > seems to be an error. You are right, somehow database was wrong, and cannot deal with path change (if there is a change after fetching). Rebuild and fix this problem. > > Lib/idlelib/idle_test/test_calltips.py has 1 and 1 > bpo issues: 20185 22392 24665 > None of these are idlelib issues. > Not that directly, but these bpo issue PR has changed the file. See: bpo-20185: PR 542 bpo-24665: PR 89, and a issue fixed but close PR 898. The detail now will show the relative PR (which bpo and which PR that is merged, fixed, or open) inside. e.g. Lib/idlelib/idle_test/test_calltips.py bpo issues: 20185 22392 24665 PR: bpo-20185: PR 542 bpo-24665: PR 89 Best Regards, Louie. ___ 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] API for bugs.python.org or some statistic about lib/module merge rate?
2017-04-28 4:06 GMT+08:00 Terry Reedy : > On 4/27/2017 7:57 AM, Louie Lu wrote: > >>> Lib/idlelib/idle_test/test_calltips.py has 1 and 1 >>> bpo issues: 20185 22392 24665 >>> None of these are idlelib issues. >>> >> >> Not that directly, but these bpo issue PR has changed the file. >> See: bpo-20185: PR 542 bpo-24665: PR 89, and a issue fixed but close PR >> 898. > > > #20185: The PR number is *very* helpful. This issue has multiple patches > and 5 PRs merged to default. > > #22392: PR 89 has about 10 commits. The original, easy-to-find patch, > https://github.com/python/cpython/pull/89/commits/6ea78e33b599605b0c1c35fbbc2df493d6dfc80a > did not touch test_calltips. > > It is touched by the latest, not so easy-to-find commit > https://github.com/python/cpython/pull/89/commits/54de7aa6c6fffe9b2248153051a24b0e658bf665 > > I don't know how to get the complete merged diff that would be applied if > the green button were pressed. > > #22392 has PR 899 (merged) and PR 898 (closed). The latter was a blunder > that incorporated about 100 already applied patches, mostly from 2016. Take > a look. > https://github.com/python/cpython/pull/898 > > Part of doing good statistics is removing bogus data from datasets. Even > though you cannot remove 898 from github, you should ignore it in your > analysis. All the hits it generates are false positives. This is probably > the source of many other false hits for idlelib. > Now add the blacklist for PR, this is still manual to add into the config I have three cases: PR 898, PR 703, and PR 552. The "automatic" identified should be add in future (probably) >> The detail now will show the relative PR (which bpo and which PR that >> is merged, fixed, or open) inside. >> >> e.g. >> Lib/idlelib/idle_test/test_calltips.py >> bpo issues: 20185 22392 24665 >> PR: bpo-20185: PR 542 bpo-24665: PR 89 > > > Note that 898 is so bogus that it cannot be handled properly. > > For me, the immediate use case is to find patches to idlelib by others that > I am not aware of, like the two real ones to test_calltips. I would like an > entry box for the start date to put in date last checked. What would be The latest bpo-issue check date will now be shown when the cursor hovers on the issue. (That mean, mobile can't see the date now. I think (on mobile) this isn't that needed) > really super would to be able to exclude issues (and associated patches) > assigned to me. This may be update in the future. (Assignee from bpo or GitHub?) > > When you get this polished, I hope you open an issue and PR to add it to one > of the cpython and mention it in the devguide. > Yes, I will. A small question what does it mean "add it to one of the cpython"? > > -- > Terry Jan Reedy > Best Regards, Louie. ___ 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] Request review of cProfile/profile series issue
For who may be reviewing cProfile / profile context manager problem, I prepare a post for explaining why the problem become, and why the patch will fix this problem: post: https://blog.louie.lu/2017/04/23/python-libs-profile-cant-context-manager/ Thanks, Louie. 2017-04-23 11:21 GMT+08:00 Louie Lu : > Hi all, > > I'm now looking for cProfile/profile lib's issue, and have solve a series of > dependent problem, here is the list: > > #9285 - Add a profile decorator to profile and cProfile > #30113 - Allow helper functions to wrap sys.setprofile > #18971 - Use argparse in the profile/cProfile modules > #30118 - Add unittest for cProfile/profile command line interface > > It can divide into two categories, first is the context manager problem, and > the second is optparse to argparse problem. > > 1. context manager problem: > > Relative issue: #9285, #30113 > Relative PR: #287, #1212, #1253 > > This is an issue since 2010, and stop at profile can't simply add a > __enter__ and __exit__ to make it a context manager. The main problem is, > sys.setprofile() will hit the return and get bad return in profile > dispatch_return function. The solution is to insert a simulate call in the > helper function, to provide the context between helper frame and where the > profile is defined. > > 2. optparse to argparse problem: > > Relative issue: #18971, #30118 > Relative PR: #1232 > Relative patch: profile_argparse.patch > > Serhiy have provide the patch of replace optparse to argparse in the profile > and cProfile, but block by Ezio request of unittest for command line > interface. The unittest is provide at #1232, and need to be reivew. If the > unittest is add and argparse patch is apply, we can then solve more problem, > e.g.: #23420, #29238, #21862 > > > This is what I've investigated for cProfile / profile library now, > to be move on, it will need others to review the work. > > Thanks! > > Best Regards, > Louie. ___ 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] The untuned tunable parameter ARENA_SIZE
For the ARENA_SIZE, will that be better to setting by ./configure first, and without hard code in c files? 2017-06-01 17:37 GMT+08:00 INADA Naoki : > x86's hugepage is 2MB. > And some Linux enables "Transparent Huge Page" feature. > > Maybe, 2MB arena size is better for TLB efficiency. > Especially, for servers having massive memory. > > > On Thu, Jun 1, 2017 at 4:38 PM, Larry Hastings wrote: >> >> >> When CPython's small block allocator was first merged in late February 2001, >> it allocated memory in gigantic chunks it called "arenas". These arenas >> were a massive 256 KILOBYTES apiece. >> >> This tunable parameter has not been touched in the intervening 16 years. >> Yet CPython's memory consumption continues to grow. By the time a current >> "trunk" build of CPython reaches the REPL prompt it's already allocated 16 >> arenas. >> >> I propose we make the arena size larger. By how much? I asked Victor to >> run some benchmarks with arenas of 1mb, 2mb, and 4mb. The results with 1mb >> and 2mb were mixed, but his benchmarks with a 4mb arena size showed >> measurable (>5%) speedups on ten benchmarks and no slowdowns. >> >> What would be the result of making the arena size 4mb? >> >> CPython could no longer run on a computer where at startup it could not >> allocate at least one 4mb continguous block of memory. >> CPython programs would die slightly sooner in out-of-memory conditions. >> CPython programs would use more memory. How much? Hard to say. It depends >> on their allocation strategy. I suspect most of the time it would be < 3mb >> additional memory. But for pathological allocation strategies the >> difference could be significant. (e.g: lots of allocs, followed by lots of >> frees, but the occasional object lives forever, which means that the arena >> it's in can never be freed. If 1 out of ever 16 256k arenas is kept alive >> this way, and the objects are spaced out precisely such that now it's 1 for >> every 4mb arena, max memory use would be the same but later stable memory >> use would hypothetically be 16x current) >> Many programs would be slightly faster now and then, simply because we call >> malloc() 1/16 as often. >> >> >> What say you? Vote for your favorite color of bikeshed now! >> >> >> /arry >> >> >> ___ >> 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/songofacandy%40gmail.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/me%40louie.lu ___ 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] IDLE internal layout
(Due to idle-dev mailing list low traffic, this mail was sent to python-dev and idle-dev) Hi all, I'm now trying to figure out IDLE internal relation. I got some module dependency graph and count. The work is at HackMD: https://hackmd.io/IwNg7AphDGBmsFoAsBOCAmZAGMBDBKsArEgruuiEkQCa5YBGsNQA Is there any previous material on this topic? thanks Louie. ___ 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] IDLE internal layout
I generate these picture with no-external, so it won't show up about importlib.import_module calls (I think) I'll try to modify the code, and re-generated the pic with importlib. 2017-06-14 20:45 GMT+08:00 Terry Reedy : > On 6/14/2017 1:48 AM, Louie Lu wrote: >> >> (Due to idle-dev mailing list low traffic, this mail was sent to >> python-dev and idle-dev) > > >> I'm now trying to figure out IDLE internal relation. >> I got some module dependency graph and count. >> >> The work is at HackMD: >> >> https://hackmd.io/IwNg7AphDGBmsFoAsBOCAmZAGMBDBKsArEgruuiEkQCa5YBGsNQA >> >> Is there any previous material on this topic? > > > Not that I know of. There are many delayed imports in idlelib. At least one > is to avoid circular import error, as I discovered when I tried to move it > to the top as suggested by PEP8. > > Thanks for finding the site and producing the .pngs. Even though missing a > few links from importlib.import_module calls, they will be helpful. I saved > the 2nd one locally so I can view it at full size. > > (The left column links such as debugger.py linking to 'debugger.py' are > nonsensical.) > > -- > 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/me%40louie.lu ___ 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
