Apart from the use of closures breaking pickling, modifying an estimator because of the context it's used in could be pretty nasty to the user... You'll need to rethink the design.

I wanted to avoid putting timing code in each method, and I wanted fit_transform to break out separate log messages for fit and transform.

Breaking pickling seems unacceptable though. I can make a helper function that takes the fit/transform method as an argument and prints timing info (ugly, unfortunately), or just write timers into each method. What do you prefer?

I suspect that usually we want timing information for all fit calls, and
you should focus on that initially. If we really think that transform calls
at prediction time are useful to time separately, we could do so only under
a high verbosity setting. I wouldn't object to the timing incorporating
both fit and transform in the _pre_transform helper.

On 27 September 2015 at 08:26, Sam Zhang [email protected] wrote:

I wanted to avoid putting timing code in each method, but breaking
pickling is unacceptable. I can make a helper function that handles the
call to fit/transform and prints timing info, or just break it out into
each method.

(broke docstrings)

—
Reply to this email directly or view it on GitHub
#5321 (comment)
.

I've taken those suggestions into account and left prediction-time calls untimed for now.

LGTM! Please make that little tweak to informativeness, and add an entry to whats_new.rst

LGTM apart from @jnothman's comments

could you please rebase?

hm didn't work :-/

@samzhang111 Thanks for picking this up! I was looking for exactly this functionality. If you're still interested in getting this merged, I'd love to be an early user :)

I was almost ready to merge at #7163 when I decided to check the output. Cross-validation's _fit_and_score helper ensures all line lengths are the same when reporting times. I think we should conform here. Indeed, a utility:

def _log_time(left_text, right_text, time, width=70, file=sys.stdout):
    pass

would be appropriate.

@samzhang111, are you still around and interested in working on this?

@samzhang111 I guess that's a "no"?

Sorry, I have been on vacation. If someone would like to do it quickly,
please. Otherwise I can later this weekend.

On Fri, Aug 26, 2016 at 1:07 PM, Andreas Mueller [email protected]
wrote:

@samzhang111 https://github.com/samzhang111 I guess that's a "no"?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5321 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACq6obRF-4IGVE-XcAmXrTcPVvJxaPSJks5qjx09gaJpZM4GEYmS
.

@samzhang111, I'm going to open this to another contributor to complete. Let me know if you're pushing on with it.

Close in favor of #10435 just to avoid clutter?