Steven D'Aprano writes: > Or maybe, as a developer (not an end-user of an app), you could be more > proactive in reporting those warnings to the third party, and > encouraging them to fix them. Maybe even submitting a patch?
As Chris B points out, it's quite possible that (generic) you have already reported, and maybe even submitted that patch, but you still have to wait for the release. Thing about submitting such patches -- I can't speak for Python programs, but in XEmacs I probably refused more warning-suppression patches than I accepted, because there was a deeper problem that needed to be fixed and the annoying warning was merely a side effect. And for any project, even if you submit a patch, there's no guarantee that the next version (or three) will contain it, which means vendoring the source. Urk! > Of course I understand that folks are busy maintaining their own > project, and have neither the time nor the inclination to take over > the maintenance of every one of their dependencies. But we > shouldn't just dismiss warnings in those dependencies as "warnings > I don't care about" and ignore them as Not My Problem. Sure, but it's still worth providing various kinds of automation. For example, it would be nice if downstream (us) could fire and forget reports of DeprecationWarnings, knowing that bug reporting systems would automatically identify and merge them. And for DeprecationWarnings, rather than patching, it would be usually be nice to suppress the warning, I think. Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7MY34PHQVOWGRCHUJ7MSMTPSP544MTV6/ Code of Conduct: http://python.org/psf/codeofconduct/
