Avoid lambda flake8 error with private function

[bobleesj]

As provided in the previous comment: #54 (comment)

For these lambda flake8 errors we would normally see if the function is being used in more than one place, and if it is, define a private function somewhere outside the main part of the code.

I created a private function called _interpolate_stretching_factor in the ComponentSignal class since the function has been used more than once. Thank you for the feedback.

Please confirm my function description.

• comments removed
• CI, pre-commit ✅

[sbillinge]

I nervous that this is not the right design here. this function seems to be doing a very shallow wrap of np.interpolate. Can't we just call np.interpolate?

Why don't you think about it for a sec and propose something cleaner?

[sbillinge]

Private functions don't need docstrings

[bobleesj]

The original func variable containing the lambda expression is used twice within apply_stretch.

First, the derivative of func is computed:

derivative_func = numdifftools.Derivative(func)

Second, the expression is simply computed:

stretched_component = func(self.stretching_factors[m])

Due to the first usage, it is required that we express the np.interp part as a function block.

To me personally, I would have maintined the lambda expression as it was originally. To avoid the flake8 error, I would use # noqa: E731 as recommended.

I am aware using this specific tag to avoid errors should be used as the last resort and it may not be the best practice (in most cases). However, we do not want to have a private function or nested function block either since it's a very simple function.

How is my thought? @sbillinge

[sbillinge]

The original func variable containing the lambda expression is used twice within apply_stretch.

First, the derivative of func is computed:

derivative_func = numdifftools.Derivative(func)

Second, the expression is simply computed:

stretched_component = func(self.stretching_factors[m])

Due to the first usage, it is required that we express the np.interp part as a function block.

To me personally, I would have maintined the lambda expression as it was originally. To avoid the flake8 error, I would use # noqa: E731 as recommended.

I am aware using this specific tag to avoid errors should be used as the last resort and it may not be the best practice (in most cases). However, we do not want to have a private function or nested function block either since it's a very simple function.

How is my thought? @sbillinge

Thanks Bob, great analysis. It is not a huge deal here, so I would probably go with the lambda as you recommend. I might take the opportunity to make the code more readable and call it something other than "func" which is not very descriptive.

[bobleesj]

Requesting a pull request:

• func was renamed to interpolate_intensity to improve clarity
• Added noqa: E731 as discussed

@sbillinge

[sbillinge]

nicely done !