what to clean up, what to leave as is

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

what to clean up, what to leave as is

ralfgommers
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


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: what to clean up, what to leave as is

Charles R Harris


On Fri, Jan 24, 2020 at 9:46 AM Ralf Gommers <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: what to clean up, what to leave as is

bashtage
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 <[hidden email]> wrote:


On Fri, Jan 24, 2020 at 9:46 AM Ralf Gommers <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: what to clean up, what to leave as is

Charles R Harris


On Fri, Jan 24, 2020 at 10:42 AM Kevin Sheppard <[hidden email]> 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

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: what to clean up, what to leave as is

Sebastian Berg
On Fri, 2020-01-24 at 10:57 -0700, Charles R Harris wrote:

>
>
> On Fri, Jan 24, 2020 at 10:42 AM Kevin Sheppard <
> [hidden email]> 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
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment