<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 5, 2019 at 1:11 PM Jeroen Demeyer <<a href="mailto:J.Demeyer@ugent.be">J.Demeyer@ugent.be</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2019-04-05 21:58, Brett Cannon wrote:<br>
> Then we can consider improving the documentation if there are<br>
> performance implications.<br>
<br>
Sure, we could write in the docs something like "Don't use this, this is <br>
not what you want. It's slow and there are better alternatives like <br>
method descriptors". Should I do that (with better wording of course)?<br></blockquote><div><br></div><div>Up to you. Obviously help is always  appreciated, just a question of who feels qualified to review the PR.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> since we don't have nearly as good of a deprecation setup as we<br>
> do in Python code.<br>
<br>
I don't get this. One can easily raise a DeprecationWarning from C code, <br>
there is plenty of code already doing that.<br></blockquote><div><br></div><div>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. <br></div></div></div>