Also, removing these large type unions and using 'Any'. I've ran all
the test cases with Python 3.7 to double check it is compatible.
If we have 'var' of type 'str | bool' and we are sure it is a string
and want to do this:
new_var = var.split(' ')
you will see warnings from type checkers be
Here is two small patches to fix some pylint warnings. The first is
'consider-using-with'. This recommends to use context managers that
handle cleanup for you. In this case two Popen calls, but here is an
example with open():
with open(file_name, 'r') as file:
data = file.read()
On 4/4/24 7:25 PM, Bruno Haible wrote:
> Thanks for this, but it is incomplete: func_gnulib_dir depends on a couple
> of other functions, which need to be defined as well.
>
> Also, it is useful to follow the function reordering in gnulib-tool.sh
> from 2024-02-28. I'm therefore applying the two a
Hi Collin,
> Running this script:
>
> $ ./all-modules --version
> ./all-modules: line 44: func_gnulib_dir: command not found
> sed: can't read /ChangeLog: No such file or directory
> ./all-modules: line 65: /build-aux/mdate-sh: No such file or directory
> all-modules (GNU gnul
Hi Collin,
> The first patch attached fixes all of those warnings by adding the
> explicit chaining.
...
> The second patch disables that warning and changes the one occurrence
> of '{}' we have to 'dict()'.
Thank you! Both patches applied.
Bruno
Hi Bruno,
On 4/4/24 5:48 AM, Bruno Haible wrote:
> The only difference between the two outputs is the message between the two
> stack traces. The latter sounds like a program bug; therefore I would say,
> let's use the chaining — just in order to clarify that the second exception
> is intended.
A
Sam James wrote:
> At a glance, it looks like gettext's m4/fixautomake.m4 at
> least might be affected.
Yes, some *.m4 files in other packages are affected as well. Fixed now.
> I should really have all the GNU projects in one directory so I can
> easily grep in future.
For searching across many
Paul Eggert wrote:
> POSIX doesn't guarantee this, so the implication is that the
> tests should be skipped when Europe/Paris does not work.
I see the two time_r tests be SKIPped (previously they FAILed)
on Alpine Linux ≤ 3.14, whereas they succeed on Alpine Linux ≥ 3.17.
The difference between
Hi Collin,
> The first is W0707 [1]. It recommends chaining exceptions. So this:
>
> try: # Try to apply patch
> sp.check_call(command, shell=True)
> except sp.CalledProcessError:
> raise GLError(2, name)
>
> becomes:
>
> try: # Try to apply patch
> sp.chec
Bruno Haible writes:
> Sam James wrote:
>> For reasons once might be able to guess, I'm currently playing with
>> "known" M4 macros vs unseen serials and such.
>>
>> At the moment, my tool uses the format described at
>> https://www.gnu.org/software/automake/manual/html_node/Serials.html.
>>
>>
Right now I am seeing two warnings from pylint that I would like to
silence:
The first is W0707 [1]. It recommends chaining exceptions. So this:
try: # Try to apply patch
sp.check_call(command, shell=True)
except sp.CalledProcessError:
raise GLError(2, name)
becomes:
Sam James wrote:
> For reasons once might be able to guess, I'm currently playing with
> "known" M4 macros vs unseen serials and such.
>
> At the moment, my tool uses the format described at
> https://www.gnu.org/software/automake/manual/html_node/Serials.html.
>
> My reading of it implies that t
Guillem Jover wrote:
> > It may be unexpected to you, but it is very much intended.
>
> The only unexpected part (which I perhaps failed to convey) was that
> it is being taken into account with --force.
This is documented in
https://www.gnu.org/software/automake/manual/html_node/Serials.html
whe
Hi all,
For reasons once might be able to guess, I'm currently playing with
"known" M4 macros vs unseen serials and such.
At the moment, my tool uses the format described at
https://www.gnu.org/software/automake/manual/html_node/Serials.html.
My reading of it implies that the use in e.g. m4/buil
14 matches
Mail list logo
