doc: test: suggest multi-line imports in functional test style guide #25811

pull theStack wants to merge 1 commits into bitcoin:master from theStack:202208-doc-test-prefer_multiline_imports changing 2 files +12 −3
  1. theStack commented at 4:14 PM on August 9, 2022: contributor

    As long as I remember contributing to functional tests (~2-3 years), it was always kind of an unwritten rule that multi-line imports are preferred over single-line imports in order to reduce the possibility of potential merge conflicts -- at least if more than one symbol from a module is imported. This PR adds this rule to the style guide and adapts the example test accordingly. (Inspired by #25792 (review)).

  2. doc: test: suggest multi-line imports in functional test style guide 4edc689382
  3. fanquake added the label Docs on Aug 9, 2022
  4. fanquake added the label Tests on Aug 9, 2022
  5. unknown approved
  6. brunoerg commented at 6:07 PM on August 9, 2022: contributor

    Concept ACK

  7. w0xlt approved
  8. kouloumos commented at 10:56 PM on August 9, 2022: contributor

    ACK 4edc6893825fd8c45c53c81c73a6a7801e1b458c

  9. stickies-v commented at 11:01 AM on August 10, 2022: contributor

    Thanks for pointing this out, I hadn't considered merge conflicts in my comment but I'm honoured to be an inspiration. Reducing maintenance burden seems a good reason for these updated style guidelines.

    We would still have merge conflicts for initially single name imports that then become multiple names, as showcased in the below script. Would it then be better to apply a uniform rule and always have imports be multiline? Either way, I think the rest of example_test.py should be updated to uniformly reflect whatever we end up with, since we now mix both.

    from collections import defaultdict
    ...
    from test_framework.test_framework import BitcoinTestFramework
    from test_framework.util import (
        assert_equal,
    )
    

    <details> <summary>Example merge conflict for importing single -> multiple names</summary>

    mkdir mergeconflict && cd mergeconflict && git init && git checkout -b master
    echo “from typing import List” > main.py && git add main.py && git commit -m “init”
    git checkout -b a
    echo "from typing import (\n    List,\n    Any,\n)" > main.py && git commit main.py -m "import any"
    git checkout master && git checkout -b b
    echo "from typing import (\n    Tuple,\n    List,\n)" > main.py && git commit main.py -m "import tuple"
    git checkout master && git merge a
    git checkout b && git rebase master
    

    </details

  10. glozow commented at 12:00 PM on August 10, 2022: member

    Concept ACK. AFAICT this is preferred and for this reason, so might as well document it.

  11. fanquake approved
  12. fanquake commented at 3:53 PM on August 10, 2022: member

    ACK 4edc6893825fd8c45c53c81c73a6a7801e1b458c

  13. MarcoFalke merged this on Aug 10, 2022
  14. MarcoFalke closed this on Aug 10, 2022

  15. sidhujag referenced this in commit 02fb80156c on Aug 11, 2022
  16. theStack deleted the branch on Aug 11, 2022
  17. theStack commented at 10:57 AM on August 11, 2022: contributor

    We would still have merge conflicts for initially single name imports that then become multiple names, as showcased in the below script. Would it then be better to apply a uniform rule and always have imports be multiline? Either way, I think the rest of example_test.py should be updated to uniformly reflect whatever we end up with, since we now mix both.

    Thanks for testing out the merge-conflict-scenario for single-/multi-line imports! I'd personally be fine with applying an uniform rule as it's more clear. Though one could counter-argue that there are some modules from where in almost all cases we only import one symbol, and it's probably not worth it to add two extra lines, e.g. the following, being present in every single functional test: from test_framework.test_framework import BitcoinTestFramework

    Anyways, if you (or anyone else) plans a follow-up, feel free to tag me as reviewer.

  18. bitcoin locked this on Aug 11, 2023

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-14 21:13 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me