[Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Tue Nov 7 17:16:53 EST 2017

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

More information about the Python-Dev mailing list