what to clean up, what to leave as is
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. Cheers, Ralf
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. Chuck
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. Kevin 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.
Chuck _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
On Fri, Jan 24, 2020 at 10:42 AM Kevin Sheppard <kevin.k.sheppard@gmail.com> wrote:
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.
I tend to see that as a matter of timing. At some point such things become archaic and unfamiliar as developers who grew up with modern Python become more common. But there is no rush. The problem with code history is trickier, and almost unavoidable over time. The information is still there, but it is harder to dig it out. Probably there need to be better tools to deal with that. This is especially apparent from the early C code cleanup that I did just to get more modern and readable code styling. My name is all over code that I didn't write, just formatted. But the cleanup was necessary for maintenance if nothing else. <snip> Chuck
On Fri, 2020-01-24 at 10:57 -0700, Charles R Harris wrote:
On Fri, Jan 24, 2020 at 10:42 AM Kevin Sheppard < kevin.k.sheppard@gmail.com> wrote:
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.
I tend to see that as a matter of timing. At some point such things become archaic and unfamiliar as developers who grew up with modern Python become more common. But there is no rush.
Honestly, I am OK with simply not cleaning up some stuff. It was a quick thought. But, if we ever get around doing it, it seems like a good time now when we already have a big code churn do to Py2 removal.
The problem with code history is trickier, and almost unavoidable over time. The information is still there, but it is harder to dig it out. Probably there need to be better tools to deal with that. This is especially apparent from the early C code cleanup that I did just to get more modern and readable code styling. My name is all over code that I didn't write, just formatted. But the cleanup was necessary for maintenance if nothing else.
Code history is a problem and it is annoying that code attribution is obfuscated by it. The argument for doing style cleanups is that if we do not use modern patterns in large chunks of the code, the old patterns are likely to repeated indefinitely. At least within their files [0]. Tools are maybe getting a bit better (e.g. github allows to click on "view blame before this, although I doubt we ever get somewhere were they will figure out that something was "just" a style cleanup. - Sebastian [0] An example are pytest vs. nose testing styles, where it is unlikely we ever lose the complexity of keeping random snippets of nose style around (which definitely will confuse new contributors).
<snip>
Chuck _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
participants (4)
-
Charles R Harris -
Kevin Sheppard -
Ralf Gommers -
Sebastian Berg