On 13 Dec. 2017 12:53 pm, "Victor Stinner" wrote:
2017-12-13 0:24 GMT+01:00 Guido van Rossum :
> Considered disagreement is acceptable.
Sure, I'm fine with that ;-)
> Nick, congrats with PEP 565! Please update the PEP to mark it as approved
> with a link to this message as the resolution, and l
2017-12-13 0:24 GMT+01:00 Guido van Rossum :
> Considered disagreement is acceptable.
Sure, I'm fine with that ;-)
> Nick, congrats with PEP 565! Please update the PEP to mark it as approved
> with a link to this message as the resolution, and let's get the
> implementation into 3.7a4!
Nick wrot
OK, in that case I'll just pronounce approval right here. Considered
disagreement is acceptable.
Nick, congrats with PEP 565! Please update the PEP to mark it as approved
with a link to this message as the resolution, and let's get the
implementation into 3.7a4!
On Tue, Dec 12, 2017 at 2:58 PM, V
Hi,
2017-12-12 21:21 GMT+01:00 Guido van Rossum :
> I'm still hoping to accept this PEP, but I don't have time to wrap my head
> around -Xdev ("devmode"?) which appears to be Victor's latest pet project.
> Should PEP 565 be changed to copy with devmode's behavior, or the other way
> around, or sho
Nick and Victor,
I'm still hoping to accept this PEP, but I don't have time to wrap my head
around -Xdev ("devmode"?) which appears to be Victor's latest pet project.
Should PEP 565 be changed to copy with devmode's behavior, or the other way
around, or should they just ignore each other? It is no
Let's discuss -Xdev implementation issue at
https://bugs.python.org/issue32230
In short, -Xdev must add its warning at the end to respect BytesWarning,
whereas it's not possible with -W option :-(
Victor
Le 6 déc. 2017 09:15, "Nick Coghlan" a écrit :
On 6 December 2017 at 14:50, Nick Coghlan
On 6 December 2017 at 14:50, Nick Coghlan wrote:
> On 6 December 2017 at 14:34, Nick Coghlan wrote:
>> That said, I go agree we could offer easier to use APIs to app
>> developers that just want to hide warnings from their users, so I've
>> filed https://bugs.python.org/issue32229 to propose a st
On 6 December 2017 at 14:34, Nick Coghlan wrote:
> That said, I go agree we could offer easier to use APIs to app
> developers that just want to hide warnings from their users, so I've
> filed https://bugs.python.org/issue32229 to propose a straightforward
> "warnings.hide_warnings()" API that enc
On 6 December 2017 at 06:43, Victor Stinner wrote:
> At the end, I'm not sure that the PEP 565 is really needed or would help
> anyone.
Folks, I'd really appreciate it if you could comment on the merits of
the PEP without implicitly claiming that I don't exist, and that Linux
system administrato
On 6 December 2017 at 05:11, Barry Warsaw wrote:
> On Dec 5, 2017, at 13:24, Guido van Rossum wrote:
>
>> But the whole point of the PEP is that it only warns about deprecations in
>> code over which the user has control -- likely __main__ is their own code,
>> and they *can* handle it.
>
> I’m
2017-12-05 21:21 GMT+01:00 Serhiy Storchaka :
> 05.12.17 22:10, Victor Stinner пише:
>>
>> Maybe we need something to declare the code that we own, to
>> enable warnings on them.
>
> Just compare __author__ with the name of the user running a script. ;-)
I was thinking as something like:
enabl
05.12.17 22:10, Victor Stinner пише:
Maybe we need something to declare the code that we own, to
enable warnings on them.
Just compare __author__ with the name of the user running a script. ;-)
___
Python-Dev mailing list
Python-Dev@python.org
https:/
On Tue, Dec 5, 2017 at 12:10 PM, Victor Stinner
wrote:
> 2017-12-05 19:24 GMT+01:00 Guido van Rossum :
> >> I disagree that *users* of an application is supposed to "handle"
> >> deprecation warnings: report them to the developer, or even try to fix
> >> them. IHMO these warnings (hidden by defau
2017-12-05 19:24 GMT+01:00 Guido van Rossum :
>> I disagree that *users* of an application is supposed to "handle"
>> deprecation warnings: report them to the developer, or even try to fix
>> them. IHMO these warnings (hidden by default) were introduced for
>> developers of the application.
>
> But
On Tue, Dec 5, 2017 at 11:11 AM, Barry Warsaw wrote:
> On Dec 5, 2017, at 13:24, Guido van Rossum wrote:
>
> > But the whole point of the PEP is that it only warns about deprecations
> in code over which the user has control -- likely __main__ is their own
> code, and they *can* handle it.
>
> I
On Dec 5, 2017, at 13:24, Guido van Rossum wrote:
> But the whole point of the PEP is that it only warns about deprecations in
> code over which the user has control -- likely __main__ is their own code,
> and they *can* handle it.
I’m not so sure how true that is. I have no sense of the rela
On Tue, Dec 5, 2017 at 9:59 AM, Victor Stinner
wrote:
> 2017-12-05 16:50 GMT+01:00 Guido van Rossum :
> > Honestly, I didn't completely follow what Victor thinks of the PEP -- his
> > post seemed mostly about promoting his own -X dev flag.
>
> -X dev is similar (but different) than -W default: sh
2017-12-05 16:50 GMT+01:00 Guido van Rossum :
> Honestly, I didn't completely follow what Victor thinks of the PEP -- his
> post seemed mostly about promoting his own -X dev flag.
-X dev is similar (but different) than -W default: show warnings which
are hidden by default otherwise. -W default wor
If you ask me this PEP is not going to make everyone happy, but I think it
is an improvement, and it seems many people are in agreement or at least
don't object to it (and obviously Nick thinks it's going to be a big
improvement).
Therefore I am planning to accept it by the end of this week unless
2017-11-12 10:24 GMT+01:00 Nick Coghlan :
> I've written a short(ish) PEP for the proposal to change the default
> warnings filters to show DeprecationWarning in __main__:
> https://www.python.org/dev/peps/pep-0565/
I understand the rationale of the PEP, but I dislike the proposed
implementation.
On Nov 28, 2017 3:55 PM, "Guido van Rossum" wrote:
On Sun, Nov 19, 2017 at 5:40 AM, Nathaniel Smith wrote:
> Eh, numpy does use FutureWarning for changes where the same code will
> transition from doing one thing to doing something else without
> passing through a state where it raises an error
> On Nov 19, 2017, at 8:40 AM, Nathaniel Smith wrote:
>
> We have been using DeprecationWarning for changes where code will
> transition from working -> raising an error, and that *is* based on
> the Official Recommendation to hide those by default whenever
> possible. We've been doing this for
On Sun, Nov 19, 2017 at 5:40 AM, Nathaniel Smith wrote:
> Eh, numpy does use FutureWarning for changes where the same code will
> transition from doing one thing to doing something else without
> passing through a state where it raises an error. But that decision
> was based on FutureWarning bein
This is awesome. If there isn't more feedback in the next few days expect
an approval early next week. (Ping me if you don't hear from me, I'm
juggling way too many small tasks so I'm likely to forget some.)
On Tue, Nov 28, 2017 at 3:00 AM, Nick Coghlan wrote:
> On 28 November 2017 at 09:52, Gui
On 28 November 2017 at 09:52, Guido van Rossum wrote:
> I am basically in agreement with this now. Some remarks:
I've pushed an update which should address most of these, as well as
Serhiy's comment about the existing FutureWarning use case:
https://github.com/python/peps/commit/aaa64f53d04347243
25.11.17 07:33, Nick Coghlan пише:
* ``FutureWarning``: always reported by default. The intended audience is users
of applications written in Python, rather than other Python developers
(e.g. warning about use of a deprecated setting in a configuration file
format).
Given its presence i
I am basically in agreement with this now. Some remarks:
- I would recommend adding a note to the abstract about the recommendation
for test runners to also enable these warnings by default.
- In some sense, simple scripts that are distributed informally (e.g. as
email attachments or via shared d
This is a new version of the proposal to show DeprecationWarning in __main__.
The proposal itself hasn't changed (it's still recommending a new
entry in the default filter list), but there have been several updates
to the PEP text based on further development work and comments in the
initial threa
On Sun, Nov 19, 2017 at 2:26 AM, Serhiy Storchaka wrote:
> It seems to me that most of issues with FutureWarning on GitHub [1] are
> related to NumPy and pandas which use FutureWarning for its original nominal
> purpose, for warning about using programming interfaces that will change the
> behavio
13.11.17 01:34, Nick Coghlan пише:
On 13 November 2017 at 03:10, Serhiy Storchaka wrote:
12.11.17 11:24, Nick Coghlan пише:
The PEP also proposes repurposing the existing FutureWarning category
to explicitly mean "backwards compatibility warnings that should be
shown to users of Python applic
On 19 November 2017 at 17:22, Nick Coghlan wrote:
> I've updated the PEP to try to make the explanation of the historical
> rationale more accurate:
> https://github.com/python/peps/commit/30daada7867dd7f0e008545c7fd98612282ec602
With these changes, I think the version now live at
https://www.pyt
On 13 November 2017 at 01:45, Guido van Rossum wrote:
> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
>>
>> In Python 2.7 and Python 3.2, the default warning filters were updated to
>> hide
>> DeprecationWarning by default, such that deprecation warnings in
>> development
>> tools that wer
On Mon, Nov 13, 2017 at 11:33 AM, Victor Stinner
wrote:
> If the Python REPL is included in the "run an application" use case,
> the frontier between user and developer becomes blurry :-) Is REPL
> designed for users or developers? Should Python guess the intent of
> the human connected to the ke
On Mon, Nov 13, 2017 at 6:09 AM, Serhiy Storchaka wrote:
> 13.11.17 14:29, Antoine Pitrou пише:
>>
>> On Mon, 13 Nov 2017 22:37:46 +1100
>> Chris Angelico wrote:
>>>
>>> On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou
>>> wrote:
On Sun, 12 Nov 2017 19:48:28 -0800
Nathaniel Smith
On 14 November 2017 at 02:27, Victor Stinner wrote:
>> The change proposed in this PEP is to update the default warning filter list
>> to be::
>>
>> default::DeprecationWarning:__main__
>> ignore::DeprecationWarning
>> ignore::PendingDeprecationWarning
>> ignore::ImportWarning
>>
Hi,
I'm not convinced that this PEP 565 will prevent developers to be
surprised when upgrading Python, since more and more applications are
using an entry point: an import + a single function call. For example,
*all* OpenStack applications use an entry point and so will be
unaffected by this PEP.
> The change proposed in this PEP is to update the default warning filter list
> to be::
>
> default::DeprecationWarning:__main__
> ignore::DeprecationWarning
> ignore::PendingDeprecationWarning
> ignore::ImportWarning
> ignore::BytesWarning
> ignore::ResourceWarning
This P
13.11.17 14:29, Antoine Pitrou пише:
On Mon, 13 Nov 2017 22:37:46 +1100
Chris Angelico wrote:
On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou wrote:
On Sun, 12 Nov 2017 19:48:28 -0800
Nathaniel Smith wrote:
On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
This change will lead to Depr
On Mon, Nov 13, 2017 at 10:37:46PM +1100, Chris Angelico wrote:
> >> https://bugs.python.org/issue1539925
> >> https://github.com/ipython/ipython/issues/6611
> >
> > Depends what you call "better". Personally, I don't want to see
> > warnings each and every time I use a deprecated or questionable
On Mon, 13 Nov 2017 22:37:46 +1100
Chris Angelico wrote:
> On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou wrote:
> > On Sun, 12 Nov 2017 19:48:28 -0800
> > Nathaniel Smith wrote:
> >> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
> >> > This change will lead to DeprecationWarning be
On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou wrote:
> On Sun, 12 Nov 2017 19:48:28 -0800
> Nathaniel Smith wrote:
>> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
>> > This change will lead to DeprecationWarning being displayed by default for:
>> >
>> > * code executed directly at the
On Sun, 12 Nov 2017 19:48:28 -0800
Nathaniel Smith wrote:
> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
> > This change will lead to DeprecationWarning being displayed by default for:
> >
> > * code executed directly at the interactive prompt
> > * code executed directly as part of a sin
13.11.17 05:48, Nathaniel Smith пише:
On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
This change will lead to DeprecationWarning being displayed by default for:
* code executed directly at the interactive prompt
* code executed directly as part of a single-file script
Technically it's
On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
> This change will lead to DeprecationWarning being displayed by default for:
>
> * code executed directly at the interactive prompt
> * code executed directly as part of a single-file script
Technically it's orthogonal, but if you're trying to
On 13 November 2017 at 03:10, Serhiy Storchaka wrote:
> 12.11.17 11:24, Nick Coghlan пише:
>>
>> The PEP also proposes repurposing the existing FutureWarning category
>> to explicitly mean "backwards compatibility warnings that should be
>> shown to users of Python applications" since:
>>
>> - we
12.11.17 11:24, Nick Coghlan пише:
The PEP also proposes repurposing the existing FutureWarning category
to explicitly mean "backwards compatibility warnings that should be
shown to users of Python applications" since:
- we don't tend to use FutureWarning for its original nominal purpose
(change
On Sun, 12 Nov 2017 19:24:12 +1000
Nick Coghlan wrote:
> I've written a short(ish) PEP for the proposal to change the default
> warnings filters to show DeprecationWarning in __main__:
> https://www.python.org/dev/peps/pep-0565/
Thank you for writing this. This is a nice summary. You finally
co
On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
> In Python 2.7 and Python 3.2, the default warning filters were updated to
> hide
> DeprecationWarning by default, such that deprecation warnings in
> development
> tools that were themselves written in Python (e.g. linters, static
> analysers
I've written a short(ish) PEP for the proposal to change the default
warnings filters to show DeprecationWarning in __main__:
https://www.python.org/dev/peps/pep-0565/
The core proposal itself is just the idea in
https://bugs.python.org/issue31975 (i.e. adding
"default::DeprecationWarning:__main__
49 matches
Mail list logo
