Repository navigation
Sort imports - #7827
Sort imports#7827Cadair wants to merge 2 commits into
Conversation
|
Hi there @Cadair 👋 - thanks for the pull request! I'm just a friendly 🤖 that checks for issues related to the changelog and making sure that this pull request is milestoned and labeled correctly. This is mainly intended for the maintainers, so if you are not a maintainer you can ignore this, and a maintainer will let you know if any action is required on your part 😃. Everything looks good from my point of view! 👍 If there are any issues with this message, please report them here. |
|
While I truly love the cleanup this PR provides, we need to be careful when/how to merge as this will cause a hell lot of conflicts with other PRs. |
|
yes, yes it would. |
| import pytest | ||
| import numpy as np | ||
| import pytest | ||
| from numpy.testing import assert_allclose |
There was a problem hiding this comment.
Just to be difficult: I'm not a fan of this sorting, as I like to keep the Numpy imports together :)
There was a problem hiding this comment.
I can add numpy as it's own section if you want?
|
Note that there are some places where the order of the imports is related to performance - I know @mhvk ordered some imports like that recently. |
|
Bonus points if you can write a script that figures out if there would be any merge conflicts with any PRs automatically and avoids those files. Should be feasible, right? |
Once CI passed, I think then we should definitely need to run this PR through the benchmarks. |
|
It is pretty easy to find a list of all files touched by open PRs: It might make sense to try and run this only for untouched files to start with? Btw this could be helpful for PEP8 cleanup too. |
|
@bsipocz - it's not just about existing benchmarks, but to do with the timing of astropy sub-package imports, which we don't test automatically. |
|
@astrofrog - Of course, you're right, we need those too. So apparently running the tools is the easy part of the job 😁 |
|
I don't think anything I did to reduce import times of modules is changed by this PR - at least, if I understand correctly, it is just organizing the imports on-top, while my changes moved imports from on-top to inline, etc. |
| from numpy.testing import assert_allclose, assert_almost_equal | ||
|
|
||
| from ..utils import KernelSizeError | ||
| from ..kernels import (Kernel1D, Kernel2D, Box1DKernel, Box2DKernel, CustomKernel, |
There was a problem hiding this comment.
this must be beyond 80 characters while most of this file is within
There was a problem hiding this comment.
I set the line limit to 99, does astropy use 80 everywhere?
There was a problem hiding this comment.
it depends on the module, some are 80 some are 100.
There was a problem hiding this comment.
in fact all the other tools in setup.cfg are configured to 100 lines.
There was a problem hiding this comment.
http://docs.astropy.org/en/stable/development/codeguide.html#coding-style-conventions
It's set to 100 so it won't complain for modules where the limit is not 80.
There was a problem hiding this comment.
yeah it's one or the other ;)
There was a problem hiding this comment.
We had this discussion quite a while back, and it was decided one should follow the style of the module - PEP8 states it should be 80, so I think 100 should be the exception, not the rule.
There was a problem hiding this comment.
Why not 79? We need that 80th char for \0. 😄
|
I'm not convinced by this import length sort, but hey you British folks like weird units |
Oh, those units are not seriously used in real life. On the other hand, the situation on the other side of the pond is complete madness, so many of the EU regulations were not the doing of the devil's work |
Haha. Welcome to USA! |
You don't understand, I sorted all imports... everywhere.