This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: PEP 361 Warnings
Type: behavior Stage: patch review
Components: None, Interpreter Core, Library (Lib) Versions: Python 2.6
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: twouters Nosy List: Rhamphoryncus, ajaksu2, anthonybaxter, nnorwitz, twouters
Priority: normal Keywords: patch

Created on 2007-03-19 19:32 by Rhamphoryncus, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
warn3.patch anthonybaxter, 2007-03-21 04:02 warn3.patch
python2.6-warnings3.diff Rhamphoryncus, 2007-04-07 21:39 PEP361 warnings, v3
Messages (10)
msg52267 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2007-03-19 19:32
Attached is a patch that adds some of the warnings mentioned in PEP 361, specifically:
* `repr`
* cmp() and __cmp__
* apply()
* coerce() and __coerce__
* reduce()
* {}.has_key()

I'm unsure what conclusions were reaches wrt py3k-specific command line options or warning categories, so I've used DeprecationWarning as a placeholder.  Not surprisingly, this causes large amounts of noise in the test suite (but no failures).

Thus far I've focused on warnings that (in my opinion) should be fixed in 2.x code.  Many of the other warnings (such as using {}.iteritems()) are better handled using the 2to3 translator.  Again though, I'm unsure if they will ultimately be given a distinct warning category, so I await input on that.
msg52268 - (view) Author: Thomas Wouters (twouters) * (Python committer) Date: 2007-03-20 21:57
The ``-warning should be emitted by the parser, not when the UNARY_CONVERT opcode is executed. I'm still not entirely sure __cmp__/cmp() should be deprecated (cmp() is terribly convenient, and I haven't heard Guido say they really should be. Maybe just __cmp__ should go.) I wonder if we shouldn't do the warning for __coerce__ and __cmp__ at class creation time as well as at call time. (Class creation is earlier and oftner, but doesn't catch all cases. The warnings registry would make sure the warning is only emitted once, by default.) Some of the messages could maybe be more informative; perhaps we can link to a wiki page with py3k-deprecation info. On the other hand, people will only see most of these if they do the -Wpy3k thing. (The ``-warning should be a real deprecation warning in the parser, not related to -Wpy3k.)

Other than those minor points, looks good. I think it should wait for the C-warnings-module Neal N's working on, though, before we really check it in. Assigning to Neal for him to take a look at.
msg52269 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2007-03-20 22:32
I originally had the `` warning emitted during the parse stage, but this prevents it from showing when the .pyc file already exists.  Which is more important?  And is it an actual DeprecationWarning or a PendingDeprecationWarning?

I didn't notice a way to produce a warning at both definition time and use time, without emitting it twice.  I agree that both is better, so I'll figure it out.

Linking to a wiki page would be far better than trying to squeeze a full explanation into one sentence.
msg52270 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2007-03-21 03:48
Thomas, should there be a 3k warning category that's a subclass of DeprecationWarning?  Should this patch impl the -3k flag or whatever it's called?

Damn, I really gotta get that warnings patch done.  First I gotta get the buildbots in decent shape, get 2.5.1 out, then xrange patch, then warnings.  That list sucks.  It doesn't even include crap like get inbox less than 200 unread msgs or do taxes. :-(
msg52271 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2007-03-21 03:53
Oooh, Anthony pointed me to his patch:  http://python.org/sf/1631035 
So no need to impl anything that's in there.  I don't think there's much overlap so far, but I didn't look that closely.
msg52272 - (view) Author: Anthony Baxter (anthonybaxter) (Python triager) Date: 2007-03-21 04:02
Here's a -W py3k patch I did. Think it went to the list, not the trackers. 
File Added: warn3.patch
msg52273 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2007-03-26 03:23
Version 2 of my patch:
* Drops the warning for ``.  Anthony Baxter's patch (#1631035) handles this better.
* __cmp__ and __coerce__ are checked for at class creation time as well as when called.  Currently will emit two warnings.
* A private function (_warnpy3k()) in warnings.py was added to take care of extracting warning location from the passed in function, but I've been unable to get that working properly.  At the moment it only serves as a single location (or two locations, if you include the C wrapper) to modify the warning message.
* The warning message was modified to be more informative, including a URL.  The URL currently points nowhere.
* A global flag (_Py_Py3kWarningFlag) was added to skip the warning code when not enabled.  I have located it with the other C interfaces to the warnings module on the assumption that it will be integrated as part of Neal's rewrite of warnings.py in C.  It defaults to on and I have not included a command line option to control it.
* Some warnings are omitted before warnings.py gets loaded, causing them to always be printed.  Presumably this will be fixed when warnings.py is rewritten in C.
* test_subprocess fails.  This is due warnings in the output and will be fixed when the warnings default to silent.
* test_descr fails.  This is due to a test (line 1298, SF bug 572567) that defines a class with __cmp__ and counts objects using gc.get_objects().  Although easily fixed by switching to __eq__, I've noticed that the p3yk branch uses __cmp__ as well.  It may be failing silently?
* One of the tests fail if I merge together the two loops it contains, but it shouldn't.  I'm guessing this is due to not registering the warnings in the right location, which is what _warnpy3k() should fix.
* Running regrtest on test_py3kwarnings.py fails.  I'm guessing this is due to the above.
* Running regrtest on everything shows many leaks (and a few more failures).  I'm hoping this is due to the above as well.
File Added: python2.6-warnings2.diff
msg52274 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2007-04-07 21:39
Fixes/changes
* Includes Patch #1692664, for my own sanity.  Hopefully won't cause a problem when applying.
* Warnings for __coerce__/__cmp__ during class creation now show as from the functions themselves.  Uses the class as a fallback if the methods are not real functions.
* Leaks shown by regrtest have been fixed.
* test_descr no longer fails, although the problem in p3yk presumably still exists.
* __warningregistry__ is handled better, so (combined with Patch #1692664 and other changes) all the oddities are gone.
* Some tests have occasionally failed with regrtest (such as test_tcl), but I don't think they're related to this patch.

Outstanding issues
* URL needs to point to an actual page
* DeprecationWarning needs to be replaced with something more appropriate
* "warning:" lines early during interpreter startup need to be silenced
* warnings module needs to control _Py_Py3kWarningFlag
File Added: python2.6-warnings3.diff
msg84709 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-03-30 23:13
I think this one is out of date.
msg84714 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2009-03-30 23:21
Aye.  2.6 has come and gone, with most or all warnings applied using (I
believe) a different patch.  If any future work is needed it can get a
new ticket.
History
Date User Action Args
2022-04-11 14:56:23adminsetgithub: 44745
2009-03-30 23:26:03ajaksu2setresolution: out of date
2009-03-30 23:21:16Rhamphoryncussetstatus: open -> closed

messages: + msg84714
2009-03-30 23:13:55ajaksu2setnosy: + ajaksu2
messages: + msg84709

components: + Interpreter Core, Library (Lib)
type: behavior
stage: patch review
2007-03-19 19:32:15Rhamphoryncuscreate