https://pylint.readthedocs.io/en/stable/user_guide/messages/refactor/prefer-typing-namedtuple.html
Says to using the class based typing.NamedTuple instead of
collections.namedtuple, which just constructs a class based off of
strings.
Here we are creating a dynamic class based on the fields in the SQL result.
It's only called once for a query, so I don't think speed is an issue.
Also it's not used by the completion, looks like just :history
With pylint 3 there is a new option: https://pylint.readthedocs.io/en/latest/user_guide/messages/convention/use-implicit-booleaness-not-comparison-to-zero.html
It's disabled by default but we enable all warnings and disabled them as
desired.
This one is of the opinion that:
if x == 0:
is bad and
if x:
is good.
I feel that the first one (x == 0) is more clear. We aren't checking for
truthiness here, we are checking for a literal value, its very
intentional.
One might argue that being precious about making the type here is
redundant in current year with type checking tooling and all that. But
there are like a hundred of these checks in the code base so it seems a
well established pattern anyhow.
In summary, the new warning doesn't have a very strong use case and we
would prefer to stick with out established pattern.
Slack now requires chrome 112+. At least one user says it still works
with 108 based. Although they did just do a UI refresh so I wouldn't be
surprised if something was broken with older versions.
Note that I'm not 100% sure that slack is actually doing a strict check
for 112, but based on their prior behaviour I assume so (they are
definitely checking for >99 so our old quirk is unhelpful at this
point).
Since I've told people to add ua-slack to their disabled quirks, should
I change the name of it now to make sure it gets re-enabled? Eh, they
can manage their own quirks.
We only want to be faking a newer chrome version, if we are already on a
newer one, we don't want to be faking an older one!
Another scenario is that we might want to fake a perpetually newer
version for some site. But that seems like a very problematic scenario
and I hope that never comes up.
Since the bug was fixed in qtbase it shouldn't matter what version of
PyQt (or webengine for that matter) you are running against. So pass
`compiled=False`.
Also expand the docstring of `check_version()` to explain a little more
what the `compiled` kwarg does. Based on a discussion here:
https://github.com/qutebrowser/qutebrowser/pull/7933#issuecomment-1732400960
What's still not clear to me is when the runtime and compiled Qt
versions can differ. I always have to rebuild PyQt when I switch Qt
versions, but maybe I'm doing something wrong there.
TODO: configure the linter to tell people to do this.
As an aside, I'm not sure I agree that this is a good idea. It seems the
f-string interpolation does have a cost when you are not logging at that
level, and we do support disabling the ram logger. But we can change it
with automation anyway.
This avoids having to mess about with static methods. And makes the test a bit
clearer as we aren't passing a class in place of an instance anymore.
Hopefully I put it in the right place. It's above the class where it is used.
Should it be at the top of the file? Bottom of the file? IDK
Florian Bruhin
qutebrowser bot
toofar
dependabot[bot]