This isn't safe given the way python implements default arguments.
Basically python store a reference to the instance it was passed, and
then if that argument is not provided it uses the default. That means
that two calls to the same function get the same instance, if one of
them mutates that instance every subsequent call that gets the default
will receive the mutated instance. The idiom to this in python is to use
None and replace the None,
def in(value: str, container: Optional[List[str]]) -> boolean:
return src in (container or [])
if there is no chance of mutation it's less code to use or and take
advantage of None being falsy. If you may want to mutate the value
passed in you need a ternary (this example is stupid):
def add(value: str, container: Optional[List[str]]) -> None:
container = container if container is not None else []
container.append(value)
I've used or everywhere I'm sure that the value will not be mutated by
the function and erred toward caution by using ternaries for the rest.
There is basically no such word in english, "nonexistant".
American people use "nonexistent" and British people used
to have "non-existent", but some time ago they did away with
the hyphens, so there is only one option really: "nonexistent".
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
There is no reason to not always do this. Without this, we end up with
a relative path to meson.py in build.ninja files when meson.py is
launched using subprocess.Popen and friends from the meson source root.
This was causing the unittests to intermittently fail when regen was
getting invoked by the pic test. Funnily enough, this only happened when
run via ./run_tests.py because __file__ was 'run_unittests.py' in that
(as opposed to './run_unittests.py') case which made
os.path.dirname(__file__) be '', and the os.path.split test in meson.py
thought that meson.py was invoked via PATH.
When installing Meson, distutils may choose to put shim scripts in the
`PATH` that only set up the egg requirements before launching the real
`meson.py` contained in the egg.
This means that `__file__` points to the real `meson.py` file, but
launching it directly is doomed to fail as it's missing the metadata
contained in the shim to set up the path egg, resulting in errors when
trying to import the `mesonbuild` module.
A similar issue affects Meson when installed as a zipapp, with the
current code going great lengths to figure out how to relaunch itself.
Using `argv[0]` avoids these issues as it gives us the way the current
executable has been launched, so we are pretty much guaranteed that
using it will create another instance of the same executable. We only
need to resolve relative paths as the current working directory may
get changed before re-launching the script, and using `realpath()` for
that saves us the trouble of manually resolving links and getting caught
in endless loops.
This also mean that `meson_script_file` no longer necessarily point to a
absolute file, so rename it to `_launcher` which hopefully would be less
prone to inducing false assumptions.
When installing Meson distutils may choose to put shim scripts in the
PATH that only set up the egg requirements before launching the real
`meson.py` contained in the egg.
This means that __file__ points to the real `meson.py` file, but
launching it directly is doomed to fail as it's missing the metadata
contained in the shim to set up the path egg, resulting in errors when
trying to import the `mesonbuild` module.
A similar issue affects Meson when installed as a zipapp, with the
current code going great lengths to figure out how to relaunch itself.
Using argv[0] avoids these issues as it gives us the way the current
executable has been launched, so we are pretty much guaranteed that
using it will create another instance of the same executable.
Daniel Mensinger
Dylan Baker
Xavier Claessens
Daniel Schulte
Mike Sinkovsky
Jussi Pakkanen
Igor Gnatenko
Nirbheek Chauhan
Franz Zapata
Emanuele Aina