(original) (raw)

On Fri, Apr 5, 2019 at 1:11 PM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:

On 2019-04-05 21:58, Brett Cannon wrote:
\> Then we can consider improving the documentation if there are
\> performance implications.

Sure, we could write in the docs something like "Don't use this, this is
not what you want. It's slow and there are better alternatives like
method descriptors". Should I do that (with better wording of course)?

Up to you. Obviously help is always appreciated, just a question of who feels qualified to review the PR.

\> since we don't have nearly as good of a deprecation setup as we
\> do in Python code.

I don't get this. One can easily raise a DeprecationWarning from C code,
there is plenty of code already doing that.

True. I personally prefer compile-time warnings for that sort of thing, but you're right we can do it at the Python "level" with a raise of a DeprecationWarning on those instances.