[Patches] [ python-Patches-1683908 ] PEP 361 Warnings

SourceForge.net noreply at sourceforge.net
Wed Mar 21 04:53:52 CET 2007


Patches item #1683908, was opened at 2007-03-19 12:32
Message generated for change (Comment added) made by nnorwitz
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: Neal Norwitz (nnorwitz)
Date: 2007-03-20 20: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 20: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 15: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 14: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


More information about the Patches mailing list