-
-
Notifications
You must be signed in to change notification settings - Fork 31.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
logging.warn() is not documented #57444
Comments
No docs for logging.warn() alias. |
That's deliberate. The original code (before incorporation into Python) had warn(), which was kept for backward compatibility. The docs refer to warning() because that's what everyone is supposed to use. The method names map to the lower case of the appropriate logging level name. |
I've got a traceback, because forgot to implement this method in logging wrapper. It should be either deprecated and removed or documented. |
It is deprecated by not being documented. It certainly isn't going to have documentation added for it. Which code was calling the warn() method? Is it not possible to change this to call warning()? ----- Original Message -----
|
./trac/env.py: self.log.warn('base_url option not set in configuration, ' quite a lot + probably trac plugins. So it's better to go through deprecation cycle and show appropriate message (but frankly - I don't mind against convenience alias - we already have some in testing modules). |
I think it's better to avoid "deprecations by missing documentation" and document explicitly if something is deprecated. |
New changeset 37479f0f68bc by Vinay Sajip in branch 'default': |
Just to me it clear - why do you want warn() to be removed aside from code duplication? My argument to leave it and document is that it is convenient and makes lines shorter (and won't break existing code). From logging module I also see that there are also logging.WARN aliases that you'll need to deprecate also. |
Because there should be only one way to do things. BTW, you could have used a DeprecationWarning instead of a PendingDeprecationWarning, especially if it was already deprecated. |
Sorry, I don't agree. I was happy to leave it as is until you raised this issue, but now I think the right thing to do is deprecate and remove warn(). I'm not too fussed about the WARN level, and I can't easily issue a deprecation warning for it as it's a module attribute, so I'll leave it in as an internal implementation detail, for which the usual caveats apply. |
It wasn't officially deprecated, just "deprecation via obscurity";-) which is why I made it a PendingDeprecationWarning. |
PendingDeprecations are not so useful now that warnings are silenced by default. Since it wasn't documented, you could deprecate it in 3.3 and remove it in 3.4 IMHO. |
Hmmm, you're probably right. I'll change it to a DeprecationWarning. |
New changeset 4a90d1ed115d by Vinay Sajip in branch 'default': |
Replace `logging.warn` (deprecated in [Python 2.7, 2011](python/cpython@04d5bc0)) with `logging.warning` (added in [Python 2.3, 2003](python/cpython@6fa635d)). * https://docs.python.org/3/library/logging.html#logging.Logger.warning * python/cpython#57444
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: