Unify kernprof and python -m line_profiler

[Erotemic]

I would like to have a CLI utility called line_profiler that roughly does what kernprof is currently doing. I would like it to correspond to python -m line_profiler as well, which would be a backwards incompatible change as that CLI currently reads an lprof file and summarizes it.

In this issue I'd like to brainstorm exactly what this streamlined interface would look like. I would like it to be similar to the python CLI in the way kernprof currently is so the following invocations:

line_profiler -c "code"
line_profiler -m modname
line_profiler path-to-script.py

give the user intuitive results. The idea being: just replace python with line_profiler and see results.

The question I have is how do we incorporate the lprof reading / summarization. Normally I would use a modal CLI, so there would be line_profiler profile <args> and line_profiler summarize <args> (or something similar), which has the benefit of keeping the CLIs completely disjoint, but I'd really like to avoid the extra profile subcommand as that breaks the "just replace python with line_profiler" idea that I think is very nice and intuitive.

We could check to see if the argument to line_profiler is an lprof file, and if it is, then use the alternate code path, but that is also messy and bloats the CLI help docs.

Another option would be add a new CLI: line_profiler_summarize, which does the same thing, but that means existing scripts might not be backwards compatible, and while that is ok to some degree for a major version bump, I do want to preserve as much backwards compatibility as possible.

We could be a little sneaky, and check is the arg is an lprof file and effectively still do the summarize behavior, but maybe warn the user that it might go away, and they should use line_profiler_summarize (or maybe a cli with a better name), which has proper help docs, and just don't document that feature in the default line_profiler CLI?

[TTsangSC]

Just brainstorming here. There might be several things that needs to be decided (and then worked) on:

• Existing semantics will be broken no matter how we cut it, and we'll have to figure out how (or whether) to rehabiiltate them; e.g.:

  • kernprof -m yes my.lprof currently runs the module yes with the postional arg my.lprof, while
  • python -m line_profiler -m yes my.lprof reads and shows the content of my.lprof with --summarize=True.

• IMO checking whether the the input file is an .lprof and switching behaviors may be problematic:

  • Ideally speaking we want the behavior to depend:

    • Solely on the syntax, and failing that
    • As little on filename (so my.lprof and utyighf4wy8fghr should be treated on equal footing)...
    • ... and on the environment (so my.lprof should be treated consistently one way or another no matter if it's an existing) as possible.

    In some sense that ship has sailed (e.g. we already had to decide if kernprof --prof-mod some.py wants to profile a Python object some.py or a file Path.cwd() / 'some.py', and as far as I remember we do use an os.path.exists() check somewhere), but still.

  • Inspection of the file content may help (e.g. in distinguishing between whether line_profiler somefile wants to run a Python script called somefile or show the LineStats dumped into said file), but considering that we currently use pickle to dump LineStats it may not be very secure to just load arbitrary files which may be pickles.

  But then again line_profiler is a dev tool, and there is some implicit trust that users are to behave in a somewhat sane way and follow some conventions, so maybe that isn't that big an issue.