Patches item #1683908, was opened at 2007-03-19 13:32
Message generated for change (Comment added) made by rhamphoryncus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam Olsen (rhamphoryncus)
Assigned to: Thomas Wouters (twouters)
Summary: PEP 361 Warnings
Initial Comment:
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.
----------------------------------------------------------------------
>Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-03-25 21:23
Message:
Logged In: YES
user_id=12364
Originator: YES
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
----------------------------------------------------------------------
Comment By: Anthony Baxter (anthonybaxter)
Date: 2007-03-20 22:02
Message:
Logged In: YES
user_id=29957
Originator: NO
Here's a -W py3k patch I did. Think it went to the list, not the trackers.
File Added: warn3.patch
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-20 21:53
Message:
Logged In: YES
user_id=33168
Originator: NO
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.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-20 21:48
Message:
Logged In: YES
user_id=33168
Originator: NO
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. :-(
----------------------------------------------------------------------
Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-03-20 16:32
Message:
Logged In: YES
user_id=12364
Originator: YES
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.
----------------------------------------------------------------------
Comment By: Thomas Wouters (twouters)
Date: 2007-03-20 15:57
Message:
Logged In: YES
user_id=34209
Originator: NO
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470
_______________________________________________
Patches mailing list
Patches@python.org
http://mail.python.org/mailman/listinfo/patches
