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

[Bruno Haible]

Hi Collin,

> This is somewhat related since it deals with imports, but is there a
> reason why we don't just import things from modules directly?
> 
> Right now we have:
> 
>       from . import constants
>       # Define global constants.
>       APP = constants.APP
>       DIRS = constants.DIRS
>       joinpath = constants.joinpath
> 
> Typically I am used to seeing:
> 
>       from .constants import APP
>       from .constants import DIRS
>       from .constants import joinpath
>       # or on one line
>       from .constants import APP, DIRS, joinpath
> 
> Is there a functional or stylistic reason for doing it as we have it
> now?

I don't know. Maybe it is related to
https://stackoverflow.com/questions/16981921/relative-imports-in-python-3 ?

> As far as the Python code goes, one annoyance that I have is that
> sometimes it is hard to tell exactly which exceptions may be thrown by
> a function.

This typically requires experimentation. (Same problem as in other
programming languages/environments.)

> I'm not sure if it is frowned upon to catch all exceptions
> blanketly

It depends. If you can get away with catching a smaller set of exceptions,
it's better.

> but I would typically do this as an example:
> 
> import subprocess as sp
> import os
> try:
>     sp.run(['invalid-command', 'update-index', '--refresh'],
>            cwd=os.getenv('GNULIB_REFDIR'), stdout=sp.DEVNULL, 
> stderr=sp.DEVNULL)
> except Exception as error:
>     print(error)

This (i.e. especiall the stderr=sp.DEVNULL) is OK if the program's diagnostics
are not very useful, or if the user can repeat the command separately (that's
the case for our 'git update-index --refresh' command here).

> We could just not
> redirect stderr to match the gnulib-tool.sh script.

Yes, as you noticed, this way of doing is OK for the case of commands
that generally don't produce warnings. That is, for which the stderr output
is non-empty if and only if the return code is != 0.

> Or we can use capture_output and check the return code, printing
> stderr only if the command fails [1]:
> 
> import subprocess as sp
> import os
> try:
>     result = sp.run(['git', 'update-index', '--bad-option'],
>                     cwd=os.getenv('GNULIB_REFDIR'), capture_output=True)
>     if result != 0:
>         print((result.stderr.decode(encoding='utf-8')))
> except Exception as error:
>     print(error)

This idiom is more widely applicable, indeed: It works also for commands
that may produce warnings.

Bruno