pdb.main is unnecessarily complicated #88720

Activity

1. jaraco commented on Jul 2, 2021

   

   jaraco

   on Jul 2, 2021

   MemberAuthor

   More actions

   While investigating bpo-44461, I observed some complexities to the current pdb.main implementation, some of which likely contributed to the bug being present.

   • variables are initialized to defaults (

     cpython/Lib/pdb.py

     Lines 1677 to 1678 in ec8759b

     	commands = []
     	run_as_module = False

     ) and then mutated (

     cpython/Lib/pdb.py

     Lines 1684 to 1686 in ec8759b

     	commands.append(optarg)
     	elif opt in ['-m']:
     	run_as_module = True

     ) based on other variables.

   • mainpyfile is conditionally mutated based on previous values of conditionally mutated variables (

     cpython/Lib/pdb.py

     Line 1696 in ec8759b

     mainpyfile = os.path.realpath(mainpyfile)

     ).

   • There are three different blocks of code (

     cpython/Lib/pdb.py

     Lines 1690 to 1691 in ec8759b

     	print('Error:', mainpyfile, 'does not exist')
     	sys.exit(1)

     ,

     cpython/Lib/pdb.py

     Lines 1696 to 1698 in ec8759b

     	mainpyfile = os.path.realpath(mainpyfile)
     	# Replace pdb's dir with script's dir in front of module search path.
     	sys.path[0] = os.path.dirname(mainpyfile)

     , and

     cpython/Lib/pdb.py

     Line 1711 in ec8759b

     pdb._runscript(mainpyfile)

     ) that are conditionally run based on run_as_module.

   These factors mean that all of these lines of code are entangled in ways that are somewhat difficult to reason about. For example, it's unclear what states have been achieved by the time pdb._run* is constructed, or what exceptions may or may not be expected for these calls.

   A functional or OO approach would limit the amount of mutation and entanglement (through encapsulation or scoping).

   An OO approach would have a protocol or interface that captures the different behaviors required prior to and on invocation of Pdb._run*.

   For example, the PDB "targets" (script or module) could be modeled as separate classes and provide symmetric interfaces with (possibly degenerate) equivalent operations for each use-case.

   To be sure, the code that's present is adequate and in my opinion right on the border of benefiting from a more rigorous abstraction. The current imperative approach is fairly readable and mostly comprehensible. It's only because of the surprise behavior in the reported issue that I propose to step back and contemplate ways to alleviate the concerns above.
2. jaraco

   added

   3.11only security fixesonly security fixes

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   on Jul 2, 2021
3. jaraco commented on Jul 18, 2021

   

   jaraco

   on Jul 18, 2021

   MemberAuthor

   More actions

   Additional problems I noticed while working on the refactor:

   • There is a lot of overlap in behavior between the implementations of _run_script and _run_module (initializing private variables, setting mainpyfile, resetting the __main__ namespace).

   • There are two block comments in _run_script whose behaviors apply to _run_module as well, but the block comments are not associated with those behaviors in _run_module.
4. miss-islington commented on Jul 19, 2021

   

   miss-islington

   on Jul 19, 2021

   Contributor

   More actions

   New changeset 2c20558 by Jason R. Coombs in branch 'main':
   bpo-44554: refactor pdb targets (and internal tweaks) (GH-26992)
   2c20558
5. iritkatriel

   closed this as completedon Jul 19, 2021
6. iritkatriel

   closed this as completedon Jul 19, 2021
7. ezio-melotti

   transferred this issue fromon Apr 10, 2022