Run slyp against the code base
#2382
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2382 +/- ##
=======================================
Coverage 99.16% 99.16%
=======================================
Files 40 40
Lines 3101 3101
Branches 680 680
=======================================
Hits 3075 3075
Misses 15 15
Partials 11 11 🚀 New features to boost your workflow:
|
This addresses several formatting issues, including: * Same-line str concatenation * Same-indentation-level multi-line str concatenation in function parameters and dict definitions * Unnecessary parentheses around str constants Although the initial work was automated, manual work was required to reflow multi-line concatenated strings to fit under the 100-character limit.
|
@kurtmckee @DanielNoord sorry for late response, for me changes look ok, but I don't see a point just running slyp if we don't integrate it in the CI. |
|
@staticdev I'm dissatisfied that the personal time I've invested trying to get isort development on track hasn't been fruitful. I'm specifically disheartened when the feedback is "looks good" but the changes don't get merged because additional conditions/requirements are added months after I've invested my time. I'm sufficiently dissatisfied by these interactions that I no longer want to try contributing to isort. I wish the project well, as I still intend to use it. However, I'm not motivated to invest my time toward its success and maintenance. |
|
Dear @kurtmckee, I understand your frustration and it is sad to me you took this decision, but also I am doing work here as best effort and had a lot of work in the last months. This MR specifically was not addressing any issue specific and I though adding to CI is necessary since you fix slyp today and next MR can break it. This is standard in any project using this kind of tools. |
|
@staticdev I'm grateful for your continued work on isort. You're correct that this wasn't addressing a bug or feature, but my goal wasn't to introduce slyp, only to mention what tool I used to find these improvement opportunities. Perhaps the PR title should have been "fix some code quality issues". When I take time away from my family and other priorities to work on open source, my goal is to improve the software that I use, but what I think I'm wanting is (for lack of a more objective description) "positive vibes" for that effort, and I don't currently feel that when contributing to isort. It's not simply this PR. Back in January I noticed that isort had completely stalled out and tried to get development started again by doing bug triage. @DanielNoord showed up and started responding, and in less than a week almost 40 issues and PRs had been addressed. However, in PyCQA/meta#64 Daniel was effectively told to stop taking action, so he did (and so did I). My coworker @sirosen offered to pick up maintenance, but that offer was rejected, too. I've tried to contribute PRs to isort, but Daniel is still honoring that discussion in PyCQA/meta#64 and won't merge them. Save for that initial week back in January where it felt like Daniel and I were working well together, I'm not getting "positive vibes". My impression is that isort is stagnating because the current gatekeepers at the repo and org levels are not making concrete decisions and taking action (as documented in PyCQA/meta#64). I recommend overcoming that stagnation. And again, I'm grateful for your continued work on isort. |
|
👋 Hi there! Mentioned person, coworker of @kurtmckee, and author of As far as I can tell, Kurt was transparent about "I used this tool to transform the code", but it was submitted in the same spirit as a manual cleanup that someone might have suggested as an interested contributor. I vehemently disagree that not putting a tool into CI means that the changes themselves should be rejected. If someone told me "I fixed this oddity I spotted in your project which I found with PyCharm," I wouldn't decide that I can't take the change simply because we don't have "PyCharm CI". In my experience from the maintainer side, suggesting new tools in CI without prior buy-in from maintainers is often a bad experience for the maintainers. It's better not to be changing the linting and autofixing configuration of a project where you are only a contributor unless there is an active problem you are resolving. So I think the typical netiquette here was observed, and if you want to setup We're using and enjoying Anyways, I'm here if I have anything useful to add, or if folks are curious about |
This addresses several formatting issues, including:
Although the initial work was automated, manual work was required to reflow multi-line concatenated strings to fit under the 100-character limit.