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

Guido van Rossum guido at python.org
Tue Nov 7 19:03:49 EST 2017


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>


More information about the Python-Dev mailing list