[issue33065] IDLE debugger: failure stepping through module loading
Timothy Geiser added the comment: This issue is still open, 8.5 months after identifying the underlying cause. What needs done to get a fix for this merged? Manual testing, or adding test cases? Anything I can do to help? I have 3.9.1 successfully built on a Raspberry Pi that I can reproduce the issue on, as well as reproduce the fix Terry suggested in msg366981. -- ___ Python tracker <https://bugs.python.org/issue33065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33065] IDLE debugger: failure stepping through module loading
Timothy Geiser added the comment: Looks good when testing both the minimal example and the pgpdump original case. I added the import at the top, and changed the original line 173 from value = repr(value) to value = reprlib.repr(value) This is based on lines 160 & 161 in reprlib (we need a Repr instance, but reprlib makes it's own for us to use). I get a nice boring and not-crashy result in the debug window for Locals: data b'' self Thanks for the fix, Terry! I shouldn't expect any strange side-effects from this, should I? -- ___ Python tracker <https://bugs.python.org/issue33065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33065] IDLE debugger: failure stepping through module loading
Timothy Geiser added the comment:
It looks like the IDLE debugger seems to call repr on objects to present in the
Locals list, even before they've been properly initialized. If __repr__ needs
to refer to variables that don't exist until __init__ is done (and I don't
think it's unreasonable for __repr__ to assume that __init__ is indeed
finished), the debugger either needs wait until __init__ has completed on any
given instance before trying to repr it, or otherwise needs to catch a
potentially very wide range of exceptions that might be raised from calling
__repr__ so early. I prefer the latter solution, since any buggy code that
(effectively) crashes on it's __repr__ (for whatever reason) will probably
bring the debugger to it's knees.
I played around with pdb directly and can sort of get the same thing if I ask
for __repr__ too early:
1 Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit
(AMD64)] on win32
2 Type "help", "copyright", "credits" or "license" for more information.
3 >>> import data
4 >>> import pdb
5 >>> pdb.run("data.BinaryData(b'some data')")
6 > (1)()
7 (Pdb) step
8 --Call--
9 > c:\users\geitd\documents\python\data.py(4)__init__()
10 -> def __init__(self, data):
11 (Pdb) p self
12 (Pdb) p BinaryData.__repr__(self)
13 *** AttributeError: 'BinaryData' object has no attribute 'length'
14 (Pdb) step
15 > c:\users\geitd\documents\python\data.py(5)__init__()
16 -> if not data:
17 (Pdb) step
18 > c:\users\geitd\documents\python\data.py(7)__init__()
19 -> if len(data) <= 1:
20 (Pdb) step
21 > c:\users\geitd\documents\python\data.py(10)__init__()
22 -> self.data = data
23 (Pdb) step
24 > c:\users\geitd\documents\python\data.py(11)__init__()
25 -> self.length = len(data)
26 (Pdb) p self
27 (Pdb) p BinaryData.__repr__(self)
28 *** AttributeError: 'BinaryData' object has no attribute 'length'
29 (Pdb) step
30 --Return--
31 > c:\users\geitd\documents\python\data.py(11)__init__()->None
32 -> self.length = len(data)
33 (Pdb) p self
34
35 (Pdb) p BinaryData.__repr__(self)
36 ''
Note that line 11 didn't return anything, but didn't have any bad results,
whereas the way I phrased line 12 gave the exact same error the IDLE debugger
threw.
Lines 26 and 27 towards the end of __init__ came out the same, but after the
--Return-- on 30, either phrasing gives what you'd expect.
I suppose the TL;DR is to take the mechanism that gives the correct behavior of
'p self' in pdb and copy it over to the IDLE debugger (or whatever other
mechanism is necessary).
Is this enough for you to work from?
--
Added file: https://bugs.python.org/file49082/data.py
___
Python tracker
<https://bugs.python.org/issue33065>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33065] IDLE debugger: failure stepping through module loading
Timothy Geiser added the comment: I wish I could be more helpful than to just pipe up with a "this bug affects me, too," note, but wanted to poke this bug report since it's been dormant for 14 months. With Python 3.8.2 I tried using the pgpdump module (version 1.5, installed from pip) on Windows 10 and wanted to step through how it worked. As soon as I enabled the debugger in IDLE it stopped working, throwing a very similar stack trace. Here's the MWE: >>> import pgpdump >>> [DEBUG ON] >>> pgpdump.BinaryData(b'') Traceback (most recent call last): File "", line 1, in pgpdump.BinaryData(b'') File "C:\Python38\lib\site-packages\pgpdump\data.py", line 13, in __init__ if not data: File "C:\Python38\lib\site-packages\pgpdump\data.py", line 13, in __init__ if not data: File "C:\Python38\lib\bdb.py", line 88, in trace_dispatch return self.dispatch_line(frame) File "C:\Python38\lib\bdb.py", line 112, in dispatch_line self.user_line(frame) File "C:\Python38\lib\idlelib\debugger.py", line 24, in user_line self.gui.interaction(message, frame) AttributeError: 'BinaryData' object has no attribute 'length' This error only occurs when the Locals checkbox in the debugging window is checked - it runs as expected as long as Locals is unchecked (this minimum [not]working example throws a "pgpdump.utils.PgpdumpException: no data to parse" error, as it should). A longer example with actual data will run for several steps while Locals is unchecked, but fails with the first Step once Locals is checked. A side note is that the specific error here is that the class BinaryData is being asked about it's 'length', rather than the OP's error of _ModuleLock not having a 'name' Is there anything else I can do to help fix this, given that I'm not familiar with programming bdb or the IDLE debugger GUI? -- nosy: +geitda ___ Python tracker <https://bugs.python.org/issue33065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24892] bytes.join() won't take it's own type as the argument
Timothy Geiser added the comment: I believe the special case has already been made: iterating over bytes-like objects returns ints. Natually, join() should take the same thing. Also, constructor bytearray(iterable_of_ints), the mutable-sequence expression ba[i:j:k] = t, and the function ba.extend(t) with t as an iterable of ints. It's the s.join(t) that's different than all these others. Again: ba = bytearray(b'barbaz') ba[0:4:2] = b'ft' ba bytearray(b'fatbaz') ba.extend(b'foo') ba bytearray(b'fatbazfoo') ba.join(b'not_this_though') Traceback (most recent call last): File pyshell#32, line 1, in module ba.join(b'not_this_though') TypeError: sequence item 0: expected a bytes-like object, int found I'll go ahead argue that it's exactly backwards as is. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24892 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24892] bytes.join() won't take it's own type as the argument
New submission from Timothy Geiser: You can't join bytes on another bytes object. (Everything below applies to bytearray, as well) x = b'foo' y = b'barbaz' x.join(y) Traceback (most recent call last): File pyshell#2, line 1, in module x.join(y) TypeError: sequence item 0: expected a bytes-like object, int found But this is fine for strings, and gives you exactly what you'd expect x = 'foo' y = 'barbaz' x.join(y) 'bfooafoorfoobfooafooz' y.join(x) 'fbarbazobarbazo' The best work-around I could think of was x = b'foo' y = b'barbaz' x.join(y[i:i+1] for i in range(len(y))) b'bfooafoorfoobfooafooz' y.join(x[i:i+1] for i in range(len(x))) b'fbarbazobarbazo' That just doesn't feel nearly pythonic enough, considering that the string version works as expected. I'm not even sure what the right solution here is, since the problem is that the iterator for a bytes object returns ints, not length-one bytes objects. Do we need another signature for the bytes.join method that takes byte-like objects and does what I'm describing here? -- components: Interpreter Core messages: 248799 nosy: geitda priority: normal severity: normal status: open title: bytes.join() won't take it's own type as the argument type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24892 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
