Re: gnulib-tool.py: Use absolute imports consistently.

[Bruno Haible]

Hi Collin,

> I want to make the imports and use of functions from other modules
> consistent. This patch makes all files use absolute imports like
> main.py. So this:
> 
>    from pygnulib.GLEmiter import GLEmiter
> 
> instead of:
> 
>    from .GLEmiter import GLEmiter

Consistency is not a good enough reason to do that. If we commit a
patch like this, in a month we may want to commit the opposite patch,
with the rationale that the package name 'pygnulib' should not be
mentioned so often.

Really, there's not much to win here: The imports work and produce
no warnings. So, best leave them alone and spend your time on areas
that do need work.

> I want to make another change but would like opinions before writing
> the patch. Right now we have:
> 
>    import os.path
>    from pygnulib import constants
>    [...]
>    DIRS = constants.DIRS
>    substart = constants.substart
>    isfile = os.path.isfile
> 
> This works fine, but stops editors from tracking function usage
> properly. For example, GLEmiter might use 'substart' 30 times but an
> editor will say there is only 1 usage since we define
> 'constants.substart' to a variable.

OK, patch welcome. I assume that when Dmitry used this style of assignments,
the Python 2.7 / 3.0 imports were not so well developed as they are today.

> While making that change it would also be a good time to fix another
> inconsistency. Right now some files will use a mix of functions
> prefixed and not prefixed by a module. For example, both
> 'os.path.isfile' and 'isfile'. I think the best solution is to import
> our own code directly and use the module prefix for standard library
> (and third-party code if ever needed). So like this:
> 
>     # Import like this.
>     import os.path
>     from constants import substart
>     # Use them like this.
>     os.path.join(...)
>     substart(...)
> 
> This feels like what I am used to seeing.

Sounds OK to me. Thanks for looking around what are the common Python
idioms.

> Slight exception for the subprocess module, since everyone does
> 'import subprocess as sp'. It would feel strange not too. :)

OK.

Bruno