12.11.17 03:47, Guido van Rossum пише:
- In Python 3 code, using `\u` escapes in a b'...' literal gives
"DeprecationWarning: invalid escape sequence '\u'"
In both cases these warnings are currently only generated if you run
mypy with these warnings enabled, e.g. `python3 -Wd -m mypy `.
But th
On Sat, Nov 11, 2017 at 3:29 PM, Nick Coghlan wrote:
> And given that one of the key benefits of static analysis is that it
> *doesn't* run the code, I'd be surprised if mypy could ever trigger a
> runtime warning in the code under tests :)
>
Actually there are a few cases where mypy *will* gene
On Fri, Nov 10, 2017 at 11:34 PM, Brett Cannon wrote:
> On Thu, Nov 9, 2017, 17:33 Nathaniel Smith, wrote:
>> - if an envvar CI=true is set, then by default make deprecation warnings
>> into errors. (This is an informal standard that lots of CI systems use.
>> Error instead of "once" because most
On 11 November 2017 at 17:34, Brett Cannon wrote:
> On Thu, Nov 9, 2017, 17:33 Nathaniel Smith, wrote:
>> Some more ideas to throw out there:
>>
>> - if an envvar CI=true is set, then by default make deprecation warnings
>> into errors. (This is an informal standard that lots of CI systems use.
>
On Sat, 11 Nov 2017 07:34:05 +
Brett Cannon wrote:
>
> One problem with that is I don't want e.g. mypy to start spewing out
> warnings while checking my code.
It's rather trivial for mypy (or any other code analysis tool) to turn
warnings off when importing the code under analysis. And sinc
On Thu, Nov 9, 2017, 17:33 Nathaniel Smith, wrote:
> On Nov 8, 2017 16:12, "Nick Coghlan" wrote:
>
> On 9 November 2017 at 07:46, Antoine Pitrou wrote:
> >
> > Le 08/11/2017 à 22:43, Nick Coghlan a écrit :
> >>
> >> However, between them, the following two guidelines should provide
> >> pretty
On 10 November 2017 at 14:34, Greg Ewing wrote:
> Tres Seaver wrote:
>>
>> IIUC, that would be as expected: you would see the warnings when running
>> your test suite exercising that imported code (which should run with all
>> warnings enabled), but not when running the app.
>
> But then what ben
Tres Seaver wrote:
IIUC, that would be as expected: you would see the warnings when running
your test suite exercising that imported code (which should run with all
warnings enabled), but not when running the app.
But then what benefit is there in turning on deprecation
warnings automatically
On 10 November 2017 at 11:53, Nick Coghlan wrote:
> On 10 November 2017 at 11:32, Nathaniel Smith wrote:
>> Is this intended to be a description of the current state of affairs?
>> Because I've never encountered a test runner that does this... Which runners
>> are you thinking of?
>
> Ah, you're
On 10 November 2017 at 11:32, Nathaniel Smith wrote:
> Is this intended to be a description of the current state of affairs?
> Because I've never encountered a test runner that does this... Which runners
> are you thinking of?
Ah, you're right, pytest currently still requires individual
developer
On Nov 8, 2017 16:12, "Nick Coghlan" wrote:
On 9 November 2017 at 07:46, Antoine Pitrou wrote:
>
> Le 08/11/2017 à 22:43, Nick Coghlan a écrit :
>>
>> However, between them, the following two guidelines should provide
>> pretty good deprecation warning coverage for the world's Python code:
>>
>>
On 10 November 2017 at 01:45, Barry Warsaw wrote:
> On Nov 9, 2017, at 07:27, Tres Seaver wrote:
>
>> IIUC, that would be as expected: you would see the warnings when running
>> your test suite exercising that imported code (which should run with all
>> warnings enabled), but not when running th
On Nov 9, 2017, at 07:27, Tres Seaver wrote:
> IIUC, that would be as expected: you would see the warnings when running
> your test suite exercising that imported code (which should run with all
> warnings enabled), but not when running the app.
>
> Seems like a reasonable choice to me.
I’m co
On 11/09/2017 01:49 AM, Greg Ewing wrote:
>> On 8 November 2017 at 19:21, Antoine Pitrou wrote:
>>> The idea that __main__ scripts should
>>> get special treatment here is entirely gratuitous.
>
> When I'm writing an app in Python, very often my __main__ is
> just a stub that imports the actual f
On 8 November 2017 at 19:21, Antoine Pitrou wrote:
The idea that __main__ scripts should
get special treatment here is entirely gratuitous.
When I'm writing an app in Python, very often my __main__ is
just a stub that imports the actual functionality from another
module to get the benefits of
On 9 November 2017 at 02:17, Barry Warsaw wrote:
> I suppose there are lots of ways to do this, but at least I’m pretty sure we
> all agree that end users shouldn’t see DeprecationWarnings, while developers
> should.
Agreed. Most of the debate to me seems to be around who is an end user
and who
On Nov 8, 2017, at 16:10, Nick Coghlan wrote:
> The rationale for that change was so that end users of applications
> that merely happened to be written in Python wouldn't see deprecation
> warnings when Linux distros (or the end user) updated to a new Python
> version.
Instead they’d see breaka
On 9 November 2017 at 07:46, Antoine Pitrou wrote:
>
> Le 08/11/2017 à 22:43, Nick Coghlan a écrit :
>>
>> However, between them, the following two guidelines should provide
>> pretty good deprecation warning coverage for the world's Python code:
>>
>> 1. If it's in __main__, it will emit deprecat
Le 08/11/2017 à 22:43, Nick Coghlan a écrit :
>
> However, between them, the following two guidelines should provide
> pretty good deprecation warning coverage for the world's Python code:
>
> 1. If it's in __main__, it will emit deprecation warnings at runtime
> 2. If it's not in __main__, it s
On 9 November 2017 at 07:09, Simon Cross wrote:
> On Wed, Nov 8, 2017 at 10:33 PM, Nick Coghlan wrote:
>> For interactive use, the principle ends up being "Code you write gives
>> deprecation warnings, code you import doesn't" (which is the main
>> aspect I care about, since it's the one that sem
On Wed, Nov 8, 2017 at 10:33 PM, Nick Coghlan wrote:
> For interactive use, the principle ends up being "Code you write gives
> deprecation warnings, code you import doesn't" (which is the main
> aspect I care about, since it's the one that semi-regularly trips me
> up when I forget that Deprecati
On 8 November 2017 at 19:21, Antoine Pitrou wrote:
> On Wed, 8 Nov 2017 11:35:13 +1000
> Nick Coghlan wrote:
>
>> On 8 November 2017 at 10:03, Guido van Rossum wrote:
>> > OK, so let's come up with a set of heuristics that does the right thing for
>> > those cases specifically. I'd say whenever
On Wed, 8 Nov 2017 11:35:13 +1000
Nick Coghlan wrote:
> On 8 November 2017 at 10:03, Guido van Rossum wrote:
> > OK, so let's come up with a set of heuristics that does the right thing for
> > those cases specifically. I'd say whenever you're executing code from a
> > zipfile or some such it's n
I'd call that a feature request. :-)
On Tue, Nov 7, 2017 at 9:28 PM, Nick Coghlan wrote:
> On 8 November 2017 at 14:58, Guido van Rossum wrote:
> > What does "RFE" mean? I don't recall hearing that term before on the
> Python
> > bug tracker. Request For E-what? (I presume it's a RedHat interna
On 8 November 2017 at 14:58, Guido van Rossum wrote:
> What does "RFE" mean? I don't recall hearing that term before on the Python
> bug tracker. Request For E-what? (I presume it's a RedHat internal term?)
Request for Enhancement (as opposed to a bug report). It's not Red Hat
specific, but short
What does "RFE" mean? I don't recall hearing that term before on the Python
bug tracker. Request For E-what? (I presume it's a RedHat internal term?)
On Tue, Nov 7, 2017 at 6:57 PM, Nick Coghlan wrote:
> On 8 November 2017 at 11:46, Guido van Rossum wrote:
> > On Tue, Nov 7, 2017 at 5:35 PM, Ni
On 8 November 2017 at 11:46, Guido van Rossum wrote:
> On Tue, Nov 7, 2017 at 5:35 PM, Nick Coghlan wrote:
>>
>> On 8 November 2017 at 10:03, Guido van Rossum wrote:
>> > OK, so let's come up with a set of heuristics that does the right thing
>> > for
>> > those cases specifically. I'd say whene
On Tue, Nov 7, 2017 at 5:35 PM, Nick Coghlan wrote:
> On 8 November 2017 at 10:03, Guido van Rossum wrote:
> > OK, so let's come up with a set of heuristics that does the right thing
> for
> > those cases specifically. I'd say whenever you're executing code from a
> > zipfile or some such it's n
On 8 November 2017 at 10:03, Guido van Rossum wrote:
> OK, so let's come up with a set of heuristics that does the right thing for
> those cases specifically. I'd say whenever you're executing code from a
> zipfile or some such it's not considered your own code (by default).
My current preferred
OK, so let's come up with a set of heuristics that does the right thing for
those cases specifically. I'd say whenever you're executing code from a
zipfile or some such it's not considered your own code (by default).
On Tue, Nov 7, 2017 at 2:16 PM, Nick Coghlan wrote:
> On 8 November 2017 at 06:
On 8 November 2017 at 06:32, Guido van Rossum wrote:
> On Mon, Nov 6, 2017 at 7:23 PM, Terry Reedy wrote:
>>
>> On 11/6/2017 9:47 PM, Nick Coghlan wrote:
>> [...]
>>>
>>> - "only show me legacy calls in *my* code" (the "I trust my deps to
>>> take care of themselves" use case)
>>
>>
>> Perhaps th
On Mon, Nov 6, 2017 at 7:23 PM, Terry Reedy wrote:
> On 11/6/2017 9:47 PM, Nick Coghlan wrote:
> [...]
>
>> - "only show me legacy calls in *my* code" (the "I trust my deps to
>> take care of themselves" use case)
>>
>
> Perhaps this should be the new default, where 'my code' means everything
> u
On 11/6/2017 9:47 PM, Nick Coghlan wrote:
On 7 November 2017 at 05:00, Alex Gaynor wrote:
I also feel this decision was a mistake. If there's a consensus to revert,
I'm happy to draft a PEP.
Even without consensus to revert, I think it would be great to have a
PEP summarising some of the trad
On 7 November 2017 at 05:00, Alex Gaynor wrote:
> I also feel this decision was a mistake. If there's a consensus to revert,
> I'm happy to draft a PEP.
Even without consensus to revert, I think it would be great to have a
PEP summarising some of the trade-offs between the different options.
And
I also feel this decision was a mistake. If there's a consensus to revert,
I'm happy to draft a PEP.
Alex
On Nov 6, 2017 1:58 PM, "Neil Schemenauer" wrote:
> On 2017-11-06, Nick Coghlan wrote:
> > Gah, seven years on from Python 2.7's release, I still get caught by
> > that. I'm tempted to prop
35 matches
Mail list logo
