On 5/3/24 6:03 PM, Bruno Haible wrote:
>> In main.py a call to mkdtemp() was the use of the 'tempfile' module
>> prefix.
> 
> Oh, that would have led to a runtime error, right?

Yes, it would only be seen if it entered the section of code where
modules have an incompatible license. So the program would fail with a
backtrace instead of a helpful error message.

> Can you please add, to the first line of the ChangeLog entry, a note
> that tells us when the regression was introduced? Such as
>    (regression 2024-xx-xy)
> or
>    (regr. yesterday)
> 
> The motivation for such an annotation is to get us thinking about
>   - how the regression could have been avoided,
>   - how the regression could have been noticed earlier,
>   - whether we need extra measures when we see, say, 5 regressions in a
>     single week.

Oops, yes I should have done that in the commit message sorry.

I've never modified a ChangeLog entry before. Is the proper way to
just modify it and commit with a one line summary? In other words, do
I need another ChangeLog entry in that commit?

I don't want to mess it up any further...

> In this case, maybe some Python style checker would have produced a
> warning, right? Would it be possible to add a Makefile rule that checks
> for the absense of such warnings, and then use this Makefile rule in the
> continuous integration that runs at least once a week?

Hmm, I like that idea. I would have to find what tool works best for
that.

I think PyCharm didn't load the whole file all the way. It would show
a warning once you scrolled down to the bottom of the file. That also
isn't very well suited for the Makefile use.

I think mypy gives a warning about it. But that is a type checker that
produces a lot of spam at the moment. With that change reverted:

    $ mypy main.py | grep 'name-defined'
    main.py:1407: error: Name "mktemp" is not defined  [name-defined]

I want to gradually improve the ability of it's type checking. But
that involves making sure the code *improves* with the changes. In
some cases you can silence the warnings with worse code. :)

I'll do some research into seeing if there are tools more suited
towards that.

Collin

Reply via email to