Yilei

Adding more context: we have a custom lint checker that wants to warn the used of non-subscripted generic types in annotations. For example: ``` CustomType1 = typing.Tuple CustomType2 = typing.Tuple[int]...

@gagern you are right, this requires more advanced analysis. In Python 3.9+, it also has the same issue for the builtin collections classes like `dict`, `tuple`, `list` etc now that...

Hmm, this isn't necessarily the opposite of #2553. There are a few options that they can co-exist: 1. We could restrict this to cases where they are within the line...

I don't have a strong preference between this (explicit str concat) and parens (#3159). There are some cases I think parens have better readability, e.g. ```python some_list = [ (...

Agreed that we should try to use the same formatting in function calls v.s. list/tuple/set literals. I don't think there exists a clear call that either explicit-str-concat or use-parens would...

Hmm, focusing on _existing parens_ here, this actually fits _Black_'s paren management [here](https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#parentheses): > Please note that _Black_ does not add or remove any additional nested parentheses that you might...

@felix-hilden hmm, I think we draw a different line between "organising" and "non-organising" parens. The purpose of them is to (significantly) increase readability, so maybe we should really call them...

Thanks for the bug report and analysis! You are right, the code should check `if self._inherited_absl_flags is not None` instead. I'll try that.

#246 is possibly related since that's also caused by a comment before the function def.

Looking at `EmptyLineTracker`, it is indeed the same underlying issue as #246, that the tracker isn't capable of doing this when there are preceding standalone comments. I'll take a stab...