Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 27.

[Collin Funk <collin.funk1@gmail.com>]

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