On Fri, Apr 5, 2019 at 1:11 PM Jeroen Demeyer <J.Demeyer at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20190405/bf387f19/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4