Re: [Python-Dev] short-circuiting runtime errors/exceptions in python debugger.
On Fri, Oct 26, 2018 at 04:18:37PM -0700, Ed Peschko wrote: > all, > > I was debugging a very long script that I was not all that familiar > with, and I was doing my familiar routine of being very careful in > evaluating expressions to make sure that I didn't hit such statements > as: > > TypeError: unsupported operand type(s) for +: 'int' and 'str' > > anyways the script has a runtime of hours, so this was tedious work, > and I hit one-too-many times where I missed a condition and had to > start all over again. Obviously you weren't careful enough :-) You know you can set breakpoints in the debugger? You don't have to single-step all the way through from the beginning. It isn't clear from your post how experienced you are. [...] > So I was wondering if it would be possible to keep that context around > if you are in the debugger and rewind the execution point to before > the statement was triggered. I think what you are looking for is a reverse debugger[1] also known as a time-travel debugger. https://softwareengineering.stackexchange.com/questions/181527/why-is-reverse-debugging-rarely-used There's a Python implementation, but I've never used it: https://morepypy.blogspot.com/2016/07/reverse-debugging-for-python.html [...] > I can't emphasize exactly how much time and effort this would save. That's what people say. But not everyone is a fan -- there are apparently memory consumption and stability issues with reverse debugging. There are people who love it, and those who don't. > so - is this possible? just from my experiments it doesn't look so, > but perhaps there is a trick out there that would give this > functionality.. > > if it isn't possible, how easy would it be to implement? If it isn't possible, it would be very difficult to implement :-) [1] A reverse debugger is not the process of adding bugs to code *wink* -- 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
[Python-Dev] short-circuiting runtime errors/exceptions in python debugger.
all, I was debugging a very long script that I was not all that familiar with, and I was doing my familiar routine of being very careful in evaluating expressions to make sure that I didn't hit such statements as: TypeError: unsupported operand type(s) for +: 'int' and 'str' anyways the script has a runtime of hours, so this was tedious work, and I hit one-too-many times where I missed a condition and had to start all over again. So that got me thinking: the main problem with exceptions and runtime errors is that they short-circuit the program context. You have this context, but you can't change it to avoid the failure; ie: with 1. aa = 'a' 2. bb = 1 + a 3. print bb you'll never get to line 3 if you go through line 2. If you are lucky you can catch it, modify aa to be an integer to continue, otherwise your only recourse is to start over again. So I was wondering if it would be possible to keep that context around if you are in the debugger and rewind the execution point to before the statement was triggered. so you could say: python script.py (Pdb) c then hit the exception, say: (Pdb) aa = 2 then run again (Pdb) c to work your way through the exception point. You could then fix the script inline in an editor. I can't emphasize exactly how much time and effort this would save. At best, debugging these types of issues is annoying, at worst it is excruciating, because they are sometimes intermittent and are not easily repeatable. Using RemotePdb or Pdb to attach to a long-running process and having the assurance that the underlying script won't die because of an inane coding error would do wonders for the reliability and integrity of scripting. so - is this possible? just from my experiments it doesn't look so, but perhaps there is a trick out there that would give this functionality.. if it isn't possible, how easy would it be to implement? Thanks much, Ed ___ 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] PEP 543-conform TLS library
Hello Python Dev, I posted the following to python-ideas but here may be a more suitable place. I apologize if cross posting bothers anyone. I have implemented an (I believe) PEP 543-conform TLS library and released TLS support in the latest version yesterday: https://github.com/Synss/python-mbedtls/tree/0.13.0 https://pypi.org/project/python-mbedtls/0.13.0/ As far as I know, I am the first one to follow PEP 543. So one point is that the API works. However, I have a couple of questions regarding the PEP: - I do not know what to do in `TLSWrappedBuffer.do_handshake()`. The full TLS handshake requires writing to the server, reading back, etc., (ClientHello, ServerHello, KeyExchange, etc.), which cannot be accomplished in a single buffer. For now, I am doing the handshake in `TLSWrappedSocket.do_handshake()`: I set the BIO to using the socket directly, then perform the handshake on the socket thus entirely bypassing the TLSWrappedBuffer. Once this is done, I swap the BIO to using the buffer and go on encrypting and decrypting from the buffer. That is, the encrypted communication is buffered. - The PEP sometimes mentions an "input buffer" and an "output buffer", and some other times just "the buffer". I believe that both implementations are possible. That is, with two different buffers for input and output, or a single one. I have implemented it with a single circular buffer (that is a stream after all). What the PEP is expecting is nonetheless not clear to me. So, can anybody clarify these two points from the PEP? Or should I just address Cory Benfield (who does not seem very active anymore lately) and Christian Heimes directly? Cheers, Mathias ___ 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 Language Governance Proposals
As a piece of pure experiential data based on some years trying to herd the PSF cats, if python-dev can find a way of running its activities without votes needing to be taken I would really emphasise the benefits of the lack of such administration. If voting is required, please consider using the PSF to manage such activity. Following the debate with interest, but mostly lurking due to my usual absence of skin in the game. Bonne chance! regards Steve Steve Holden On Fri, Oct 26, 2018 at 6:17 PM, Brett Cannon wrote: > > > On Tue, 23 Oct 2018 at 13:20, Jeroen Demeyer wrote: > >> What is the timeframe for the installation of the new governance? In >> other words, when will it be possible to review PEPs? >> > > PEP 8001 outlines the voting for the governance models which includes a > planned schedule for that vote. After that it will vary depending on which > governance model is chosen as some of them require electing people to > positions while others don't. The overall goal is to have the whole ting > resolved no later than probably March (but probably sooner than that). > Basically this should not be a new thing come PyCon US in May. > > But since you're asking about wanting to "review PEPs", you can review > them now. There hasn't been much change to them lately so they are pretty > stable at this point. > > ___ > 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 Language Governance Proposals
On Tue, 23 Oct 2018 at 13:20, Jeroen Demeyer wrote: > What is the timeframe for the installation of the new governance? In > other words, when will it be possible to review PEPs? > PEP 8001 outlines the voting for the governance models which includes a planned schedule for that vote. After that it will vary depending on which governance model is chosen as some of them require electing people to positions while others don't. The overall goal is to have the whole ting resolved no later than probably March (but probably sooner than that). Basically this should not be a new thing come PyCon US in May. But since you're asking about wanting to "review PEPs", you can review them now. There hasn't been much change to them lately so they are pretty stable at this point. ___ 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-10-19 - 2018-10-26) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open6823 (-12) closed 40005 (+62) total 46828 (+50) Open issues with patches: 2716 Issues opened (34) == #25750: tp_descr_get(self, obj, type) is called without owning a refer https://bugs.python.org/issue25750 reopened by serhiy.storchaka #35028: Off by one error in cgi.FieldStorage(max_num_fields) https://bugs.python.org/issue35028 opened by Matthew Belisle #35031: test_asyncio test_start_tls_server_1 fails in AMD64 FreeBSD CU https://bugs.python.org/issue35031 opened by pablogsal #35032: Remove the videos from faq/Windows https://bugs.python.org/issue35032 opened by matrixise #35033: Column or row spanning cells are not implemented. https://bugs.python.org/issue35033 opened by mdk #35035: Documentation for email.utils is named email.util.rst https://bugs.python.org/issue35035 opened by zmwangx #35037: PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC https://bugs.python.org/issue35037 opened by scoder #35040: [functools] provide an async-compatible version of functools.l https://bugs.python.org/issue35040 opened by Liran Nuna #35042: Use the role :pep: for the PEP \d+ https://bugs.python.org/issue35042 opened by matrixise #35045: test_min_max_version (test.test_ssl.ContextTests) fails on Fed https://bugs.python.org/issue35045 opened by cstratak #35047: Better error messages in unittest.mock https://bugs.python.org/issue35047 opened by Petter S #35048: Can't reassign __class__ despite the assigned class having ide https://bugs.python.org/issue35048 opened by bup #35050: Off-by-one bug in AF_ALG https://bugs.python.org/issue35050 opened by christian.heimes #35052: Coverity scan: copy/paste error in Lib/xml/dom/minidom.py https://bugs.python.org/issue35052 opened by cstratak #35054: Add more index entries for symbols https://bugs.python.org/issue35054 opened by serhiy.storchaka #35055: Error when we try to download the epub archive https://bugs.python.org/issue35055 opened by matrixise #35056: Test leaks of memory not managed by Python allocator https://bugs.python.org/issue35056 opened by serhiy.storchaka #35058: Unable to Install Python on Windows https://bugs.python.org/issue35058 opened by alexbach #35059: Convert Py_INCREF() and PyObject_INIT() to inlined functions https://bugs.python.org/issue35059 opened by vstinner #35061: Specify libffi.so soname for ctypes https://bugs.python.org/issue35061 opened by tturbs #35062: io.IncrementalNewlineDecoder assign out-of-range value to bitw https://bugs.python.org/issue35062 opened by xiang.zhang #35063: Checking for abstractmethod implementation fails to consider M https://bugs.python.org/issue35063 opened by Antony.Lee #35064: COUNT_ALLOCS build export inc_count() and dec_count() function https://bugs.python.org/issue35064 opened by vstinner #35065: Reading received data from a closed TCP stream using `StreamRe https://bugs.python.org/issue35065 opened by vxgmichel #35066: Inconsistency between dangling '%' handling in time.strftime() https://bugs.python.org/issue35066 opened by mjsaah #35067: Use vswhere instead of _distutils_findvs https://bugs.python.org/issue35067 opened by steve.dower #35068: [2.7] Possible crashes due to incorrect error handling in pyex https://bugs.python.org/issue35068 opened by ZackerySpytz #35070: test_posix fails on macOS 10.14 Mojave https://bugs.python.org/issue35070 opened by barry #35071: Canot send real string from c api to module (corrupted string) https://bugs.python.org/issue35071 opened by Yhojann Aguilera #35072: re.sub does not play nice with chr(92) https://bugs.python.org/issue35072 opened by Samuel Warfield #35074: source install [3.7.1] on debian jessie https://bugs.python.org/issue35074 opened by foxleoly #35075: Doc: pprint example uses dead URL https://bugs.python.org/issue35075 opened by inada.naoki #35076: FAIL: test_min_max_version (test.test_ssl.ContextTests) with l https://bugs.python.org/issue35076 opened by jean-michel #35077: Make TypeError message less ambiguous https://bugs.python.org/issue35077 opened by coyot Most recent 15 issues with no replies (15) == #35076: FAIL: test_min_max_version (test.test_ssl.ContextTests) with l https://bugs.python.org/issue35076 #35075: Doc: pprint example uses dead URL https://bugs.python.org/issue35075 #35068: [2.7] Possible crashes due to incorrect error handling in pyex https://bugs.python.org/issue35068 #35067: Use vswhere instead of _distutils_findvs https://bugs.python.org/issue35067 #35064: COUNT_ALLOCS build export inc_count() and dec_count() function https://bugs.python.org/issue35064 #35063: Checking for abstractmethod implementation fails to consider M https://bugs.python.org/issue35063
Re: [Python-Dev] "Deprecation" of os.system in favor of subprocess?
Thanks for asking a question that triggered an enlightening discussion! On 10/25/2018 5:13 PM, Stephane Wirtel wrote: > Hi all, > > After your feedback, I have my answer. > > I understand the your points of view and I don't want to change any part > of code for os.system and subprocess, I don't want to deprecate > os.system in favor of subprocess. I just wanted to know your opinion > about this point. > > +1 to use os.system when we only need a call without portability, just a > quick code. > > +1 for subprocess for the portability. > > Thank you so much for your patience/time and your explanations. > > Stéphane ___ 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
