On 2/23/24 3:51 PM, Bruno Haible wrote: > I.e. you meant to write > mode != None > not > modules != None > ?
Oops. I'm not sure how I missed this in your original email as well... You are correct. It should be "mode != None". I should have a patch ready in a bit to fix another item in the gnulib-tool.py.TODO. If you would like I could fix that typo along with it. Or you can commit the change yourself if you would prefer. Thanks for the catch. > I recall having seen this warning. Was it from python itself? > Or from pycodestyle or pylint? (Cf. the comments at gnulib-tool.py > line 29..33) > > But I don't recall whether this warning was justified or bogus. I'd imagine that most of the code linters and style checkers would warn about it. It seems to be error code E711 for pycodestyle which is disabled by the command in that comment [1]. I mentioned it more out of habit though. I tend to find the Python tools confusing so I mostly avoid them (which is probably a bad habit). There is like 20 separate linters so I never know which one is the most "standard" if that makes sense... The difference between "==" and "is" can cause actual bugs, but those typically don't involve comparisons to None. It is hard for me to imagine a situation where it would actually cause problems in that case. I'm not super familiar with Python though, so maybe someone who knows better can give their thoughts. Here is a silly example to show the difference, but of course you would never write it without intending the consequences. class Example: def __eq__(self, other): return True def main(): one = Example() print(f"one == None: {one == None}") print(f"one == 0: {one == 0}") print(f"one is None: {one is None}") if __name__ == "__main__": main() [collin@debian gnulib]$ ./test.py one == None: True one == 0: True one is None: False > And I'm not convinced Pathlib is a win here, because > - we are not targetting native Windows, only Unix platforms (that > includes Cygwin), > - it appears to have some extra learning curve besides 'import os'. Sure, that makes sense. There is definitely less benefit if you are not concerned with Windows paths. I'll stick to os.path since it seems everyone is comfortable with it. [1] https://pycodestyle.pycqa.org/en/latest/intro.html#error-codes