Magic Python textmate changes broke constants

[funkindy]

• Pylance version: 2025.10.3
• OS and version: MacOS
• Python version 3.12 (venv, uv)

Repro Steps

I use custom color scheme for years: https://marketplace.visualstudio.com/items?itemName=jdinhlife.gruvbox

1. Install 2025.10.3

Expected behavior

type hints has this coloring:

Actual behavior

Colors are not the same after 2025.10.3, also there are less semantics in coloring. It is almost all-yellow

If i downgrade pylance version to 2025.10.2 or lower, colors become correct. Maybe it is not a bug, but for me personally it is super-inconvenient, because i use this gruvbox variant for years

[github-actions[bot]]

Hi @funkindy, I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

---

Explanation:

• Pylance 2025.10.3 now applies semantic highlighting to type hints (token type typeHint), which relies on your theme’s semanticTokenColors rules.
• If your Gruvbox variant doesn’t define a color for typeHint, VS Code falls back to its default semantic color (often yellow), making all annotations appear the same.
• Use Developer: Inspect Editor Tokens and Scopes to verify the semantic token type and scope that Pylance is assigning to your type hints.

---

Potential Duplicate Issues – These issues may be duplicates of your report, but may differ in some of the details.

• Type annotations context semantically highlighted incorrectly? – Troubleshooting via token inspector and checking editor.semanticTokenColorCustomizations.
  https://github.com/microsoft/pylance-release/issues/708
• Pylance makes the syntax highlighting in my VSCode theme (Tokyo Night Storm) become unbalanced – Effects of semantic highlighting on theme colors.
  https://github.com/microsoft/pylance-release/issues/5570

---

Potential Workarounds:

• Define semantic token rules for type hints in your settings.json, matching your Gruvbox palette. For example:

  "editor.semanticTokenColorCustomizations": {
    "[Gruvbox Dark]": {
      "rules": {
        "*.typeHint": "#A6E22E",       // adjust to your preferred type-hint color
        "*.parameter": "#F9F1A5"      // optional: customize parameter hint color
      }
    }
  }
  

• Inspect tokens with “Developer: Inspect Editor Tokens and Scopes” to confirm which semantic token types and modifiers need overrides.

The team will respond to your issue shortly. Please note this is a trial feature and may not be fully accurate. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or was incorrect, please give it a 👎. Your feedback helps us improve!

[gordiig]

+ To that issue I have different color scheme, but colors for type annotations changed too. Also, some types have one color, others have another. Default values changed colors too.

It is harder to read code now. Not because colors changed, but because they've changed very inconstantly

[rchiodo]

Can somebody post some code that causes the problem? We updated our use of Magic Python to the latest version (it's what provides most of the tokens for colorization). It's probably characterizing the types in your example as different tokens than it used to.

The question is whether or not the new tokens are more correct or not. Your theme may just not be recognizing the tokens that are being output now.

For me, with this code:

def foo(a: Optional[str] = None) -> str:
    ...

I get this set of tokens for 2025.10.3:

And this set of tokens for 2025.10.2:

You can see the text mate scopes have changed.

[rchiodo]

Semantic tokens have stayed the same (which are provided by Pylance) so any difference here should be from text mate scoping

[funkindy]

@rchiodo sample:

def foo(a: str | None = None) -> list[dict[str, str]]: ...

2025.10.2 (Which is as expected)

2025.10.3

[rchiodo]

The colors aren't the important part. It's the tokens:

Your theme must not support the support.type.builtin.python scope. It's why it's coming out different. That's the new scope that was introduced in 2025.10.3

[rchiodo]

Although I'm surprised your theme isn't colorizing the semantic token. It should color a 'class' the same between both versions.

[rchiodo]

Yeah it doesn't look like it has a coloring for class:

This is for 2025.10.3

This is for 2025.10.2

It looks like it has a coloring for meta.function.python. Which is no longer one of the textmate scopes. That explains the difference.

[funkindy]

Yeah i see. But is it as expected that default (most popular obv) themes are also affected?

Dark+ 2025.10.2 - Note that None looks the same in annotation, param default and as a basic variable. It is very important for readability for me personally

Dark+ 2025.10.3 - None has different colors in function and as a module var are different (!)

here also list somehow has different colors in the same annotation expr:

[funkindy]

@rchiodo sorry, i dont get why is this closed.

There are variours scope changes for textmate scopes in 2025.10.3 that brokes a lot of color themes. e.g.:

1. constant.language.python is now not relevant to type hints (None, Ellipsis broken in type annotations and cannot be adjusted) they are now support.type.python inside type hints

2. meta.indexed-name.python, meta.item-access.python - also dropped from annotations in favor of support.type.python

so it loses flexibility also :(

[rchiodo]

Sorry but my colors don't come out that way. Perhaps you have some settings overriding things.

I'm using this:

And this is the colors I get for your example:

If you use 'Developer : Inspect Editor Tokens and Scopes', it should show you where the color is coming from.

For me the 'None' in the parameters field is actually a semantic color:

The Default Dark theme does support the 'support.type' textmate scope though, so support.type.python should work even if the semantic color isn't being used.

[rchiodo]

And it seems I was wrong, 'meta.function.python' is still one of the textmate scopes, it's just support.type.python comes first now. It wasn't actually removed.

[rchiodo]

I get the same colors on 2025.10.2. Just the support.type token doesn't match so I don't see that in the tokens and scopes (it only matches the semantic token):

[rchiodo]

Maybe you have this turned off?

That gives me this for 2025.10.3

And this for 2025.10.2:

Which looks like what you had said. 'constant.language.python' is no longer detected by the textmate scope. Instead it picks the 'support.type' color.

Given that our semantic token provider calls this a constant, then yeah the text mate language file seems wrong in this case.

[funkindy]

Yes, sorry, i had semanticHighlighting.enabled=false during those tests of Dark+. Now everything is the same with you.

So i decided to switch to default theme because even with tweaks i couldnt achieve the same result with gruvbox in 2025.10.3

The thing i really dont like is that with this semantic tokens i cant assign different colors to func parameters and variable passed to it (in nested case both parts has semantic token type = parameter with no modifier)

i`d like to make it look like this:

which is a default look if i disable semanticHighlighting (but this leads to list/None and other problems).

Textmate assign different scope to them and it makes sense to me. It would be nice to have some modifier maybe for right part of the assignment.

[rchiodo]

Maybe we should open a different issue for adding a new semantic token for values passed as parameters. Right now the semantic token for the value and the keyword is the same:

[iutlu]

Thanks for opening the issue @funkindy! I'd thought that I was going crazy 🙂

Reverted to 2025.10.2, things are much saner.

Theme: Monokai Pro, and I have not played with the semanticHighlighting setting

[funkindy]

Another point in diff editor. Different colors in default Dark+ with default settings. Why did you rename this issue? It is hard to find now obv.

[rchiodo]

Not sure what the error you're showing in the diff editor is. The left side doesn't have any textmate scopes. The right side is working better than it was in 2025.9.1 for me.