What should we do with cProfile?
Hello, As per PEP 3108, we were supposed to merge profile/cProfile into one unified module. I initially championed the change, but other things got in the way and I have never got to the point of a useful patch. I posted some code and outlined an approach how the merge could be done. However, there still a lot of details to be worked out. So I wondering whether we should abandon the change all together or attempt it for the next release. Personally, I slightly leaning on the former option since the two modules are actually fairly different underneath even though they are used similarly. And also, because it is getting late to make such backward incompatible changes. I am willing to volunteer to push the change though if it is still desired by the community. Cheers! http://bugs.python.org/issue2919
Alexandre Vassalotti wrote:
Hello,
As per PEP 3108, we were supposed to merge profile/cProfile into one unified module. I initially championed the change, but other things got in the way and I have never got to the point of a useful patch. I posted some code and outlined an approach how the merge could be done. However, there still a lot of details to be worked out.
So I wondering whether we should abandon the change all together or attempt it for the next release. Personally, I slightly leaning on the former option since the two modules are actually fairly different underneath even though they are used similarly. And also, because it is getting late to make such backward incompatible changes.
I am willing to volunteer to push the change though if it is still desired by the community.
I don't have a strong opinion either way, but if it was worth merging them for 3.3, then it's worth merging them for 3.4. Don't let "I won't be finished in time for 3.3" stop you. -- Steven
As per PEP 3108, we were supposed to merge profile/cProfile into one unified module. I initially championed the change, but other things got in the way and I have never got to the point of a useful patch. I posted some code and outlined an approach how the merge could be done. However, there still a lot of details to be worked out.
So I wondering whether we should abandon the change all together or attempt it for the next release. Personally, I slightly leaning on the former option since the two modules are actually fairly different underneath even though they are used similarly. And also, because it is getting late to make such backward incompatible changes.
I am willing to volunteer to push the change though if it is still desired by the community.
I don't have a strong opinion either way, but if it was worth merging them for 3.3, then it's worth merging them for 3.4. Don't let "I won't be finished in time for 3.3" stop you.
+1 IMHO merging modules with their C accelerators is a worthy goal, because having two modules in the stdlib doing the same is confusing. At worst, the merged module can do everything it can in C and defer the things it can't do to Python (or defer *everything* on platforms where the C extension can't be built for some reason). And as Steven said, the 3.3 timeline doesn't have anything really special about it. Although there's still time until the beta release, even if this is done for 3.4 it will be great. Eli
On Wed, May 30, 2012 at 1:01 PM, Eli Bendersky
And as Steven said, the 3.3 timeline doesn't have anything really special about it. Although there's still time until the beta release, even if this is done for 3.4 it will be great.
Yep - there's a reason the 3.4 target gets added to the tracker even before 3.3 is out. It's precisely so we can bump things as soon as we reach a point where we're comparing the effort we think is needed to get them agreed on and/or bedded down properly and the time remaining before the first beta and officially say "not going to happen". I've already done that for Eugene Toder's proposed compiler enhancements. It's a promising approach, but it's *way* too late in the 3.3 cycle to be contemplating that kind of change. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
So I wondering whether we should abandon the change all together or attempt it for the next release. Personally, I slightly leaning on the former option since the two modules are actually fairly different underneath even though they are used similarly. And also, because it is getting late to make such backward incompatible changes.
I agree that this change is not worthwhile for Python 3. I suggest to close the issue as "won't fix". I'm not sure whether anybody uses the profile module at all, so recycling the name might have been appropriate for Python 3.0. But now that would be a backwards-incompatible change, and I agree it's doubtful whether a backwards-compatible change can be achieved. Even if profile could somehow stay compatible, nothing is gained if cProfile also stays - but it would have to, for backwards compatibility reasons. I predict that at some point, somebody contributes yet another profiling tool which may well supersede both profile and cProfile. If you are interested in profiling in general, I suggest that you could rather work on such code, and release it to PyPI. Regards, Martin
participants (5)
-
"Martin v. Löwis" -
Alexandre Vassalotti -
Eli Bendersky -
Nick Coghlan -
Steven D'Aprano