[Python-Dev] Locks and signals
On Thu, 27 May 2010 21:57:48 -0400 Reid Kleckner wrote: > > Unrelatedly, I feel like this behavior of waiting for the thread to > terminate usually manifests as deadlocks when the main thread throws > an uncaught exception. The application then no longer responds > properly to interrupts, since it's stuck waiting on a semaphore. I think the internal low-level lock implementation should be fixed so that it runs PyErr_CheckSignals() and is able to signal an error on function return (rather than the current binary "lock succeeded" / "lock timed out" status). Actually, it would be nice if you could open a bug entry for that :) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-05-21 - 2010-05-28) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2705 open (+40) / 17957 closed (+21) / 20662 total (+61) Open issues with patches: 1095 Average duration of open issues: 720 days. Median duration of open issues: 500 days. Open Issues Breakdown open 2683 (+40) languishing12 ( +0) pending 9 ( +0) Issues Created Or Reopened (62) ___ httplib fails with HEAD requests to pages with "transfer-encod 2010-05-26 http://bugs.python.org/issue6312reopened orsenthil patch The external link to a "Hash Collision FAQ" points to some com 2010-05-21 CLOSED http://bugs.python.org/issue8783created stutzbach tarfile/Windows: Don't use mbcs as the default encoding2010-05-22 http://bugs.python.org/issue8784created haypo patch findall() and finditer() docs misleading 2010-05-22 CLOSED http://bugs.python.org/issue8785created hagen Add support for IEEE 754 contexts to decimal module. 2010-05-22 http://bugs.python.org/issue8786created mark.dickinson warnings inside PyRun_SimpleString() display argv[1] 2010-05-22 http://bugs.python.org/issue8787created Sebastian patch urllib.urlencode documentation unclear on doseq2010-05-22 http://bugs.python.org/issue8788created VeXocide spam 2010-05-22 CLOSED http://bugs.python.org/issue8789created renben spam 2010-05-22 CLOSED http://bugs.python.org/issue8790created renben spam 2010-05-22 CLOSED http://bugs.python.org/issue8791created renben xmlrpclib compatibility issues with Apache XML-RPC library 2010-05-22 http://bugs.python.org/issue8792created bra IDLE crashes on opening invalid file 2010-05-23 http://bugs.python.org/issue8793created royf spam 2010-05-23 CLOSED http://bugs.python.org/issue8794created renben Error sending utf8 strings over syslog udp protocol2010-05-23 CLOSED http://bugs.python.org/issue8795created skliarie Deprecate codecs.open()2010-05-23 http://bugs.python.org/issue8796created haypo urllib2 basicauth broken in 2.6.5: RuntimeError: maximum recur 2010-05-24 http://bugs.python.org/issue8797created jonozzz tkinter build variants on OSX 2010-05-24 http://bugs.python.org/issue8798created ronaldoussoren Hang in lib/test/test_threading.py 2010-05-24 http://bugs.python.org/issue8799created krisvale patch, patch, easy add threading.RWLock
Re: [Python-Dev] PEP 3148 ready for pronouncement
Brian Quinlan sweetapp.com> writes: > "future" is a computing science term of art, like "thread". Anyway, > this has been discussed in the past and Guido was happy with the name. I've not seen this mentioned, but on such a long thread I might have missed it: we already have a "__future__" module, as in from __future__ import with_statement and to my mind, this is a potential point of confusion with the term "future". > > * It seems unnecessarily verbose to tack "Executor" > > onto the end of every Executor subclass. They could > > simply be called ThreadPool and ProcessPool without > > losing anything. > > You could have general thread pools that aren't related to executors > (actually, it would be great if Python had a good built-in thread pool > implementation) and I'd like to avoid using an overly generic name. > Aren't executors and pools both housekeepers around a bunch of threads which execute code as a service for other threads? A thread is useless unless it executes code, isn't it? I'm not sure I understand the fine distinction between an executor and a pool. Having Executor as a suffix will give a point of familiarity to those who already know java.util.concurrent. And ProcessPool might cause confusion with multiprocessing.Pool because at first glance they seem to be the same thing. > > * I don't see a strong reason to put this module > > inside a newly-created namespace. If there were a > > namespace called "concurrent", I would expect to find > > other existing concurrency-related modules there as > > well, such as threading and multiprocessing. But we > > can't move them there without breaking existing code. > > I think that Jesse was planning to add some functionality to this > namespace. I don't really have an opinion on this. > I'm not sure of the benefit of a "concurrent" namespace, since it wouldn't contain the existing concurrency stuff. I think it's something to consider only for a big reorg which would break backward compatibility. IMO it would make more sense to leave this module as a top-level module for now (a sibling to "threading", "multiprocessing"). Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Bugfix releases should not change APIs
I had the strong impression that there was a policy that x.y.z bugfix releases should only fix bugs and not add new features and revise current ones. The rationale, as I understood it, is that x.y.z releases should be increasingly better implementations of a stable x.y feature set. Adding features is 'bad' because code using a new feature will not work in previous releases of the same x.y version. Changing features is even worse because it may also break working code going forward. Because of this policy, an x.y.z Windows installer (I do not know about others) deletes any earlier release of the same version. Also, there is no What's New in Python x.y.z (relative to x.y.(z-1) since such should be empty. Consequently, violations of the policy are pretty much silent and well hidden. Yesterday, I spent two hours puzzling over the failure of my previously 'green' test sequence that tested a custom test function. I finally realized that the change was not due to anything I did (or undid), but a change in 3.1.2 in the interaction of StringIO.truncate, StringIO.getvalue, and print(x, StringIO()). (I should note the it is the usual stability and quality of Python that made me slow to blame Python rather than myself.) After filing http://bugs.python.org/issue8840 I was rather shocked to be told that the code-breaking and policy-violating change was intentional because being 'more consistent with other file-handling APIs out there' was somehow more important than consistency within version releases. It also seems to me that discussion of code-breaking API changes like this should involve more than one user and one developer. See http://bugs.python.org/issue6939 I have fixed my tests so they works in 3.1.2 and should work in other 3.1 releases, but that would be a nuisance to test. Of course, I should not have to worry about API changes within a version series. I think issue 8840 illustrates another reason for the bugfix-only policy. New x.y features and docs are (nearly always) added before the first beta. They can then be tested, discussed, and improved. This 'cooking' does not occur for bugfix releases. For reasons I give in my response on the tracker, I think the new behavior is buggy and the doc deficient. So, I think 1) the supposed bugfix-only policy should really be the policy; 2) the violation in 3.1.2 should be reverted in 3.1.3, and the API change reviewed in the normal 3.2 alpha/beta process. I am curious as to what others think on both points. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3148 ready for pronouncement
On Sat, 29 May 2010 08:28:46 am Vinay Sajip wrote: > I've not seen this mentioned, but on such a long thread I might have > missed it: we already have a "__future__" module, as in > > from __future__ import with_statement > > and to my mind, this is a potential point of confusion with the term > "future". [...] > I'm not sure of the benefit of a "concurrent" namespace, since it > wouldn't contain the existing concurrency stuff. I think it's > something to consider only for a big reorg which would break backward > compatibility. IMO it would make more sense to leave this module as a > top-level module for now (a sibling to "threading", > "multiprocessing"). I have suggested a way to move the existing concurrency stuff without breaking backwards compatibility, and Terry Reedy asked if it would work. I haven't seen any responses, either positive or negative. For the record, my suggestion was: for each concurrency modules: move it into the concurrency package add a top level module with the same name containing: # e.g. for threading from concurrency.threading import * Then in some future Python version, each top level module gets a PendingDeprecation warning, followed by a Deprecation warning some time later, and eventually in the indefinite future removal of the top level module. Leaving the futures module in the top level of the std lib is far more likely to confuse users than adding it to its own namespace. Compare: import __future__ import futures with: import __future__ import concurrency.futures In my opinion, it is high time for the std lib to pay more attention to the final Zen: Namespaces are one honking great idea -- let's do more of those! -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3148 ready for pronouncement
Vinay Sajip wrote: > Brian Quinlan sweetapp.com> writes: > >> "future" is a computing science term of art, like "thread". Anyway, >> this has been discussed in the past and Guido was happy with the name. > > I've not seen this mentioned, but on such a long thread I might have missed > it: > we already have a "__future__" module, as in > > from __future__ import with_statement > > and to my mind, this is a potential point of confusion with the term "future". > >>> * It seems unnecessarily verbose to tack "Executor" >>> onto the end of every Executor subclass. They could >>> simply be called ThreadPool and ProcessPool without >>> losing anything. >> You could have general thread pools that aren't related to executors >> (actually, it would be great if Python had a good built-in thread pool >> implementation) and I'd like to avoid using an overly generic name. >> > > Aren't executors and pools both housekeepers around a bunch of threads which > execute code as a service for other threads? A thread is useless unless it > executes code, isn't it? I'm not sure I understand the fine distinction > between > an executor and a pool. Having Executor as a suffix will give a point of > familiarity to those who already know java.util.concurrent. And ProcessPool > might cause confusion with multiprocessing.Pool because at first glance they > seem to be the same thing. > >>> * I don't see a strong reason to put this module >>> inside a newly-created namespace. If there were a >>> namespace called "concurrent", I would expect to find >>> other existing concurrency-related modules there as >>> well, such as threading and multiprocessing. But we >>> can't move them there without breaking existing code. >> I think that Jesse was planning to add some functionality to this >> namespace. I don't really have an opinion on this. >> > > I'm not sure of the benefit of a "concurrent" namespace, since it wouldn't > contain the existing concurrency stuff. I think it's something to consider > only > for a big reorg which would break backward compatibility. IMO it would make > more > sense to leave this module as a top-level module for now (a sibling to > "threading", "multiprocessing"). > Unless there's some way of having the two namespaces (existing and concurrent-oriented) simultaneously coexist. A single implementation with two separate namespace mappings? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ "All I want for my birthday is another birthday" - Ian Dury, 1942-2000 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3148 ready for pronouncement
On May 28, 2010, at 8:12 PM, Steven D'Aprano wrote: On Sat, 29 May 2010 08:28:46 am Vinay Sajip wrote: I've not seen this mentioned, but on such a long thread I might have missed it: we already have a "__future__" module, as in from __future__ import with_statement and to my mind, this is a potential point of confusion with the term "future". [...] I'm not sure of the benefit of a "concurrent" namespace, since it wouldn't contain the existing concurrency stuff. I think it's something to consider only for a big reorg which would break backward compatibility. IMO it would make more sense to leave this module as a top-level module for now (a sibling to "threading", "multiprocessing"). I have suggested a way to move the existing concurrency stuff without breaking backwards compatibility, and Terry Reedy asked if it would work. I haven't seen any responses, either positive or negative. For the record, my suggestion was: for each concurrency modules: move it into the concurrency package add a top level module with the same name containing: # e.g. for threading from concurrency.threading import * Then in some future Python version, each top level module gets a PendingDeprecation warning, followed by a Deprecation warning some time later, and eventually in the indefinite future removal of the top level module. Leaving the futures module in the top level of the std lib is far more likely to confuse users than adding it to its own namespace. Compare: import __future__ import futures with: import __future__ import concurrency.futures In my opinion, it is high time for the std lib to pay more attention to the final Zen: Namespaces are one honking great idea -- let's do more of those! Yes, your suggestion for how to move things is the way we would want to do it, and in the back of my head, what we should do long term - just not right now. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bugfix releases should not change APIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry Reedy wrote: > I had the strong impression that there was a policy that x.y.z bugfix > releases should only fix bugs and not add new features and revise > current ones. The rationale, as I understood it, is that x.y.z releases > should be increasingly better implementations of a stable x.y feature > set. Adding features is 'bad' because code using a new feature will not > work in previous releases of the same x.y version. Changing features is > even worse because it may also break working code going forward. > > Because of this policy, an x.y.z Windows installer (I do not know about > others) deletes any earlier release of the same version. Also, there is > no What's New in Python x.y.z (relative to x.y.(z-1) since such should > be empty. Consequently, violations of the policy are pretty much silent > and well hidden. > > Yesterday, I spent two hours puzzling over the failure of my previously > 'green' test sequence that tested a custom test function. I finally > realized that the change was not due to anything I did (or undid), but a > change in 3.1.2 in the interaction of StringIO.truncate, > StringIO.getvalue, and print(x, StringIO()). (I should note the it is > the usual stability and quality of Python that made me slow to blame > Python rather than myself.) > > After filing > http://bugs.python.org/issue8840 > I was rather shocked to be told that the code-breaking and > policy-violating change was intentional because being 'more consistent > with other file-handling APIs out there' was somehow more important than > consistency within version releases. It also seems to me that discussion > of code-breaking API changes like this should involve more than one user > and one developer. See > http://bugs.python.org/issue6939 > > I have fixed my tests so they works in 3.1.2 and should work in other > 3.1 releases, but that would be a nuisance to test. Of course, I should > not have to worry about API changes within a version series. > > I think issue 8840 illustrates another reason for the bugfix-only > policy. New x.y features and docs are (nearly always) added before the > first beta. They can then be tested, discussed, and improved. This > 'cooking' does not occur for bugfix releases. For reasons I give in my > response on the tracker, I think the new behavior is buggy and the doc > deficient. > > So, I think > 1) the supposed bugfix-only policy should really be the policy; > 2) the violation in 3.1.2 should be reverted in 3.1.3, and the API > change reviewed in the normal 3.2 alpha/beta process. > I am curious as to what others think on both points. +1 on #1 as the general policy. I don't have enough skin in the game of the 3.1.x world to have an opinion about this specific breakage, but I have certainly seen other examples in the 2.x releases, where such a resolution was the appropriate outcome. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwAYEkACgkQ+gerLs4ltQ6AuQCfTk4mAl3ClpE1uu6nBRNrNjBc g54AoI2SObUNn/d0RvIbYj/vl7HDQbbj =U8z2 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bugfix releases should not change APIs
Terry Reedy wrote: > I had the strong impression that there was a policy that x.y.z bugfix > releases should only fix bugs and not add new features and revise > current ones. The rationale, as I understood it, is that x.y.z releases > should be increasingly better implementations of a stable x.y feature > set. Adding features is 'bad' because code using a new feature will not > work in previous releases of the same x.y version. Changing features is > even worse because it may also break working code going forward. > > Because of this policy, an x.y.z Windows installer (I do not know about > others) deletes any earlier release of the same version. Also, there is > no What's New in Python x.y.z (relative to x.y.(z-1) since such should > be empty. Consequently, violations of the policy are pretty much silent > and well hidden. > > Yesterday, I spent two hours puzzling over the failure of my previously > 'green' test sequence that tested a custom test function. I finally > realized that the change was not due to anything I did (or undid), but a > change in 3.1.2 in the interaction of StringIO.truncate, > StringIO.getvalue, and print(x, StringIO()). (I should note the it is > the usual stability and quality of Python that made me slow to blame > Python rather than myself.) > > After filing > http://bugs.python.org/issue8840 > I was rather shocked to be told that the code-breaking and > policy-violating change was intentional because being 'more consistent > with other file-handling APIs out there' was somehow more important than > consistency within version releases. It also seems to me that discussion > of code-breaking API changes like this should involve more than one user > and one developer. See > http://bugs.python.org/issue6939 > > I have fixed my tests so they works in 3.1.2 and should work in other > 3.1 releases, but that would be a nuisance to test. Of course, I should > not have to worry about API changes within a version series. > > I think issue 8840 illustrates another reason for the bugfix-only > policy. New x.y features and docs are (nearly always) added before the > first beta. They can then be tested, discussed, and improved. This > 'cooking' does not occur for bugfix releases. For reasons I give in my > response on the tracker, I think the new behavior is buggy and the doc > deficient. > > So, I think > 1) the supposed bugfix-only policy should really be the policy; > 2) the violation in 3.1.2 should be reverted in 3.1.3, and the API > change reviewed in the normal 3.2 alpha/beta process. > I am curious as to what others think on both points. > I think it shows how developers can "get worked over" if they are insufficiently vigilant. 1) I completely agree, and adduce as evidence the fact that something like this always seems to happen when the rule is broken; 2) But we may wish to release 3.1.2.1(?) which backports fixes from the 3.2 line but retains the file store semantics (which I am assured will be easy in the glorious reign of Hg). Surely some compatible "shim" layer could have been introduced? What is the process for ensuring that such API changes do *not* creep into maintenance releases? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ "All I want for my birthday is another birthday" - Ian Dury, 1942-2000 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bugfix releases should not change APIs
2010/5/28 Steve Holden : > Terry Reedy wrote: >> http://bugs.python.org/issue8840 >> I was rather shocked to be told that the code-breaking and >> policy-violating change was intentional because being 'more consistent >> with other file-handling APIs out there' was somehow more important than >> consistency within version releases. It also seems to me that discussion >> of code-breaking API changes like this should involve more than one user >> and one developer. This was discussed on the mailing list and this was produced: http://mail.python.org/pipermail/python-dev/2009-September/092247.html > What is the process for ensuring that such API changes do *not* creep > into maintenance releases? Generally developers are good about checking with the wider developer community about possibly incompatible changes. And given the link I posted above I don't consider this change to have "crept" in. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3148 ready for pronouncement
On 29/05/10 10:19, Jesse Noller wrote: In my opinion, it is high time for the std lib to pay more attention to the final Zen: Namespaces are one honking great idea -- let's do more of those! Yes, your suggestion for how to move things is the way we would want to do it, and in the back of my head, what we should do long term - just not right now. Yep, this is what I have been saying as well. 1. Using concurrency.futures rather than a top level futures module resolves the potential confusion with __future__ and stock market futures without inventing our own name for a well established computer science concept. 2. With the concurrency package in place following PEP 3148, we can separately consider the question of if/when/how to move other concurrency related modules (e.g. threading, multiprocessing, Queue) into that package at a later date. Since this topic keeps coming up, some reasoning along these lines should go into PEP 3148. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bugfix releases should not change APIs
On 29/05/10 09:03, Terry Reedy wrote: After filing http://bugs.python.org/issue8840 I was rather shocked to be told that the code-breaking and policy-violating change was intentional because being 'more consistent with other file-handling APIs out there' was somehow more important than consistency within version releases. It also seems to me that discussion of code-breaking API changes like this should involve more than one user and one developer. See http://bugs.python.org/issue6939 As Benjamin noted, that change was discussed on python-dev and actually made at Guido's direction. So, I think 1) the supposed bugfix-only policy should really be the policy; 2) the violation in 3.1.2 should be reverted in 3.1.3, and the API change reviewed in the normal 3.2 alpha/beta process. I am curious as to what others think on both points. The bugfix-only policy remains in place, but there are corner cases (such as this one) where the definition of what is and isn't a bug gets fuzzy and we need to make a judgment call as to whether to fix them or not. In particular, fixing bugs often runs the risk of breaking existing workarounds for those bugs. The decimal module, for example, has a standing policy to treat deviations from the standard as bugs, and this may lead to changes in the module if the standard is updated between two releases. This specific change was discussed on python-dev and the chance of breaking existing 3.1 code was deemed preferable to retaining semantics that were seen as broken, so I would be against reverting it. However, it may be worth modifying the policy to ensure that such exceptional bug fixes be mentioned prominently in the release notes and on the download page for that maintenance release. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bugfix releases should not change APIs
On 29/05/10 09:03, Terry Reedy wrote: After filing http://bugs.python.org/issue8840 I was rather shocked to be told that the code-breaking and policy-violating change was intentional because being 'more consistent with other file-handling APIs out there' was somehow more important than consistency within version releases. It also seems to me that discussion of code-breaking API changes like this should involve more than one user and one developer. See http://bugs.python.org/issue6939 For the record, I have added links to Guido's python-dev post to both of these tracker issues. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3148 ready for pronouncement
Steven D'Aprano wrote: I have suggested a way to move the existing concurrency stuff without breaking backwards compatibility, and Terry Reedy asked if it would work. I haven't seen any responses, either positive or negative. For the record, my suggestion was: for each concurrency modules: move it into the concurrency package add a top level module with the same name containing: # e.g. for threading from concurrency.threading import * In the past the problem identified with this approach has been that pickles produced with new pythons would not be readable by older pythons. I think this was the main reason that Brett's 3.0 library reorganization wasn't more radical. Theres a discussion if this here: http://mail.python.org/pipermail/python-dev/2008-May/079535.html http://mail.python.org/pipermail/stdlib-sig/2008-May/000303.html and a little more here: http://bugs.python.org/issue2775 Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
