Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
Hi, Le mardi 19 avril 2011 à 22:42 -0400, Terry Reedy a écrit : > On 4/19/2011 5:59 PM, victor.stinner wrote: > > >Issue #11223: Add threading._info() function providing informations > > about the > > thread implementation. > > Since this is being documented, making it part of the public api, why > does it have a leading underscore? Well, I suppose that this function might be specific to CPython. Do you think that this function can/should be implemented in PyPy, Jython and IronPython? Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Drop OS/2 and VMS support?
Various people wrote: > So please go ahead and add them to PEP 11. > If you want to post the "call for support" to Python Insider, let me know off > list and I will set you up with access. > Doesn't it have more chances of succeeding if posted to comp.lang.python, > simply? I say "all of the above". It could be good to find a OS/2 and OpenVMS developer mailing list as well, and post it there. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Telephone: +48 691 268 328 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Buildbots and faulthandler
Hi, The new faulthandler module is now fully functional and it has no more known issue. Its timeout feature is used on regrtest to dump the Python backtrace and exit if a test takes more than 1 hour. Using the regrtest timeout and faulthandler signal handlers (enable in regrtest), I started to collect tracebacks of all timeouts. Open issues: * test_threading.test_notify() on Windows http://bugs.python.org/issue11769 Not analyzed yet. I am unable to reproduce it in my VM. * test_mmap.test_large_offset() on Mac OS X http://bugs.python.org/issue11779 May be related (and fixed) by issue #11277 which has a patch. * test_threading.test_3_join_in_forked_from_thread() on Ubuntu http://bugs.python.org/issue11870 Only seen once. * test_mmap.test_big_buffer() on Mac OS X (it's a crash, bus error) http://bugs.python.org/issue11277 The origin of the problem was already identified, but the trace proves that faulthandler is able to catch correctly SIGBUS ;-) * test_ttk_guionly on Mac OS X (bus error) http://bugs.python.org/issue5120 Same as #11277 (the origin of the problem was already identified) Closed issues: * test_io.test_interrupted_write_text() on FreeBSD http://bugs.python.org/issue11859 (there was already enough information without faulthandler) * test_threadsignals.test_signals() on Mac OS X http://bugs.python.org/issue11768 Race condition (deadlock). * test_multiprocessing.test_async_error_callback() on many OSes http://bugs.python.org/issue8428 Race condition. I'm proud of #11768 (because I fixed it). The bug was a deadlock. It is usually very hard to reproduce such issue (a deadlock) and without faulthandler, the only available information was the name of the file. With faulthandler, we have not only the name of the test function, but also the full traceback of the hang, but also the traceback of all other threads. Thanks to the faulthandler trace of #8428, with the traceback of all threads, Charles-Francois Natali was able to understand and fix another complex race condition in multiprocessing (at shutdown). I also fixed other issues (not using faulthandler) and so ALL OUR 3.X BUILDBOTS ARE GREEN! ... ok ok, except: - sparc Debian 3.x: offline since 21 days - PPC Leopard 3.x : "hg clean" fails with twisted.internet.error.ProcessExitedAlready, but I think that except this buildbot specific issue, it must be green - x86 Windows7 3.x: the master lost the connection with the slave on test_cmd_line, but it should be a sporadic problem Anyway, if you see a "Timeout (1:00:00)!" or "Fatal error" (with a traceback) issue on a buildbot, please open a new issue (if it doesn't exist, search a least the name of the test file). If you have other problems related to regrtest timeout or faulthandler, contact me or open an issue. Finally, I'm very happy to see that my faulthandler module was as useful as I expected: with more informations, we are now able to identify race conditions. I hope that we will fix all remaining threading, signal and subprocess race conditions! Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
On Wed, Apr 20, 2011 at 6:20 PM, Victor Stinner wrote: > Hi, > > Le mardi 19 avril 2011 à 22:42 -0400, Terry Reedy a écrit : >> On 4/19/2011 5:59 PM, victor.stinner wrote: >> >> > Issue #11223: Add threading._info() function providing informations >> > about the >> > thread implementation. >> >> Since this is being documented, making it part of the public api, why >> does it have a leading underscore? > > Well, I suppose that this function might be specific to CPython. Do you > think that this function can/should be implemented in PyPy, Jython and > IronPython? I agree with your reasoning (and the leading underscore), but I suggest marking the docs with the implementation detail flag. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots and faulthandler
On Wed, Apr 20, 2011 at 7:37 PM, Victor Stinner wrote: > Finally, I'm very happy to see that my faulthandler module was as useful > as I expected: with more informations, we are now able to identify race > conditions. I hope that we will fix all remaining threading, signal and > subprocess race conditions! Excellent work :) Minor nit: the faulthandler docs could use an "impl-detail" block similar to the one in the dis module docs. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots and faulthandler
Victor Stinner wrote: Finally, I'm very happy to see that my faulthandler module was as useful as I expected [...] Congratulations! Nice work. ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
On 08:20 am, [email protected] wrote: Hi, Le mardi 19 avril 2011 � 22:42 -0400, Terry Reedy a �crit : On 4/19/2011 5:59 PM, victor.stinner wrote: >Issue #11223: Add threading._info() function providing informations about the > thread implementation. Since this is being documented, making it part of the public api, why does it have a leading underscore? Can I propose something wildly radical? Maybe the guarantees made about whether an API will be available in future versions of Python (ostensibly what "public" vs "private" is for) should not be tightly coupled to the decision about whether to bother to explain what an API does? Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
2011/4/20 : > On 08:20 am, [email protected] wrote: >> >> Hi, >> >> Le mardi 19 avril 2011 à 22:42 -0400, Terry Reedy a écrit : >>> >>> On 4/19/2011 5:59 PM, victor.stinner wrote: >>> >>> > Issue #11223: Add threading._info() function providing informations >>> > about the >>> > thread implementation. >>> >>> Since this is being documented, making it part of the public api, why >>> does it have a leading underscore? >> > > Can I propose something wildly radical? Maybe the guarantees made about > whether an API will be available in future versions of Python (ostensibly > what "public" vs "private" is for) should not be tightly coupled to the > decision about whether to bother to explain what an API does? With what criteria would you propose to replace it with? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
Le mercredi 20 avril 2011 à 20:24 +1000, Nick Coghlan a écrit : > On Wed, Apr 20, 2011 at 6:20 PM, Victor Stinner > wrote: > > Hi, > > > > Le mardi 19 avril 2011 à 22:42 -0400, Terry Reedy a écrit : > >> On 4/19/2011 5:59 PM, victor.stinner wrote: > >> > >> >Issue #11223: Add threading._info() function providing informations > >> > about the > >> > thread implementation. > >> > >> Since this is being documented, making it part of the public api, why > >> does it have a leading underscore? > > > > Well, I suppose that this function might be specific to CPython. Do you > > think that this function can/should be implemented in PyPy, Jython and > > IronPython? > > I agree with your reasoning (and the leading underscore), but I > suggest marking the docs with the implementation detail flag. I chose to return a dict to be flexible: any thread implementation may add new specific keys. There is just one mandatory key: 'name', name of the thread implementation (nt, os2, pthread or solaris for CPython 3.3). http://docs.python.org/dev/py3k/library/threading.html#threading._info After thinking twice, PyPy, Jython and IronPython should be able to fill the only required key (name). PyPy reuses the code from CPython, so it can just reuse the same names (pthread or nt). I suppose that IronPython uses Windows threads and semaphores, so it can use the name 'nt'. For Jython, I don't know if Jython is able to get the name of the thread implementation used by the JVM. If it is not, something like 'jvm' can be used. threading._info() is a function: it can call other functions to retrieve informations (it is not hardcoded or initialized at startup). What do you think? Can I remove the leading underscore? :-) Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
On 01:11 pm, [email protected] wrote: 2011/4/20 : On 08:20 am, [email protected] wrote: Hi, Le mardi 19 avril 2011 � 22:42 -0400, Terry Reedy a �crit : On 4/19/2011 5:59 PM, victor.stinner wrote: > Issue #11223: Add threading._info() function providing informations > about the > thread implementation. Since this is being documented, making it part of the public api, why does it have a leading underscore? Can I propose something wildly radical? Maybe the guarantees made about whether an API will be available in future versions of Python (ostensibly what "public" vs "private" is for) should not be tightly coupled to the decision about whether to bother to explain what an API does? With what criteria would you propose to replace it with? I'm not sure what kind of criteria you're thinking of. I'm only suggesting that: 1) Document whatever you want (preferably as much as possible) 2) Make "privateness" defined by whether there is a leading underscore It is a big mistake to think that documentation isn't necessary for things just because you don't want application developers to use them. Maintainers benefit from it just as much. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
On Wed, 20 Apr 2011 08:11:48 -0500, Benjamin Peterson wrote: > 2011/4/20 : > > On 08:20 am, [email protected] wrote: > >> > >> Hi, > >> > >> Le mardi 19 avril 2011 à 22:42 -0400, Terry Reedy a écrit : > >>> > >>> On 4/19/2011 5:59 PM, victor.stinner wrote: > >>> > >>> >   Issue #11223: Add threading._info() function providing informations > >>> > about the > >>> > thread implementation. > >>> > >>> Since this is being documented, making it part of the public api, why > >>> does it have a leading underscore? > >> > > > > Can I propose something wildly radical?  Maybe the guarantees made about > > whether an API will be available in future versions of Python (ostensibly > > what "public" vs "private" is for) should not be tightly coupled to the > > decision about whether to bother to explain what an API does? > > With what criteria would you propose to replace it with? I believe Jean-Paul was suggesting that just because an interface is marked as "private" and might go away or change in the future does not automatically mean it must also be undocumented. To which I say +1. (Note that we already have a whole module like that: test.support.) -- R. David Murray http://www.bitdance.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
2011/4/20 R. David Murray : > On Wed, 20 Apr 2011 08:11:48 -0500, Benjamin Peterson > wrote: >> 2011/4/20 : >> > On 08:20 am, [email protected] wrote: >> >> >> >> Hi, >> >> >> >> Le mardi 19 avril 2011 à 22:42 -0400, Terry Reedy a écrit : >> >>> >> >>> On 4/19/2011 5:59 PM, victor.stinner wrote: >> >>> >> >>> > Issue #11223: Add threading._info() function providing informations >> >>> > about the >> >>> > thread implementation. >> >>> >> >>> Since this is being documented, making it part of the public api, why >> >>> does it have a leading underscore? >> >> >> > >> > Can I propose something wildly radical? Maybe the guarantees made about >> > whether an API will be available in future versions of Python (ostensibly >> > what "public" vs "private" is for) should not be tightly coupled to the >> > decision about whether to bother to explain what an API does? >> >> With what criteria would you propose to replace it with? > > I believe Jean-Paul was suggesting that just because an interface is > marked as "private" and might go away or change in the future does not > automatically mean it must also be undocumented. To which I say +1. > (Note that we already have a whole module like that: test.support.) I think that test.* as a special case is private stuff. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
2011/4/20 Victor Stinner : > Le mercredi 20 avril 2011 à 20:24 +1000, Nick Coghlan a écrit : >> On Wed, Apr 20, 2011 at 6:20 PM, Victor Stinner >> wrote: >> > Hi, >> > >> > Le mardi 19 avril 2011 à 22:42 -0400, Terry Reedy a écrit : >> >> On 4/19/2011 5:59 PM, victor.stinner wrote: >> >> >> >> > Issue #11223: Add threading._info() function providing informations >> >> > about the >> >> > thread implementation. >> >> >> >> Since this is being documented, making it part of the public api, why >> >> does it have a leading underscore? >> > >> > Well, I suppose that this function might be specific to CPython. Do you >> > think that this function can/should be implemented in PyPy, Jython and >> > IronPython? >> >> I agree with your reasoning (and the leading underscore), but I >> suggest marking the docs with the implementation detail flag. > > I chose to return a dict to be flexible: any thread implementation may > add new specific keys. There is just one mandatory key: 'name', name of > the thread implementation (nt, os2, pthread or solaris for CPython 3.3). How about using a structseq ala sys.float_info or sys.long_info? (In fact, we might want to put this in sys.) -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: os.sendfile(): on Linux if offset parameter is passed as NULL we were
No we haven't. I plan to make a unique commit for offset=None on Linux and a serie of other tests I have implemented for py-sendfile module [1]. In details test for small file, empty file and (most important) large file: http://code.google.com/p/py-sendfile/source/browse/trunk/test/test_sendfile.py?spec=svn68&r=68#296 [1] http://code.google.com/p/py-sendfile --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil 2011/4/19 Antoine Pitrou : > On Tue, 19 Apr 2011 09:47:21 +0200 > giampaolo.rodola wrote: > >> http://hg.python.org/cpython/rev/8c49f7fbba1d >> changeset: 69437:8c49f7fbba1d >> user: Giampaolo Rodola' >> date: Tue Apr 19 09:47:16 2011 +0200 >> summary: >> os.sendfile(): on Linux if offset parameter is passed as NULL we were >> erroneously returning a (bytes_sent, None) tuple instead of bytes_sent > > Do we have tests for this? > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: os.sendfile(): on Linux if offset parameter is passed as NULL we were
On 4/20/2011 2:09 PM, Giampaolo Rodolà wrote: No we haven't. "No we haven't" what? Such out-of-context responses exemplify why top-posting is greatly inferior for readers, who vastly outnumber the one writer. If that line had been put where it belongs, right after what it refers to, it would have been clear. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
On 4/20/2011 12:57 PM, Benjamin Peterson wrote: On 4/19/2011 5:59 PM, victor.stinner wrote: Issue #11223: Add threading._info() function providing informations about the thread implementation. How about using a structseq ala sys.float_info or sys.long_info? (In fact, we might want to put this in sys.) sys.thread_info strikes me as a good idea too. The only thing required should be 'name' with '' at the default indicating no threading. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
On 4/20/2011 10:11 AM, [email protected] wrote: On 01:11 pm, [email protected] wrote: It is a big mistake to think that documentation isn't necessary for things just because you don't want application developers to use them. Maintainers benefit from it just as much. Maintainers can and will read the doc string. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
Le mercredi 20 avril 2011 à 11:57 -0500, Benjamin Peterson a écrit : > 2011/4/20 Victor Stinner : > > Le mercredi 20 avril 2011 à 20:24 +1000, Nick Coghlan a écrit : > >> On Wed, Apr 20, 2011 at 6:20 PM, Victor Stinner > >> wrote: > >> > Hi, > >> > > >> > Le mardi 19 avril 2011 à 22:42 -0400, Terry Reedy a écrit : > >> >> On 4/19/2011 5:59 PM, victor.stinner wrote: > >> >> > >> >> >Issue #11223: Add threading._info() function providing > >> >> > informations about the > >> >> > thread implementation. > >> >> > >> >> Since this is being documented, making it part of the public api, why > >> >> does it have a leading underscore? > >> > > >> > Well, I suppose that this function might be specific to CPython. Do you > >> > think that this function can/should be implemented in PyPy, Jython and > >> > IronPython? > >> > >> I agree with your reasoning (and the leading underscore), but I > >> suggest marking the docs with the implementation detail flag. > > > > I chose to return a dict to be flexible: any thread implementation may > > add new specific keys. There is just one mandatory key: 'name', name of > > the thread implementation (nt, os2, pthread or solaris for CPython 3.3). > > How about using a structseq ala sys.float_info or sys.long_info? (In > fact, we might want to put this in sys.) Would you prefer something like the following example? >>> sys.thread_info sys.threadinfo(name='pthread', 'lock_implementation': 'semaphore', version: 'NPTL 2.11.2') >>> sys.thread_info sys.threadinfo(name='nt', 'lock_implementation': 'semaphore', version: '') >>> sys.thread_info sys.threadinfo(name='os2', 'lock_implementation': '', version: '') Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots and faulthandler
On 4/20/2011 7:57 AM, Ethan Furman wrote: Victor Stinner wrote: Finally, I'm very happy to see that my faulthandler module was as useful as I expected [...] Congratulations! Nice work. Ditto. Multiple pats on the back. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
2011/4/20 Victor Stinner : > Le mercredi 20 avril 2011 à 11:57 -0500, Benjamin Peterson a écrit : >> How about using a structseq ala sys.float_info or sys.long_info? (In >> fact, we might want to put this in sys.) > > Would you prefer something like the following example? > sys.thread_info > sys.threadinfo(name='pthread', 'lock_implementation': 'semaphore', > version: 'NPTL 2.11.2') sys.thread_info > sys.threadinfo(name='nt', 'lock_implementation': 'semaphore', version: > '') sys.thread_info > sys.threadinfo(name='os2', 'lock_implementation': '', version: '') The only things that would improve that beautiful sight would be s/threadinfo/thread_info/. :) -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the
On Wed, 20 Apr 2011 17:03:19 -0500 Benjamin Peterson wrote: > 2011/4/20 Victor Stinner : > > Le mercredi 20 avril 2011 à 11:57 -0500, Benjamin Peterson a écrit : > >> How about using a structseq ala sys.float_info or sys.long_info? (In > >> fact, we might want to put this in sys.) > > > > Would you prefer something like the following example? > > > sys.thread_info > > sys.threadinfo(name='pthread', 'lock_implementation': 'semaphore', > > version: 'NPTL 2.11.2') > sys.thread_info > > sys.threadinfo(name='nt', 'lock_implementation': 'semaphore', version: > > '') > sys.thread_info > > sys.threadinfo(name='os2', 'lock_implementation': '', version: '') > > The only things that would improve that beautiful sight would be > s/threadinfo/thread_info/. :) And None instead of the empty string when a value is unknown/irrelevant. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
