This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients brett.cannon, jcdlr, om364@, terry.reedy
Date 2018-09-23.20:32:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1537734747.87.0.956365154283.issue33065@psf.upfronthosting.co.za>
In-reply-to
Content
The problem is not limited to user modules.  In duplicate issue #34609 (not closed), the same traceback was obtained with unittest.  I also got the same with asyncio.  There will not be a problem if the module is already loaded in sys.modules, so that importlib is not invoked.

The traceback is obscured by the fact that the executed importlib is frozen, leaving it traceable, but the code not directly available.  Hence the code is omitted from the debugger display and traceback.  However, the line numbers can be used to find the code within Lib/importlib._bootstrap.py.  Using current master (updated last night), the functions and lines executed by stepping with import unittest are (as expected when reading the code, up to the unexpected exception):

_find_and_load: 980
ModuleLock.__init__: 144, 145
ModuleLock.__enter__: 148
_get_module_lock: 163-168, 170-171, 174: lock = _ModuleLock(name)
_ModuleLock.__init__: 59: self.lock = _thread.allocate_lock()

IDLE's visual debugger has name-value panels for locals, including non-locals, and for globals.  It uses repr to gets value representations.  The locals panel is displayed by default.

Before line 174, 'lock' is bound to None, so before executing line 59, the display is "lock:None\nname:'unittest'".  After line 59, debugger apparently tries to get the repr of the in-process instance.  Since the call in 174 has not completed and should not have rebound 'lock' to the instance, I do not understand why.  (Brett, I now understand what you wrote to be pointing as this puzzle also.)  ppperry, additional light would be appreciated.

Given that debugger does try to get the repr of the instance, both Brett Cannon, here, and (ppperry), on duplicate issue #34609 (now closed), have pointed out that _ModuleLock.__repr__ uses self.name:
        return '_ModuleLock({!r}) at {}'.format(self.name, id(self))

I verified that updating the locals panel is the problem by starting over and turning the panel off until past the the assignment to self.name, at which point, the lock value is "_ModuleLock('unittest') at ...".

Debugger should be prepared for repr to fail, and display something informative.  In the present case, perhaps

repr raised "AttributeError: '_ModuleLock' object has no attribute 'name'"

with a check for whether the exception message contains "'.*' object" (and add such if not present).
History
Date User Action Args
2018-09-23 20:32:27terry.reedysetrecipients: + terry.reedy, brett.cannon, jcdlr, om364@
2018-09-23 20:32:27terry.reedysetmessageid: <1537734747.87.0.956365154283.issue33065@psf.upfronthosting.co.za>
2018-09-23 20:32:27terry.reedylinkissue33065 messages
2018-09-23 20:32:27terry.reedycreate