[Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff (original) (raw)
Guido van Rossum guido at python.org
Tue Nov 7 19:03:49 EST 2017
- Previous message (by thread): [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff
- Next message (by thread): [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
OK, so let's come up with a set of heuristics that does the right thing for those cases specifically. I'd say whenever you're executing code from a zipfile or some such it's not considered your own code (by default).
On Tue, Nov 7, 2017 at 2:16 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
On 8 November 2017 at 06:32, Guido van Rossum <guido at python.org> wrote: > On Mon, Nov 6, 2017 at 7:23 PM, Terry Reedy <tjreedy at udel.edu> wrote: >> >> On 11/6/2017 9:47 PM, Nick Coghlan wrote: >> [...] >>> >>> - "only show me legacy calls in my code" (the "I trust my deps to >>> take care of themselves" use case) >> >> >> Perhaps this should be the new default, where 'my code' means everything >> under the directory containing the startup file. If an app developer either >> fixes or suppresses warnings from app code when they first appear, then >> users will seldom or never see warnings. So for users, this would then be >> close to the current default. > > Yes, this or a close a variant sounds like a decent option.
Unfortunately, there are a lot of common directory layouts where a simple filesystem based assumption like that one will lead to warnings from third party code: 1. zipapp archives, where everything, including main.py, shares a common path prefix (the zip archive) 2. Working directories that include a ".venv" link to the default virtual environment for a project (this is a not uncommon way of telling IDEs which venv to use) 3. Package execution, when the package includes a "vendor" or "bundle" subtree The one thing we can be reasonably confident counts as "the developer's code" is "main", but even that isn't completely certain in cases where folks are publishing single file scripts for use by others (e.g. a DeprecationWarning from get-pip.py would be useful to pip developers, but almost entirely unhelpful to users of the script itself). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171107/69457a0c/attachment.html>
- Previous message (by thread): [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff
- Next message (by thread): [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]