I think some types of clean-ups, for example, imports, are pretty low cost, low risk and don't have much bearing on and it might be best to do them all at once. 

f-strings are also pretty simple but can be abused to the detriment of code around (for example, moving a string defined in a variable outside a function into the function just so it can have an f-string).

I think more general code clean-up, for example, removing list around iterators (e.g., list(map(f, i)) should be mostly avoided unless there is a compelling case to prefer the iterator for performance reasons. 


On Fri, Jan 24, 2020 at 5:29 PM Charles R Harris <charlesr.harris@gmail.com> wrote:

On Fri, Jan 24, 2020 at 9:46 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi all,

It's great to see that people are jumping at the chance to clean up Python 2 support. I would however caution about overdoing it on other cleanups. As a reminder, we normally do not want pure style PRs (e.g. PEP8 cleanups), because they make the code history (git blame, commits on particular files, etc.) harder to work with, have review overhead, and may introduce new bugs for little gain.

Imho that same rationale applies to things like converting strings to f-strings. There's of course some gray area, for example removing "from ... import *" can guard against accidentally exposing new API, so can be considered a valuable cleanup.

As a separate/additional point: numpy.distutils and numpy.f2py are largely untested, PRs are hard to test locally because of platform-specific code, and changes often introduce regressions. So even for some cleanups that are okay for other files, please do not do them on those modules.

I do like f-strings, they can make the code simpler and more readable.

NumPy-Discussion mailing list