All changes were created by running
"pyupgrade --py3-only"
and committing the results. Although this has been performed in the
past, newer versions of pyupgrade can automatically catch more
opportunities, notably list comprehensions can use generators instead,
in the following cases:
- unpacking into function arguments as function(*generator)
- unpacking into assignments of the form x, y = generator
- as the argument to some builtin functions such as min/max/sorted
Also catch a few creeping cases of new code added using older styles.
The previous commit bd2fcb268b
accidentally used the wrong var so the param name was missing,
leading to an error of "unrecognized arguments" for the
datadirs parameter value.
We ended up passing a NoneType as the program binary, which is a very
awkward way to communicate an error when failing to write a basic
package version file.
There were two allowed kwargs that were unused, I've dropped them for
now, though I need to check if they were documented. If they are then we
need to deprecate them to remove them, otherwise we'll just leave them
removed.
This does not convert the build side, or remove any of the checking it
does. We still need that for other callers of custom target. What we'll
do for those is add an internal interface that defaults things, then
we'll be able to have those callers do their own validation, and the
CustomTarget validation machinary can be removed.
Fixes#9096
Hardcoding the name is fragile, and enabling it based on the existence of
/etc/debian_version (as the is_debianlike helper does) will result in
incorrect paths if the Python binary is not provided by Debian.
Using the deb_system distuils scheme instead makes sure we use the
install path from the current interpreter, which Debian could change
between releases, and gives us the correct value on Python installations
that are not provided by Debian (eg. deadsnakes, Github Action Python,
etc.)
Do notice, though, that there is still no guarantee that these are the
correct paths, as they assume all schemes paths have the install prefix
as a base, see #9284.
Signed-off-by: Filipe Laíns <lains@riseup.net>
I ran into one of these from LGTM, and it would be nice if pylint could
warn me as part of my local development process instead of waiting for
the CI to tell me.
This really is more of a struct than a dict, as the types are disjoint
and they are internally handled, (ie, not from user input). This cleans
some things up, in addition I spotted a bug in the ModuleState where the
dict with the version and license is passed to a field that expects just
the version string.
In commit 3c4c7d0429 the qresource
variable stopped being overwritten with a mesonlib.File, which is
reasonable. However, one call site for it which relied on being a built
file did not get renamed when needed.
Make the build target use the built file.
And more accurate too, TBH. Currently it says it is building "lang.mo",
even though it is actually building "domain.mo" inside
lang/LC_MESSAGES/.
Since meson loudly complains if I try to name the display name
"lang/domain.mo", name it with a dash instead of a slash. The actual
name isn't a priority here IMO, and this is nicely readable.
Removed in commit 487d45c1e5 but perhaps
it should not have -- people may have been depending on ensuring those
are built somehow. Even though the internal implementation changed and
it is now built by the all target, let's keep the old target around too.
Now it just aliases the actual build rules, though.
Users may wish to make use of these files for their own purposes.
For example, the -pot and -update-po pseudo targets could be reused in
an alias_target(), and at least one person wanted to reuse the built .mo
files as custom_target input.
Fixes#6227
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
The sysconfig paths are, by default, correct for every OS -- they are
supposed to follow the scheme that python knows about per default.
For some reason, this overrode the scheme to posix_prefix, which is the
default for posix OSes like linux and macOS, but wrong on Windows.
Simply deleting this entirely makes everything that used to work, still
work, and a couple new things start working.
The tool needs to run the preprocessor (but does not actually produce
compiled outputs), and meanwhile ignores lots of flags it doesn't think
it needs. In the case of -D_FORTIFY_SOURCE=... this is only valid if -O
is there too, but otherwise spits out confusing warnings.
The warnings are spurious and can be safely ignored, but in this case
let's go the extra mile and fix g-ir-scanner's upstream bug by removing
the fortify flag first.
Fixes#9161
rsplit(..., 1) always produces exactly one split, by design, there's no
need to then join a 1-element list via a generator comprehension after
extracting the end of it via pop. If this commit message sounds
confusing, then so was I when trying to figure out what this actually
did and if it needed extracting to PythonExternalModule.
Eli Schwartz
Dan Streetman
Daniel Mensinger
Dylan Baker
Xavier Claessens
Filipe Laíns
Ting-Wei Lan
Tristan Partin