gh-148615: Handle -- end-of-options separator in pdb argument parsing

[Shrey-N]

The switch from getopt to argparse in gh-125115, python -m pdb rejects the standard -- end-of-options separator. Makes it impossible to pass arguments that share names with pdb flags (like -c) to the target script.

The root cause is that pdb's argparse parser has no positional arguments defined, so parse_known_args() does not consume -- and returns it in the remainder list. The manual post processing logic in parse_args() then incorrectly treats it as an unrecognized flag since it starts with -.

This adds a check for -- in the elif args[0].startswith('-'). When found, the separator is consumed and parsing continues to the script name. If no script follows, an error is raised. All other unrecognized flags continue to produce the existing error message.

Closes gh-148615 :)

[gaogaotiantian]

Thanks for fixing this. We need some regression test on this. We need to test the specific case reported, and also some others. I wonder if -- works as expected when it's on other places.

For the code itself, let's move -- check to it's own case (not under args[0].startswith), less nested logic.

[Shrey-N]

Thank you, that makes sense, I will update the PR asap! :)

[Shrey-N]

Hiya @gaogaotiantian, is there anything else needed from my side to move this forward?

[gaogaotiantian]

Sorry I was kind of busy recently and did not get a chance to take a look :)

I don't think this issue worth a while new test class for it. Some test cases in a test method would do. The new test class does not cover anything that the integration test can't cover. Let's just put all the interesting test cases in the same method. It's a relatively corner case and we don't need to overreact.

[python-cla-bot]

All commit authors signed the Contributor License Agreement.