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(mostrecentcalllast):File"/Users/kmike/envs/pymorphy/bin/kernprof.py",line233,in<module>sys.exit(main(sys.argv))File"/Users/kmike/envs/pymorphy/bin/kernprof.py",line230,inmainprof.print_stats()File"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/cProfile.py",line81,inprint_statspstats.Stats(self).strip_dirs().sort_stats(sort).print_stats()File"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pstats.py",line93,in__init__self.init(arg)File"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pstats.py",line107,ininitself.load_stats(arg)File"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pstats.py",line136,inload_statsself.__class__,arg)TypeError:Cannotcreateorconstructa<classpstats.Statsat0x1041f1f58>objectfrom'<__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 :)