n as *soft keywords*.  The identifiers "match", "case", "type" and
"_" can syntactically act as keywords in certain contexts, but this
distinction is done at the parser level, not when tokenizing.

As soft keywords, their use in the grammar is possible while still
preserving compatibility with existing code that uses these names as
identifier names.

"match", "case", and "_" are used in the "match" statement. "type" is
used in the "type" statement.

Changed in version 3.12: "type" is now a soft keyword.


Reserved classes of identifiers
===============================

Certain classes of identifiers (besides keywords) have special
meanings.  These classes are identified by the patterns of leading and
trailing underscore characters:

"_*"
   Not imported by "from module import *".

"_"
   In a "case" pattern within a "match" statement, "_" is a soft
   keyword that denotes a wildcard.

   Separately, the interactive interpreter makes the result of the
   last evaluation available in the variable "_". (It is stored in the
   "builtins" module, alongside built-in functions like "print".)

   Elsewhere, "_" is a regular identifier. It is often used to name
   “special” items, but it is not special to Python itself.

   Note:

     The name "_" is often used in conjunction with
     internationalization; refer to the documentation for the
     "gettext" module for more information on this convention.It is
     also commonly used for unused variables.

"__*__"
   System-defined names, informally known as “dunder” names. These
   names are defined by the interpreter and its implementation
   (including the standard library). Current system names are
   discussed in the Special method names section and elsewhere. More
   will likely be defined in future versions of Python.  *Any* use of
   "__*__" names, in any context, that does not follow explicitly
   documented use, is subject to breakage without warning.

"__*"
   Class-private names.  Names in this category, when used within the
   context of a class definition, are re-written to use a mangled form
   to help avoid name clashes between “private” attributes of base and
   derived classes. See section Identifiers (Names).
