[issue2772] Add PendingDeprecationWarning for % formatting

Raymond Hettinger added the comment: Am closing this one. It is pointless and counter-productive unless there is a firm decision that % formatting is definitely going away (and migration tools have been developed). Right now, it looks like there is some chance that it might pull through for a

[issue2772] Add PendingDeprecationWarning for % formatting

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue2772] Add PendingDeprecationWarning for % formatting

Guido van Rossum added the comment: Not it. -- assignee: gvanrossum -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith <[EMAIL PROTECTED]> added the comment: I agree. That's one of the reasons I un-assigned it to me. Well, that and I couldn't get it to pass all tests. ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2772] Add PendingDeprecationWarning for % formatting

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: I think this is premature until be know for sure that % formatting will in-fact be deprecated in Py3.1. Time will tell how well the new format options get accepted. Likewise, we'll learn more about how readily legacy code can get conve

[issue2772] Add PendingDeprecationWarning for % formatting

Changes by Eric Smith <[EMAIL PROTECTED]>: -- assignee: eric.smith -> ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list m

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith <[EMAIL PROTECTED]> added the comment: The attached patch (percent_formatting_pending_deprecation_0.diff) adds both the simple global lock to unicode_mod() and changes warnings.py to use .format() instead of % formatting. I think this is good enough. We should add a warning to the do

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith <[EMAIL PROTECTED]> added the comment: > That would make user code warning that uses '%"' brittle. However, if > we warn about it, I think it's ok. True enough. Then I think we should go with: 1. Use .format() in the warnings module. 2. Tell the users not to use % formatting in user

[issue2772] Add PendingDeprecationWarning for % formatting

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: On Wed, May 7, 2008 at 10:33 AM, Eric Smith <[EMAIL PROTECTED]> wrote: > I think a better approach will be to remove % formatting from > warnings.py. I think that will remove the need for any checks at all. > I'll investigate that. Tha

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith <[EMAIL PROTECTED]> added the comment: I'm not sure Py_EnterRecursiveCall is what I want, because that allows the recursion to happen, but just aborts it when it gets too deep. What I want to achieve is to have the warning not called if it's the warning that's being formatted. I code

[issue2772] Add PendingDeprecationWarning for % formatting

Neal Norwitz <[EMAIL PROTECTED]> added the comment: Why not use the normal recursion check mechanism? Specifically, if (Py_EnterRecursiveCall("unicode % ")) return NULL; // err = Warn(); Py_LeaveRecursiveCall(); I don't see where the problem with threads co

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith <[EMAIL PROTECTED]> added the comment: > Well, the first thing to check for is Py_Py3kWarning. Then do the > extra logic and execution speed. In 3.0, it's always a PendingDeprecationWarning, so that won't work. The test needs to be: if not recursing and warning_is_not_suppressed:

[issue2772] Add PendingDeprecationWarning for % formatting

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: On Tue, May 6, 2008 at 4:50 PM, Eric Smith <[EMAIL PROTECTED]> wrote: > > Eric Smith <[EMAIL PROTECTED]> added the comment: > > Since we're just trying to prevent this function from recursing > (indirectly) into itself, I think all of th

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith <[EMAIL PROTECTED]> added the comment: Since we're just trying to prevent this function from recursing (indirectly) into itself, I think all of the logic can go here. What would you suggest the function _PyErr_InErrorProcessing do differently? I think the real issue is: Does the add

[issue2772] Add PendingDeprecationWarning for % formatting

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Would it be practical to add a _PyErr_InErrorProcessing function to prevent recursion? -- nosy: +benjamin.peterson __ Tracker <[EMAIL PROTECTED]> _

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith <[EMAIL PROTECTED]> added the comment: Right. But is it worth adding per-thread machinery to this? I was going to do that, but it seemed like overkill. Upon further reflection, however, I think you may be right. I'll remove the "easy" keyword! -- keywords: -easy

[issue2772] Add PendingDeprecationWarning for % formatting

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > Do I need to acquire the GIL here? No, the GIL has already been acquired. The problem with the static variable is that while the main thread is PyErr_WarnEx(), another thread may gain focus. And it will not trigger the warning. -

[issue2772] Add PendingDeprecationWarning for % formatting

New submission from Eric Smith <[EMAIL PROTECTED]>: Per http://mail.python.org/pipermail/python-3000/2008-April/013094.html, add a PendingDeprecationWarning to 3.0 for % formatting. The attached patch implements this for 3.0. For 2.6, it should only be a PendingDeprecationWarning if -3 warnings