kernprof.py -b flag doesn't work though, but this seems unrelated to Python 3.x support (it fails even without my changes).
The exception is:
Traceback (most recent call last):
File "/Users/kmike/envs/pymorphy/bin/kernprof.py", line 233, in <module>
File "/Users/kmike/envs/pymorphy/bin/kernprof.py", line 230, in main
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/cProfile.py", line 81, in print_stats
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pstats.py", line 93, in __init__
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pstats.py", line 107, in init
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pstats.py", line 136, in load_stats
TypeError: Cannot create or construct a <class pstats.Stats at 0x1041f1f58> object from '<__main__.ContextualProfile object at 0x1041da910>''
It is raised when there are not functions decorated with @profile.
If cProfile import is commented out, then ContextualProfile.__init__ fails because profile.Profile is an old-style class and thus super() doesn't work. After changing it to use Profile.__init__ exception is no longer raised. But it seems we don't need to fix this because cProfile is always imported under 2.x, and under 3.x super always work.
I'm using it since March too, without issues in both 2.x and 3.x virtualenvs.
I guess merging is hard mainly because line_profiler is very stable software, there are no unit tests for this PR, and the changes are non-trivial, esp. if one haven't done Python 3.x porting before, so it is hard to check if this PR is valid. Also, after merging Robert should commit himself to supporting Python 3 in line_profiler and check patches for Python 3.x compatibility. I don't know how to improve the situation - writing proper tests for line_profiler looks quite hard, and unfortunately I don't have time for that now.
What I can do is to offer help with fixing compatibility issues after merging this PR - say, I'll submit a PR with a fix for any Python 2.x or 3.x compat issue in a period of 14 days after raising it for all issues raised until 2015 :)
There are two "\n"s (for dump_file and text_file), and the second "\n" may be either between the message and "text_file" or between "dump_file" and "text_file", so if we just remove these "\n"s we'll lose one separator when both options are ON.
Does strict backwards compatibility matter in this case? I found extra empty line nice :)
I've fixed an issue with extra newline as Joseph Martinot-Lagarde suggested. It looked well in IPython notebook, but not so well when line_profiler is used in a regular IPython shell. I prefer not to fix PY2/PY3 thing to keep the relevant code 1-to-1 copy-paste from six.