Should we backport fixes to pdb?

@iritkatriel and some new contributors have been working on fixing some bugs in the pdb module, and I’ve begun reviewing that work. This is my first time working on the pdb module, which doesn’t seem to have had a consistent maintainer for a while now.

I know our general backporting policies well, including specifically for stdlib modules. But I’m still conflicted on whether these fixes should be backported to 3.9 and 3.8. The reason is that other debugging tools are likely relying on the existing (broken) behavior, since the pdb module is promoted as being extensible, with the interface being undocumented, “just read the code”.

So, should we simply not backport fixes, and mention them in the 3.10 “What’s New”? That seems to be the safest approach.

Example PRs with fixes:


I’m adding comments to each of the PRs.

UPDATE: 3 our of 4 I am okay with backporting; the exception is the breakpoint fix.

1 Like

That’s fantastic @guido, many thanks! :pray:

You could ask the SC for an official call on this, but I view pdb like I view IDLE: a batteries-included tool and not a library with an API, so backports should be fine.

While regressions are unpleasant, they cannot be avoided. In general, I would suggest to backport bugfixes in all branches accepting bugfixes (currently 3.8, 3.9 and master).

If the backported bugfix causes a new issue, well, it happens, it’s ok. It should be fixed as any other bug. And then again, the fix for the new issue should be backported as well.

When someone complains that regressions must not be tolerated, I always ask to add new tests. This is the only reliable metric: more tests is always a good thing.

1 Like