If your code is designed to work with Python 3.10 or newer, you want to use the PEP 604 syntax, using ... | None union syntax, and not use typing.Optional:

def test(a: dict[Any, Any] | None = None) -> None:
    #print(a) ==> {'a': 1234}
    #or
    #print(a) ==> None

def test(a: list[Any] | None = None) -> None:
    #print(a) ==> [1, 2, 3, 4, 'a', 'b']
    #or
    #print(a) ==> None

Code that still supports older Python versions can still stick to using Optional. Optional[...] is a shorthand notation for Union[..., None], telling the type checker that either an object of the specific type is required, or None is required. ... stands for any valid type hint, including complex compound types or a Union[] of more types. Whenever you have a keyword argument with default value None, you should use Optional.

So for your two examples, you have dict and list container types, but the default value for the a keyword argument shows that None is permitted too so use Optional[...]:

from typing import Optional

def test(a: Optional[dict] = None) -> None:
    #print(a) ==> {'a': 1234}
    #or
    #print(a) ==> None

def test(a: Optional[list] = None) -> None:
    #print(a) ==> [1, 2, 3, 4, 'a', 'b']
    #or
    #print(a) ==> None

There is technically no difference between using Optional[] on a Union[], or just adding None to the Union[]. So Optional[Union[str, int]] and Union[str, int, None] are exactly the same thing.

Personally, I'd stick with always using Optional[] when setting the type for a keyword argument that uses = None to set a default value, this documents the reason why None is allowed better. Moreover, it makes it easier to move the Union[...] part into a separate type alias, or to later remove the Optional[...] part if an argument becomes mandatory.

For example, say you have

from typing import Optional, Union

def api_function(optional_argument: Optional[Union[str, int]] = None) -> None:
    """Frob the fooznar.

    If optional_argument is given, it must be an id of the fooznar subwidget
    to filter on. The id should be a string, or for backwards compatibility,
    an integer is also accepted.

    """

then documentation is improved by pulling out the Union[str, int] into a type alias:

from typing import Optional, Union

# subwidget ids used to be integers, now they are strings. Support both.
SubWidgetId = Union[str, int]


def api_function(optional_argument: Optional[SubWidgetId] = None) -> None:
    """Frob the fooznar.

    If optional_argument is given, it must be an id of the fooznar subwidget
    to filter on. The id should be a string, or for backwards compatibility,
    an integer is also accepted.

    """

The refactor to move the Union[] into an alias was made all the much easier because Optional[...] was used instead of Union[str, int, None]. The None value is not a 'subwidget id' after all, it's not part of the value, None is meant to flag the absence of a value.

Side note: Unless your code only has to support Python 3.9 or newer, you want to avoid using the standard library container types in type hinting, as you can't say anything about what types they must contain. So instead of dict and list, use typing.Dict and typing.List, respectively. And when only reading from a container type, you may just as well accept any immutable abstract container type; lists and tuples are Sequence objects, while dict is a Mapping type:

from typing import Mapping, Optional, Sequence, Union

def test(a: Optional[Mapping[str, int]] = None) -> None:
    """accepts an optional map with string keys and integer values"""
    # print(a) ==> {'a': 1234}
    # or
    # print(a) ==> None

def test(a: Optional[Sequence[Union[int, str]]] = None) -> None:
    """accepts an optional sequence of integers and strings
    # print(a) ==> [1, 2, 3, 4, 'a', 'b']
    # or
    # print(a) ==> None

In Python 3.9 and up, the standard container types have all been updated to support using them in type hints, see PEP 585. But, while you now can use dict[str, int] or list[Union[int, str]], you still may want to use the more expressive Mapping and Sequence annotations to indicate that a function won't be mutating the contents (they are treated as 'read only'), and that the functions would work with any object that works as a mapping or sequence, respectively.

Python 3.10 introduces the | union operator into type hinting, see PEP 604. Instead of Union[str, int] you can write str | int. In line with other type-hinted languages, the preferred (and more concise) way to denote an optional argument in Python 3.10 and up, is now Type | None, e.g. str | None or list | None.

The "modern" way to write this is str | None. Traditionally, I used Optional[str], mostly because Optional existed specifically for this purpose.

All I read is speculations.

I'd rather give you a feedback from practice (I'm a professional trainer and dev, I've been expose to a lot of code and coders, including using type hints).

• type hints are not well know. A lot of people still don't know about it.

• people that know about it didn't take time to learn about it. Typing is not that popular amongs Python dev. They are popular amongs dev in big teams or comming from stricter languages. The feature is here to accomodate them.

• a lot of Python dev are not... dev. I work with teachers, geogramaticians, mathematicians, etc. They could not care less about code, it's just a mean to an end, and typing just get in their way.

• a lot of dev are not... good dev. I works with a lot of people making loads of money 20k/month) with badly coded websites. They don't know a lot of about programming, just enough to run their business. They don't want to invest into something new, like type hints, that make things cleaners. Clean is not their problem.

Now there is a small minority of people, like me, who are interested in that feature. They used it. Here is there result:

• the documentation sucks. The tutorials suck. You basically spend hours just to express anything more complex than the basic types.

• it's not ready : mypy and pycharm support is partial, and sometimes buggy. I had sometime to use some very stupid hacks: https://github.com/Tygs/ww/blob/master/src/ww/types.py

• setuping mypy is much more work that it should be.

• the spec is incomplete: dunder methods are not detected yet, which means duck typing cannot be easily defined in your annotation.

• it's takes a lot of time to figure out how to do anything.

• even if you do everything right, the tooling doesn't give you that much safety net yet.

All in all, I'm still considering type hints a good things. It needs to happen. But in it's current state, it's a pain.

I don't know whether TypeScript enforces type constraints at compile or run time. But Python does support type hints.

Python 3.0 introduced function annotations as defined in PEP 3107. They work like this:

def log_in(login: 'Login', password: 'Password') -> 'Return value':
    # ...

log_in.func_annotation['login'] # => 'Login'
log_in.func_annotation['password'] # => 'Password'
log_in.func_annotation['return'] # => 'Return value'

You can annotate the parameters and the return value with any object.

This can be used to implement type hints. Python 3.5 introduces the typing module. You can implement a decorator that'd perform run-time type checking.