Re: [PATCH] gnulib-tool.py: Store the module name instead of computing it.

2024-03-31 Thread Collin Funk
Hi Bruno, On 3/31/24 5:12 AM, Bruno Haible wrote: > But when I look at your patch now, I see that it can be done in an even > simpler > way: > - From the path and the module name, you compute the directory. > The only use of that directory is to compute the path again. > - This directory

Re: [PATCH] gnulib-tool.py: Store the module name instead of computing it.

2024-03-31 Thread Bruno Haible
Hi Collin, > Not sure why I didn't do this in the first place to be honest... > Here is two patches. Most of the change is in these lines: > > if self.exists(module): > path, istemp = self.filesystem.lookup(joinpath('modules', > module)) > -result = GLModule(sel

Re: [PATCH] gnulib-tool.py: Store the module name instead of computing it.

2024-03-30 Thread Collin Funk
Hi Bruno, On 3/26/24 5:20 AM, Bruno Haible wrote: > Regarding the 'modules' subdirectory: When I see you replacing 2 lines of code > with 8 lines of code, and especially searching for a 'modules' file name > component, I wonder whether there's no simpler solution. > Namely, a module of name NAME c

Re: [PATCH] gnulib-tool.py: Store the module name instead of computing it.

2024-03-26 Thread Bruno Haible
Hi Collin, > Would you prefer one patch with all of the changes or one per file? One patch with all the changes of the same kind, please. Whereas different kinds of refactorings belong in different patches, I would say. > Since it is just you and I testing we can leave it as is. In the > future

Re: [PATCH] gnulib-tool.py: Store the module name instead of computing it.

2024-03-26 Thread Collin Funk
Hi Bruno, On 3/26/24 5:18 PM, Bruno Haible wrote: > Yes. Sounds good. Would you prefer one patch with all of the changes or one per file? I'm happy either way, so whatever would make it easier for you if you want to review the changes. > I'm reluctant to add a dependency on yet another environme

Re: [PATCH] gnulib-tool.py: Store the module name instead of computing it.

2024-03-26 Thread Bruno Haible
Hi Collin, > > Feel free to do so. Either in GLFileSystem only, or globally - as you like. > > I would prefer to do it globally. I find they make it easier to > reference code. Since we have *some* of the information in docstrings, > I would just remove those and turn them into actual type hints.

Re: [PATCH] gnulib-tool.py: Store the module name instead of computing it.

2024-03-26 Thread Collin Funk
Hi Bruno, On 3/26/24 3:19 PM, Bruno Haible wrote: > Feel free to do so. Either in GLFileSystem only, or globally - as you like. I would prefer to do it globally. I find they make it easier to reference code. Since we have *some* of the information in docstrings, I would just remove those and turn

Re: [PATCH] gnulib-tool.py: Store the module name instead of computing it.

2024-03-26 Thread Bruno Haible
Hi Collin, > The GLFileSystem.py file returns many tuples which is very much making > me want to add type hints. It is easier to glance at and understand > that way, in my opinion. Feel free to do so. Either in GLFileSystem only, or globally - as you like. > Right now GLFileSystem.lookup returns

Re: [PATCH] gnulib-tool.py: Store the module name instead of computing it.

2024-03-26 Thread Collin Funk
Hi Bruno, On 3/26/24 5:20 AM, Bruno Haible wrote: > Regarding the 'modules' subdirectory: When I see you replacing 2 lines of code > with 8 lines of code, and especially searching for a 'modules' file name > component, I wonder whether there's no simpler solution. > Namely, a module of name NAME c

Re: [PATCH] gnulib-tool.py: Store the module name instead of computing it.

2024-03-26 Thread Bruno Haible
Hi Collin, > But, atleast we are not back to taking 20 seconds to run ./test-all.sh. It's good that you are looking at the execution times. These __eq__ etc. methods are apparently heavily used. > It seems that Python has an index() function to find the first > occurrence of an item in a list, b

[PATCH] gnulib-tool.py: Store the module name instead of computing it.

2024-03-25 Thread Collin Funk
On 3/25/24 10:27 PM, Collin Funk wrote: > But that is an easy fix. I just have to figure out how to write it so > that it isn't ugly. :) I was not very successful at making it not ugly... It seems that Python has an index() function to find the first occurrence of an item in a list, but they don'