[Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff
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