11 Aug 2009, Benjamin Peterson wrote: > 2009/8/11 Jacob Rus: >> I have some other questions: How does one deprecate part of a standard >> library API? How can we alert users to the deprecation? When can the >> deprecated parts be removed? > > Basically, you add a DeprecationWarning to the API. Then remove it in > the next major version. Okay, I made another patch, http://bugs.python.org/issue6626 That adds some deprecation warnings to many of the functions/methods in the module. (I think the 'strict' parameters should also be deprecated. But I'm considering actually making a new class, MimeTypesRegistry, or something, and then just making its API stay mostly compatible with MimeTypes, but extended to behave the way I think it should, and deprecating the MimeTypes class altogether, making it a subclass in the interim.) Is there any way to explicitly (i.e. in code rather than docs) deprecate string flags or dicts/lists from the module global namespace? I don't think users should be mucking with the module's singleton at all, and should be forced to make a new registry instance to customize the behavior, so they don't break each-other's code. > Then, you might garner some more reviews by putting your patch up on > Rietveld; it makes reviewing much painful. Okay, my last Rietveld link didn't get any eyeballs, but here's another try: http://codereview.appspot.com/107042 Cheers, Jacob Rus
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