Movatterモバイル変換
[0]ホーム
[Python-Dev] Proposal: go back to enabling DeprecationWarning by default
Nick Coghlanncoghlan at gmail.com
Mon Nov 6 03:18:55 EST 2017
On 6 November 2017 at 17:09, Guido van Rossum <guido at python.org> wrote:> I still find this unfriendly to users of Python scripts and small apps who> are not the developers of those scripts.At a distro level, these warnings being off by default has actuallyturned out to be a problem, as it's precisely those users of Pythonscripts and small apps running in the system Python that don't findout they're at risk of a future distro upgrade breaking their toolsuntil they hit the release where they actually break. They then go tothe developers of either the distro or those tools saying "Everythingis broken, now what do I do?", rather than less urgently asking "Hey,what's up with this weird warning I'm getting now?".So compared to that current experience of "My distro upgrade broke mystuff", getting back to the occasional "After my distro upgrade, abunch of my stuff is now emitting messages I don't understand onstderr" sounds likes a positive improvement to me :)> Isn't there a better heuristic we can come up with so that the warnings tend> to be on for developers but off for end users?That depends on where you're drawing the line between "developer" and"end user". Someone working on a new version of Django, for example,would probably qualify as an end user from our perspective, whilethey'd be a framework developer from the point of view of someonebuilding a website.If we're talking about "Doesn't even know what Python is" end users,then the most reliable way for devs to ensure they never see adeprecation warning is to bundle Python with the application, insteadof expecting end users to handle the task of integrating the twotogether.If we're talking about library and frameworks developers, then theonly reliable way to distinguish between deprecation warnings that areencountered because a dependency has a future compatibility problemand those that are internal to the application is to use modulefiltering: warnings.filterwarnings("ignore", category=DeprecationWarning) warnings.filterwarnings("once", category=DeprecationWarning,module="myproject.*") warnings.filterwarnings("once", category=DeprecationWarning,module="__main__.*")This model allows folks to more selectively opt-in to getting warningsfrom their direct dependencies, while ignoring warnings from furtherdown their dependency stack.As things currently stand though, there's little inherent incentivefor new Python users to start learning how to do any of this -instead, the default behaviour for the last several years has been"Breaking API changes just happen sometimes without any priorwarning", and you have to go find out how to say "Please tell me whenbreaking changes are coming" (and remember to opt in to that everytime you start Python) before you get any prior notification.I do like Barry's suggestion of introducing a gentler API specificallyfor filtering deprecations warnings, though, as I find the warningsfiltering system to be a bit like logging, in that it's sufficientlypowerful and flexible that getting started with it can be genuinelyconfusing and intimidating.In relation to that, the "warn" module README athttps://pypi.python.org/pypi/warn/ provides some additional examplesof how it can currently be difficult to craft a good definition ofwhich deprecation warnings someone actually wants to see.Cheers,Nick.P.S. That README also points out another problem with the status quo:DeprecationWarning still gets silenced by default when encountered inthird party modules as well, meaning that also shows up as an abruptcompatibility break for anyone that didn't already know they needed toopt-in to get deprecation warnings.-- Nick Coghlan |ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Devmailing list
[8]ページ先頭