Line Profiler 6.0 Roadmap

[Erotemic]

I want to make backwards incompatible changes in line-profiler in order to improve the new-user experience and generally streamline usage.

I'm making the issue to record these ideas and invite discussion before any changes are made.

Off the top of my head as I'm writing this I'm thinking:

• Deprecate cProfile / pstats usage. I don't see a use case for this library. If anyone is using pstats please let me know and we will keep it, but make it opt in instead of the default. The new default should be line-by-line=True and builtins=True. (Maybe in 5.0 we should warn that this change will occur if the user does not specify -l, and in 6.0 make -l into a no-op that warns it will no longer be needed and will result in an error in the future).

• The skip-zero option should default to true.

• The help text to print out the results of the lprof file info should always show even if you are summarizing. Also when summarizing with kernprof the results should be sorted by time. They currently do not seem to be. Not sure why that is, that could be fixed in a 5.x branch.

• We will keep the kernprof script both for backwards compat, but also to recognize the R Kern's contribution to the Python ecosystem by creating this package, but I think we should alias it and make python -m line_profiler the default entry point and also add line_profiler or lineprof script to make it more clear that this is a cohesive package. This means that python -m line_profiler main should become modal depending on if it is summarizing a lprof file, or running a script. Will have to think about the right design for this. I think it is important to ensure that usage is very concise and the user gets something interpretable and expected with minimal boilerplate. (Unify kernprof and python -m line_profiler #386)

• Rewrite the README and docs to be streamlined.

• Add internal benchmarks to identify performance regressions. (see Worst-Case Overhead Increase Since 4.1.3 #375)

• Consolidate the 3 __version__ attributes into line_profiler.__init__ (part of the consolidation of kernprof and line-profiler clis).

[Theelx]

While I can certainly see that there are benefits to having skip-zero default to True (less clutter), I'd disagree with having the default change because of a few negatives. I find it very useful to be able to see the context around lines which were run in the command line output, and also it helps me know which lines were not run without having to change back from the terminal to the editor (which costs a mental context switch). Additionally, while I know most developers have the terminal integrated into the editor, I've been TAing a university Data Science class for 3rd-years in which I've been working with the professor to teach them how to do profiling, and very few of them have their editor set up with an integrated terminal. I think having skip-zero stay defaulting to False will help onboard new users by making it clear which lines have not run.

Sorry if the above is a bit rambly and incoherent, I'm still recovering from being put under for a surgery. I'll try to remember to come back and edit this to make it make more sense. Also, all the other ideas you have sound great!

[Erotemic]

Thanks @Theelx ! Exactly the sort of feedback I'm looking for. I think ensure things are sorted by default will help the issue without changing the default. Maybe another direction could be having an option for printing "tips" enabled by default. If it detects that its printing tons of zeros, maybe it gives the user a tip that the "-z" option exists.

BTW, are your students not using vscode? I'm still on gvim myself, but that's due to a large amount of configuration dept. I strongly push new coders to vscode.

Also, have a speedy recovery 🏥 !

[Theelx]

I really like the idea of printing tips by default, especially with detecting a lot of zeroes. One thing to be careful with that though is breaking any programmatic analysis of the CLI output (though anyone doing that ought to be using the API). Might be worth including a way to opt-out of tips. Sorting results by %time (like scalene) or per hit masks the control flow a bit imo, which leans a bit away from being beginner-friendly. We encourage the students to start with VSCode/Colab/Jupyter for the first two or three weeks, but then we try to move them to Vim/Neovim for most of the semester, and lastly nano for the last week or two (to get them familiar with basic Linux tools that they might need if they ever debug in more restricted environments). It's a bit messy of a progression, but we hope to get them familiar with multiple tools that they may need. And thanks for the well-wishes!