Opened 8 years ago
Last modified 5 years ago
#12570 new enhancement
Create a deprecated function decorator
| Reported by: | Ryan J Ollos | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | next-major-releases |
| Component: | general | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
Since we've been deprecating and removing a lot of code, I thought it might be useful to add a deprecated decorator to trac.util. The decorator could log a message at the appropriate level, which might be WARNING. The message would indicate that a deprecated function, class or method has been called by a plugin.
Attachments (0)
Change History (8)
comment:2 by , 7 years ago
Bonus points for playing nice with Sphinx so that the :deprecated: annotation gets generated automatically ;-)
comment:3 by , 7 years ago
I dislike deprecated warnings being shown to stderr. It may be useful to a developer but it's just noisy to a user. However, I think it would be good to write the warnings to trac.log.
comment:5 by , 7 years ago
Speaking of logging at warning level, the logs get filled with Genshi deprecated messages: trunk/trac/web/chrome.py@15668:1692-1693#L1689. Two alternatives might be: only log once in lifecycle of the environment, or log at info level.
comment:6 by , 7 years ago
Well, yes, we should log at warning level and once per each unique template.
Something with warnings and logging.captureWarnings(True).
comment:8 by , 5 years ago
| Milestone: | next-dev-1.5.x → next-major-releases |
|---|
Here's an example. I don't think we want to add a dependency, but could be useful for an example implementation.