It's really inconvenient to want a thing that is always a list, but not
be able to provide a default value of a list because of mutation. To
that end the typed_kwargs method now makes a shallow copy of the default
when using a `ContainerTypeInfo` as the type. This mean that using a
default of `[]` is perfectly safe.
When mutable items are stored in an lru cache, changing the returned
items changes the cached items as well. Therefore we want to ensure that
we're not mutating them. Using the ImmutableListProtocol allows mypy to
find mutations and reject them. This doesn't solve the problem of
mutable values inside the values, so you could have to do things like:
```python
ImmutableListProtocol[ImmutableListProtocol[str]]
```
or equally hacky. It can also be used for input types and acts a bit
like C's const:
```python
def foo(arg: ImmutableListProtocol[str]) -> T.List[str]:
arg[1] = 'foo' # works while running, but mypy errors
```
this is a place that *must* only be imported inside a if
typing.TYPE_CHECKING block. It is a mixture of smoothing over thinigs
that moved from typing_extensions to typing in later python versions and
useful but typing only code.
This makes typing_extensions required for python versions older than
3.8 *when running mypy*. typing_extensions should *only* be imported
inside an `if typing.TYPE_CHECKING` block (include the new _typing.py
module) to ensure that it doesn't become a runtime dependency
This is problematic when we meson is installed in the different
root(say C:) while building from another root(say D:).
This is how it is done in mesonpep517 and causes problems
because of that.
Custom objects returned by modules must be subclass of ModuleObject and
have the state argument in its methods.
Add MutableModuleObject base class for objects that needs to be deep
copied on assignation.
The only advantage they have is they have the interpreter in arguments,
but it's already available as self.interpreter. We should discourage
usage of the interpreter API and rely on ModuleState object instead in
the future.
This also lift the restriction that a module method cannot add build
targets, but that was not enforced for snippet methods anyway (and some
modules were doing it) and it's really loose restriction as it should
check for many other things if we wanted to make it consistent.
Daniel Mensinger
Jussi Pakkanen
Xavier Claessens
Dylan Baker
Naveen M K