bpo-34788: Add support for scoped IPv6 addresses by opavlyuk · Pull Request #13772 · python/cpython
As for me, this PR could not be broken into multiple smaller ones, because it refers to and covers a single issue. Also, all changes depend on each other and could not be merged separately (e.g. tests after main code or vice versa). According to devguide, tests and documentation should be included to PR. So, seems it would not be right to make separate PR`s.
May be, some tests could be considered redundant, but devguide insists on writing tests both for normal behaviour and for error conditions.
Usually, for more involved issues, a single PR represents a self-contained step towards the resolution. Self-contained meaning that the PR also contains the respective documentation changes, test coverage, and is compatible with the existing code-base by itself. This doesn't mean that the entire issue has to be covered at once.
As for this PR specifically, I'm not entirely certain into what self-contained pieces it could be further fragmented into, it's just a general guideline. If it's not reasonably possible to do this, it's not at all required. The most substantial benefit of fragmenting it into multiple PRs is easier debugging when the integration tests aren't passing.
In my PR I only extend this test with cases, consisting scope IPv6 addresses. It was already written in such a style. According to devguide, it isn't recommended to make cosmetic changes to unrelated code. PEP8 also tells that, if an existing library has a different style, internal consistency is preferred. So, to keep existing style of test, I haven't put assertions in loop.
Upon reconsideration and further inspection of the existing tests, keeping the current style of the library is understandable, especially given the sheer volume. Perhaps I'll work on refactoring it in a future PR, but it'd likely have to be done all at once for consistency. When I had first submitted my initial review, I had underestimated the size of the existing tests. Improving the readability would likely be a project on it's own. I wouldn't expect you to refactor all of the entire existing tests within the same issue.
The above also applies to the naming conventions. I'm far more used to our more recent unit tests using the underscore naming. My apologies, it looks like I focused a bit too much on your additions rather than the context.
But, if it is a must, I will fix that lines, of course.
As someone who isn't a core dev, my reviews are just recommendations based on my experiences thus far working within the Python repositories. So if you have reasons for doing anything a particular way and the core devs agree with your justification, you can definitely keep it as it is.