1628954 - [py3.8] third_party/python/gyp/pylib/gyp/input.py:1186: SyntaxWarning: "is" with a literal. Did you mean "=="?

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mike Hommey [:glandium]]

Running configure with python 3.8 issues the warning in the summary. It doesn't fail, though.

Comment 1

[Mike Hommey [:glandium]]

Other similar warnings during the build:

xpcom/ds/StaticAtoms.py:2585: SyntaxWarning: "is" with a literal. Did you mean "=="?
   if atom.atom_type is "PseudoElementAtom":
xpcom/ds/StaticAtoms.py:2589: SyntaxWarning: "is" with a literal. Did you mean "=="?
   elif atom.atom_type is "NonInheritingAnonBoxAtom" or atom.atom_type is "InheritingAnonBoxAtom":
xpcom/ds/StaticAtoms.py:2589: SyntaxWarning: "is" with a literal. Did you mean "=="?
   elif atom.atom_type is "NonInheritingAnonBoxAtom" or atom.atom_type is "InheritingAnonBoxAtom":
dom/bindings/GenerateCSS2PropertiesWebIDL.py:26: SyntaxWarning: "is not" with a literal. Did you mean "!="?
    if p.pref is not "":

Comment 2

[Ricky Stewart]

Attachment: Bug 1628954 - Don't use 'is' and 'is not' to perform comparison against strings in Python

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d829918b75e1
Don't use 'is' and 'is not' to perform comparison against strings in Python r=nalexander

Comment 4

[Mike Hommey [:glandium]]

You left out the gyp one.

Comment 5

[Ricky Stewart]

Whoops, my fault for not checking thoroughly in the title as well as the body of the post :)

It's third_party code. Do we have qualms with just making drive-by changes in-tree to third party code? I can throw together a PR since the problem still hasn't been fixed at HEAD and then update the vendored library but that'll take (substantially?) longer.

Comment 6

[Mike Hommey [:glandium]]

Considering current master of gyp is what we have in tree, and the rate of change in the gyp upstream repo, it looks like waiting for an upstream PR to be merged would only guarantee a delay, while it's likely that whenever we'd need to update gyp in the future the PR would have been merged and we wouldn't need to care about losing a local change to the vendored library.

That said, if you're going to file an upstream PR, it'd be good to fix MsvsSettings._TargetConfig too (see bug 1627163).

Comment 7

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/d829918b75e1

Comment 8

[Ricky Stewart]

Attachment: Bug 1628954 - Fix bad string comparison in gyp

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5d4a4de4bcff
Fix bad string comparison in gyp r=dmajor

Comment 10

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/5d4a4de4bcff