Re: [python-committers] Deprecation Policy PEP

2016-01-30 Thread Nick Coghlan 
On 30 January 2016 at 09:39, Barry Warsaw  wrote:
> On Jan 29, 2016, at 06:11 PM, Brett Cannon wrote:
>
>>+1 from me as well, especially once Serhiy's comments are addressed.

Likewise - an additional proofreading pass would be useful, but the
overall content looks fine to me.

> Me too, but only if you add a PendingDeprecationWarning to
> PendingDeprecationWarning .

There were some discussions a while back of restoring a distinction
between the two by having code executed directly at the REPL (whether
at the command line or in IDLE) show DeprecationWarning by default,
but still hide PendingDeprecationWarning globally.

That idea actually seemed to garner general approval, so I suspect the
main reason the discussion died out was the fact that it's a bit
fiddly to implement.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Deprecation Policy PEP

2016-01-30 Thread Nick Coghlan 
On 30 January 2016 at 13:28, Martin Panter  wrote:
> On 29 January 2016 at 21:59, Serhiy Storchaka  wrote:
>> On 29.01.16 21:56, Ezio Melotti wrote:
>>> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka 
>>> wrote:
 Some deprecation can be documentation-only.
>>>
>>> Do you have examples where this has been done?
>>
>> An attribute of a module. [. . .]
>> Removing some special behavior [. . .]
>
> Sometimes people want to avoid raising a DeprecationWarning even where
> it is technically possible. For example, the optparse module
> , which is still widely used in
> other modules. Brett’s load_module() situation also sounds similar.

Another case where this arises is when an API has been deprecated for
pure Python 3 code, but is still needed in single source Python 2/3
code.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Deprecation Policy PEP

2016-01-30 Thread Terry Reedy 

On 1/30/2016 3:39 AM, Nick Coghlan wrote:


Me too, but only if you add a PendingDeprecationWarning to
PendingDeprecationWarning .


There were some discussions a while back of restoring a distinction
between the two by having code executed directly at the REPL (whether
at the command line or in IDLE) show DeprecationWarning by default,
but still hide PendingDeprecationWarning globally.


What would you do for mixed start-batch, switch to interactive mode 
(-i)?  Turn DWs on at the beginning on the basis that -i is mainly for 
development?



That idea actually seemed to garner general approval, so I suspect the
main reason the discussion died out was the fact that it's a bit
fiddly to implement.


IDLE executes usercode with, I believe, exec(code_object, pseudo_main). 
 Does exec simply use the current warnings setting?


-TJR

___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers