Warnings (was Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"])

[Chris Angelico]

On Sat, Oct 7, 2017 at 11:19 AM, Steve D'Aprano
<steve+python at pearwood.info> wrote:
> On Sat, 7 Oct 2017 05:33 am, Grant Edwards wrote:
>
>> On 2017-10-06, Marko Rauhamaa <marko at pacujo.net> wrote:
>>
>>> The reason a daemon usually opens dummy file descriptors for the 0, 1
>>> and 2 slots is to avoid accidents. Some library might assume the
>>> existence of those file descriptors. For example, I often see GTK print
>>> out diagnositic messages.
>>
>> I run a lot of GTK programs from the command line, and I would say 90%
>> or more of them spew a steady stream of meaningless (to the user)
>> diagnostic messages.  That's pretty sloppy programming if you ask
>> me...
>
> Indeed.
>
> If you ever start to doubt that the average quality of software is "crap", try
> running GUI applications from the command line and watch the stream of
> warnings and errors flow by. They range from relatively trivial warnings that
> correctly sized icons are missing, to scary looking warnings about
> uninitialised pointers.
>
> Developers: why do you bother to log warnings if you're never going to fix the
> damn things?

The warnings usually come from the library, but the bugs are in the
application. So the question is: is it right for a library to raise
console warnings like that? Under what circumstances and to what
destinations should a library report on potential problems?

IMO the console belongs to the application, not a library. But that
means that the logging of warnings needs to be done by the app. I'm
not sure what the solution is.

ChrisA