The commit in this PR removes unused Python imports.
Remove unused Python imports #9508
pull practicalswift wants to merge 1 commits into bitcoin:master from practicalswift:remove-unused-python-import changing 10 files +1 −17-
practicalswift commented at 8:34 PM on January 10, 2017: contributor
- practicalswift renamed this:
[gardening] Remove unused Python imports
[trivial] Remove unused Python imports
on Jan 10, 2017 - practicalswift force-pushed on Jan 10, 2017
- fanquake added the label Refactoring on Jan 11, 2017
-
laanwj commented at 12:57 PM on January 11, 2017: member
Makes sense. Is there an automated tool you used to find these?
-
practicalswift commented at 1:52 PM on January 12, 2017: contributor
@laanwj Yes,
pycodestyle(formerlypep8) is probably the most common tool for checking Python code against the Python Software Foundation's Style Guide for Python Code (PEP-8). Unused imports is one class of violations covered bypycodestyle.I've done some cleanup work for the
apple/swiftproject - see here - which included things such as bringing the Python code base in line with PEP-8. Please let me know if that kind of contributions would be welcome in the Bitcoin project and I'll dig in! :-) -
jtimon commented at 2:08 AM on January 13, 2017: contributor
Concept ACK
- practicalswift renamed this:
[trivial] Remove unused Python imports
Remove unused Python imports
on Jan 13, 2017 -
Remove unused Python imports 95bab821b3
- practicalswift force-pushed on Jan 13, 2017
-
practicalswift commented at 6:03 PM on January 13, 2017: contributor
Removed
[trivial]from the commit title. -
jnewbery commented at 2:45 PM on January 17, 2017: member
ACK
Feel free to open PRs for tidying up python coding style. I'm happy to review anything in the qa directory.
-
practicalswift commented at 2:59 PM on January 17, 2017: contributor
@jnewbery OK, great! Will do! :-)
-
practicalswift commented at 3:00 PM on January 17, 2017: contributor
-
practicalswift commented at 9:15 AM on January 18, 2017: contributor
@jnewbery What is the proper protocol to follow w.r.t. to submitting Python cleanups? Should I wait for this initial Python cleanup PR to get merged before proceeding with further cleanups, or what is the preferred way to proceed? :-)
-
MarcoFalke commented at 9:25 AM on January 18, 2017: member
utACK 95bab821b3af268d23e9cf5f9da3dd7f1e396949
- MarcoFalke merged this on Jan 18, 2017
- MarcoFalke closed this on Jan 18, 2017
- MarcoFalke referenced this in commit b0b57a1730 on Jan 18, 2017
-
jnewbery commented at 2:20 PM on January 18, 2017: member
@practicalswift - probably best to ask @MarcoFalke since he maintains the qa and test code. In general I'd recommend not making parallel PRs which touch a lot of files, since you'll probably end up having to rebase.
-
practicalswift commented at 3:25 PM on January 18, 2017: contributor
-
MarcoFalke commented at 6:22 PM on January 18, 2017: member
I think it makes sense to clean up the python code base in qa/ but please make sure you are not "exceeding the goal". We already had cleanup pulls which changed to a max line length to 80 chars among other things. It turned out the patch was impossible to review, actually changed behavior and would have introduced bugs. I'd rather have "ugly" code that works than some PEP8 code that crashes.
Just ask yourself if a specific cleanup task is worth it and easy to review, then it should be fine.
- codablock referenced this in commit edd06e39e6 on Jan 19, 2018
- codablock referenced this in commit c2e47bcf3f on Jan 20, 2018
- codablock referenced this in commit be63fb7953 on Jan 21, 2018
- andvgal referenced this in commit bdc5fe6352 on Jan 6, 2019
- CryptoCentric referenced this in commit b6e307559c on Feb 27, 2019
- CryptoCentric referenced this in commit e11d1ae195 on Feb 27, 2019
- practicalswift deleted the branch on Apr 10, 2021
- DrahtBot locked this on Aug 16, 2022
Contributors
Labels