Add `type-refactor` label

[erlend-aasland]

Although we discourage refactoring in general, there is sometimes a valid need for refactoring. Recent examples would be Irit's refactoring of the compiler and Mark Shannon's proposal for more readable type defs. We've historically also done (and are still doing) several test refactorings:

• Move test sub-packages to Lib/test cpython#54781
• Split up _testcapimodule.c cpython#93649
• Move test files into test subdirectories cpython#108303
• Split test_dis into a directory by separating generated content cpython#123361

Currently, we use type-feature for these efforts, but it may be beneficial to be able to differentiate between (real¹) features and refactorings.

Footnotes

1. user-facing ↩

[erlend-aasland]

Another example that recently appeared:

• Refactor PyUnicodeError internal C helpers cpython#127787

[picnixz]

Some other examples:

• Refactor codecs error handlers to use _PyUnicodeError_GetParams and extract complex logic into separate functions cpython#129173
• Refactor sqlite3 error handler cpython#129928
• Reorganize the JIT optimization passes. cpython#128939
• refactor the implementation of inlined comprehensions cpython#124697

There are probably more but this would at least separate what's a real feature from what's a refactorization (sometimes internal, sometimes not).

[picnixz]

After python/cpython#131238, and other issues that are meant to target refactorization-only (and not really feature), I become more and more convinced that we need such label.

@ezio-melotti Are you willing to create this new label? (I don't know which color to use though so I leave it to you, but maybe some purple? (in between the issue red and the blue feature))

[AA-Turner]

Perhaps type-internal? If the goal is "to differentiate between [user-facing] features and refactorings".

[picnixz]

type-internal would also be interesting! because sometimes it's more of an internal thing (and we coud use it for the different Tools that we don't ship it yet)

[erlend-aasland]

What other types of changes would type-internal encompass, apart from refactorings?

[picnixz]

It could be something affecting the Tools for instance. I've opened the topic-tools label and saw that there were arguments in favor and against in a previous discussion. However, what we can probably safely say, is that whatever is in Tools is roughly something internal. Now, I don't know if mixing type-bug and type-internal would make sense to others or type-internal and type-feature in that case.

Nevertheless, I would be happy if we had a way to distinguish features from refactoring because most of the time, refactoring doesn't require a what's new and refactoring can be follow-ups of bug fixes, in which case those are not backported.

[erlend-aasland]

Regarding refactoring, @gpshead 👆

[gpshead]

+1 to this type-refactor label.

I'd define it similar to "no visible behavior change, no non-internal API changes, no ABI changes" usually involving code reorganization to ease future work. Refactorings can sometimes be safe to backport which is something a feature does not do.

I think type-internal would be less useful. It doesn't communicate purpose as well. Ex: bugfixes and features can both be entirely internal, they just happen to also have a visible behavior change.

[erlend-aasland]

ISTM there is some support and little opposition for adding a type-refactor label. I suggest we add it and see how it fares. If it ends up being unused, we can just remove it.

[erlend-aasland]

@ezio-melotti, would you mind adding the type-refactor label?

[ezio-melotti]

Done: https://github.com/python/cpython/labels/type-refactor