[Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

[Nick Coghlan]

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