[Python-ideas] Deprecation APIs and language tooling

[Stephen J. Turnbull]

Sergei Lebedev writes:

 > The proliferation of deprecation APIs itself is not a problem, but it does
 > make it difficult (if not impossible) for language tooling to consume that
 > deprecation information and help users of these libraries write better
 > code.

We don't know that it's not a problem, though.

To get this discussion properly kicked off, the first thing that
should be checked is what is common and what is not in the many
existing APIs, and make proposals about the odd features (whether to
include them in the standard API or not), as well as reconciling
similar features that are implemented differently.  At the other end,
the 'deprecations' module, on PyPI I guess (searching for "deprecation
doc" found at the readthedocs manual, not the package itself), seems
to be a minimal API likely to be a common core.  (However the
restriction that the deprecation date has to be set to set the target
removal date seems odd to me.)

 > Imagine, if there was a standard way to flag something as
 > deprecated.

But there *is* a stdlib way to flag something as deprecated
(DeprecationWarning), but issuing those warnings is a user option, off
by default.  The reasons why that standard API is not used, but every
library auther prefers a module-specific API, need to be addressed.
And somebody cared enough about 'deprecations' to bring it to version
2.06, which suggests they're using it quite a bit.

 > What do you think? Is anyone interested in discussing this further
 > and perhaps sketching an API which could work reasonably well for
 > library authors as well as for tooling?

I'll lurk in the discussion, but this is not something I've felt a
need for in the past.  It's not the place where you'd expect to see
this discussion, but in the mypy issue you mention, Guido's specific
invitation to do exactly this apparently met with complete silence,
which is not a good sign (but not necessarily a bad one, either).

One general comment: I expect that something that works for consumers
of deprecation information wouldt work for library authors, too.  The
problem is the API for filtering out unwanted information (eg,
deprecations in imported libraries you're unable or unwilling to
vendor, removals far enough in the future you're happy to postpone the
work), without too much work on the consumer's side (most consumers
will not be willing to do more than "on" vs "off", and currently they
prefer "off" for DeprecationWarning itself).

Steve

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HGTR32Q2YHFOTX4UTQDAEG3DZBSMHNDC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Deprecation APIs and language tooling

[Sergei Lebedev]

Hi python-ideas,

The subject is by no means new nor unique, and in fact has been discussed
on python-ideas at least once

before as well as in python/mypy#2403
..

However, to date, there seems to be no standard way of deprecating things
declaratively, and ~every major library has its own internal API for that.
For example,

* numpy.deprecate,
* similar decorators in pandas

and TensorFlow
,

* twisted.python.deprecate
,

* warn_about_renamed_method

in Django,
* etc etc.

The proliferation of deprecation APIs itself is not a problem, but it does
make it difficult (if not impossible) for language tooling to consume that
deprecation information and help users of these libraries write better
code.

Imagine, if there was a standard way to flag something as deprecated. That
would allow, for example, an IDE or a linter to statically flag a
particular usage site as problematic and, assuming such information is
available, to suggest an auto-generated fix (see @Deprecated in Kotlin
, for
example).

What do you think? Is anyone interested in discussing this further and
perhaps sketching an API which could work reasonably well for library
authors as well as for tooling?

Cheers,
Sergei
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EABCXCALZFRDH7CKMUL4YHFBQFOBUWN7/
Code of Conduct: http://python.org/psf/codeofconduct/