Yuan and Dmitry, thank you for review and suggestions.
 
> Can we do this instead: in python--treesit-fontify-string, we check if
  string-interpolation feature is enabled, if it is, fontify string_start,
  string_content and string_end only; if not, fontify the whole string.
 
Done.
Enable interpolation highlighting only if 'string-interpolation is presented on the third level of treesit-font-lock-feature-list.
Personally, If I saw a f-string with an interpolation fontified as string, I would assume that it is bug.
Clearly it is not a string, so it should be highlighted distinctly.
But if it is a convention across all languages, we should follow it.
 
> I think "for var in range(3)" should be part of the "definition" feature
  because a variable is defined there. Alongside parameters.
 
I added it to definitions.
My thoughts about parameters. I started to extend rules for them since they are very limited now.
But I'm not sure what face to use for them.
I would like to not use the same face as for assignments, because I'd want to highlight them differently.
It seems that there is no appropriate face in font-lock.el, so I ended up creating my own face in my config.
Does it make sense to add new face for parameters in font-lock.el?
Or it is too small feature for its own face?
I also apply this face for keyword argument in function calls.  
 
 
Summary for all changes in the patch.
 
definition feature:
`for var in range(3)` highlight var as font-lock-variable-name-face
 
 
assignment feature:
var := 3 (named_expression)
var *= 3 (augmented_assignment)
Highlight var as font-lock-variable-name-face.
 
Make list_splat_pattern query more precise.
list_splat_pattern may appear not only in assignments: var, *rest = call(),
but in the parameter list too: def f(*args).
Highlight args only for the first case in assignment feature.
 
 
type feature:
Fontify built-ins (dict,list,etc.) as types when they are used in type hints.
support nested union types, for example `Lvl1 | Lvl2[Lvl3[Lvl3], Lvl2]`.
This structure is represented via nesting binary_operator and subscript nodes in the grammar.
Function python--treesit-fontify-union-types iterates over all children and highlight identifier nodes.
 
Fontify base class names in the class definition: class Temp(Base1, pack0.Base2):
Fontify class patterns in case statement: case [TempC() | bytes(b)]:
Highlight the second argument as a type in isinstance/issubclass call:
isinstance(var2, (str, dict, Type1)); issubclass(var1, int|str)
 
For all dotted names of a type highlight only the last part of the name,
e.g. collections.abc.Iterator.
 
 
decorator feature:
Highlight dotted names: @pytest.mark.skip
Function python--treesit-fontify-dotted-decorator iterates over all nested attribute nodes and highlight identifier nodes.
 
When font-lock-level is set 4, `skip` had function-call face in: @pytest.mark.skip(reason='t')
Add `:override t` to decorator feature to override function-call face.
 
 
string feature:
Enable interpolation highlighting only if string-interpolation is presented on the third level of treesit-font-lock-feature-list.
Fix fontification of strings inside of f-strings interpolation,
e.g. for f"beg {'nested'}" - 'nested' was not fontified as string.
 
 
function feature:
Do not override the face of builtin functions (all, bytes etc.) with
the function call face
 
 
keyword feature:
Add "is not"  to the `python--treesit-keywords` list.
 
 
 
11.12.2023, 10:10, "Yuan Fu" <casouri@gmail.com>:



On 12/10/23 4:00 PM, Dmitry Gutov wrote:

 On 10/12/2023 14:04, Denis Zubarev wrote:
  > Arguably, the last 2 lines are "variable references" rather than
 definitions
 `var := 3`  is assignment expressions. It allows variable assignments
 to occur inside of larger expressions. For example `if (match :=
 pattern.search(data)) is not None:`.
 It mostly used to define new variables and act on them if some
 condition is met.

 Ah, thanks! This feature is newer than my working experience with Python.
 
 My rationale for `var *= 3` was that it is shorthand for `var = var *
 3` and currently the `var` on the left hand side is fontified with
 `font-lock-variable-name-face`.

 I think ideally, in cases when "var =" is not the first occurrence for
 the same var in a given scope, we wouldn't highlight it as
 "definition" either.

 Speaking of font-lock-variable-use-face, I think it would be most
 useful if it helped with noticing typos (meaning, it would only be
 used for references to variables that have been defined previously,
 according to the rules of the language). But for that we still need to
 implement the scope tracking. And before that, well, my personal
 preference is not to highlight the references at all, but opinions
 differ.

Personally I regard the "assignment" feature to mean "any assignment",
rather than definition. But that's just me. For my personal taste, I
would make *= always highlight its LHS.

 I wanted shorthand form to be consistent with the full form.
 Your point makes sense too, I don't have strong opinion about this.
 Also I'm not sure now about `var[ii] = 1`, since it is actually
 accessing the list or dictionary element and
 `font-lock-variable-use-face` may suit better here.

 Yep. To sum up, I would add highlighting to your examples `for var in
 range(3)` and `var := 3` but not others.

IMHO, for the assignment feature, we should stick to the narrow
definition of assignments, ie, anything that looks like "a = b". Things
like "for var in range(3)" could be highlighted by variable feature, I
think.

And for var[i] = 1, I don't know either. I think I decided to not
fontify it back then, but it wasn't based on any strong reasoning.

 Question about new changes.
 Should I push them to this patch and provide description of new changes,
 or it would be better to wait for review and send them as new patch?

 I suggest sending an updated patch for review in this case, but you
 can also wait for Yuan's comments first.
 

If you can consolidate everything into a single patch, and pair it with
a summary, that'll be a great aid to me. Also, in case you don't know
yet, we follow certain format for commit messages, you can check it out
in the CONTRIBUTE file, "Commit messages" section.

Yuan