On 2017-11-07 14:17, Philipp A. wrote: > Nick Coghlan <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>> schrieb am > Di., 7. Nov. 2017 um 14:57 Uhr: > > Users of applications written in Python are not python-dev's users: > they're the users of those applications, and hence the quality of > that experience is up to the developers of those applications. […] > > > Thank you, that’s exactly what I’m talking about. Besides: Nobody is > “hosed”… There will be one occurrence of every DeprecationWarning in the > stderr of the application. Hardly the end of the world for CLI > applications and even invisible for GUI applications. > > If the devs care about the user not seeing any warnings in their CLI > application, they’ll have a test set up for that, which will tell them > that the newest python-dev would raise a new warning, once they turn on > testing for that release. That’s completely fine! > > Explicit is better than implicit! If I know lib X raises > DeprecationWarnings I don’t care about, I want to explicitly silence > them, instead of missing out on all the valuable information in other > DeprecationWarnings. > Also, errors should never pass silently. Deprecation warnings are future errors.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4