Hello All, Since PEP 338 <http://www.python.org/dev/peps/pep-0338/> we can run python modules as a script via `python -m module_name` but there is no way to run pdb on those (AFAIK). The proposal is to add a new argument "-m" to the pdb module to allow users to run `python -m pdb -m my_module_name` This is especially useful when working on cli tools that use entrypoints in setup.py, as there is no other way to run them. I have a possible implementation here https://github.com/python/cpython/pull/4752 I quite often use pdb with scripts, being able to run modules would be useful as well. What do you think? Regards! Mario
On Thu, Jan 4, 2018 at 1:56 PM, Mario Corchero <mariocj89@gmail.com> wrote:
Mega +1, I always, always want this, for every command that itself can invoke other python scripts. There is prior art in that this feature was already added to cProfile as well: https://bugs.python.org/issue21862 -- Devin
On Thu, Jan 4, 2018 at 8:15 PM, Guido van Rossum <guido@python.org> wrote:
Sounds uncontroversial, this can just be done via bugs.python.org.
.. and it has been proposed there over 7 years ago: <https://bugs.python.org/issue9325>.
On 10 January 2018 at 05:18, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
Aye, I linked Mario's patch up to that as a higher level tracking issue - the `pdb -m` support is available in 3.7.0a4 :) He's also now submitted comparable patches for a couple of other modules which I'll aim to get to before 3.7.0b1 Cheers, Nick. P.S. For anyone curious as to what the delay has been, the problem is that the *public* runpy API isn't quite flexible enough to support the way some of these other modules want to run code, and even if we had added such an API, they likely would have required refactoring in order to use it. Mario's patches have instead been taking advantage of the fact that these are stdlib modules we're updating, and hence we can get away with using *private* runpy APIs for now, and then based on these conversions, we can look at what features the public runpy API would need in order for us to migrate them away from using those private interfaces. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, Jan 4, 2018 at 1:56 PM, Mario Corchero <mariocj89@gmail.com> wrote:
Mega +1, I always, always want this, for every command that itself can invoke other python scripts. There is prior art in that this feature was already added to cProfile as well: https://bugs.python.org/issue21862 -- Devin
On Thu, Jan 4, 2018 at 8:15 PM, Guido van Rossum <guido@python.org> wrote:
Sounds uncontroversial, this can just be done via bugs.python.org.
.. and it has been proposed there over 7 years ago: <https://bugs.python.org/issue9325>.
On 10 January 2018 at 05:18, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
Aye, I linked Mario's patch up to that as a higher level tracking issue - the `pdb -m` support is available in 3.7.0a4 :) He's also now submitted comparable patches for a couple of other modules which I'll aim to get to before 3.7.0b1 Cheers, Nick. P.S. For anyone curious as to what the delay has been, the problem is that the *public* runpy API isn't quite flexible enough to support the way some of these other modules want to run code, and even if we had added such an API, they likely would have required refactoring in order to use it. Mario's patches have instead been taking advantage of the fact that these are stdlib modules we're updating, and hence we can get away with using *private* runpy APIs for now, and then based on these conversions, we can look at what features the public runpy API would need in order for us to migrate them away from using those private interfaces. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (6)
-
Alexander Belopolsky -
Devin Jeanpierre -
Guido van Rossum -
Lisa Roach -
Mario Corchero -
Nick Coghlan