On Sat, Oct 7, 2017 at 11:19 AM, Steve D'Aprano <steve+pyt...@pearwood.info> wrote: > On Sat, 7 Oct 2017 05:33 am, Grant Edwards wrote: > >> On 2017-10-06, Marko Rauhamaa <ma...@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 -- https://mail.python.org/mailman/listinfo/python-list
