Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

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 > > *

Re: [Python-Dev] PEP 561 rework

On 13 November 2017 at 17:33, Ethan Smith wrote: > On Sun, Nov 12, 2017 at 8:07 PM, Nathaniel Smith wrote: >> PyPI doesn't distinguish between the names 'foo-stubs' and 'foo_stubs' >> -- they get normalized together. So even if you use 'foo-stubs' as the >>

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

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

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

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

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

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

[Python-Dev] PEP 549 vs. PEP 562

I've pondered two PEPs that are in (friendly) competition with each other: - PEP 549 -- Instance Descriptors (Larry Hastings) - PEP 562 -- Module __getattr__ (Ivan Levkivskyi) In the end I am *rejecting* PEP 549 and I hope to *accept* PEP 562, with a small addition to the latter to also support

Re: [Python-Dev] PEP 561 rework

Hello everyone, Am 14.11.2017 um 00:29 schrieb Guido van Rossum: This is a nice piece of work. I expect to accept it pretty much verbatim (with some small edits, see https://github.com/python/peps/pull/467). I agree with Nick that we don't have to do anything specifically about control of

[Python-Dev] Python possible vulnerabilities in concurrency

I am looking for one or two experts to discuss with me how Python concurrency features fit together, and possible vulnerabilities associated with that. TR 24772 lists 5 vulnerabilities associated with 1. activating threads, tasks or pico-threads 2. Directed termination of threads, tasks or

Re: [Python-Dev] PEP 561 rework

Hi Ethan! This is a nice piece of work. I expect to accept it pretty much verbatim (with some small edits, see https://github.com/python/peps/pull/467). I agree with Nick that we don't have to do anything specifically about control of foo_stubs packages -- nor do I think we need to worry about

Re: [Python-Dev] PEP 561 rework

On Mon, Nov 13, 2017 at 3:50 PM, Sebastian Rittau wrote: > Am 14.11.2017 um 00:29 schrieb Guido van Rossum: > >> This is a nice piece of work. I expect to accept it pretty much verbatim >> (with some small edits, see https://github.com/python/peps/pull/467). I >> agree with

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

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:

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

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 >>

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

On 14 November 2017 at 02:08, Victor Stinner wrote: > My "-X dev" idea is not incompatible with Nick's PEP 565 "Show > DeprecationWarning in __main__" and it's different: it's an opt-in > option, while Nick wants to change the default behaviour. I'm +1 on a `-X dev`

Re: [Python-Dev] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

Can you give any examples of problems caused by the ast not being standardized? The original motivation of being able to distinguish between foo(x: int) foo(x: "int") isn't very compelling – it's not clear it's a problem in the first place, and even if it is then all we need is some kind of

Re: [Python-Dev] PEP 561 rework

On Mon, Nov 13, 2017 at 3:50 PM, Sebastian Rittau wrote: > Hello everyone, > > > Am 14.11.2017 um 00:29 schrieb Guido van Rossum: > >> This is a nice piece of work. I expect to accept it pretty much verbatim >> (with some small edits, see

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

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

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

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

Re: [Python-Dev] Disallow ambiguous syntax f(x for x in [1],)

FWIW, it is common to have syntax checks in ast.c. Especially situations like class ``C(x for x in [1]): ...`` I think would be hard to prohibit in Grammar. Since anyway we have many checks in ast.c already, I wouldn't care much about implementing these corner cases in Grammar. -- Ivan

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

2017-11-13 17:40 GMT+01:00 Antoine Pitrou : > I would personally not add `-b` in those options. I think it was > useful while porting stuff to 3.x, but not so much these days. You should consider youself as lucky if you completed to port all your code to Python 3. It's not

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

13.11.17 18:40, Antoine Pitrou пише: On Mon, 13 Nov 2017 17:08:06 +0100 Victor Stinner wrote: In short: python3.7 -X dev script.py behaves as: PYTHONMALLOC=debug python3.7 -Wd -b -X faulthandler script.py I would personally not add `-b` in those options. I

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

Le 13/11/2017 à 17:46, Victor Stinner a écrit : > 2017-11-13 17:40 GMT+01:00 Antoine Pitrou : >> I would personally not add `-b` in those options. I think it was >> useful while porting stuff to 3.x, but not so much these days. > > You should consider youself as lucky if

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

2017-11-13 17:51 GMT+01:00 Antoine Pitrou : > The main issue I have with `-b` is actually that you can get spurious > warnings about properly working code. You can also get warnings in > well-tested third-party libraries, e.g.: > >

[Python-Dev] process-wide warning settings

On Mon, 13 Nov 2017 18:19:07 +0100 Victor Stinner wrote: > > I really dislike this code since warnings.catch_warnings() is > process-wide and so impact other threads :-( > > (Maybe Yury's PEP "context variables" would help here? ;-)) They can't really help unless we

[Python-Dev] Add a developer mode to Python: -X dev command line option

Hi, The discussion on DeprecationWarning reminded me my old idea of a "development mode" for CPython: -X dev. Since Brett likes it, I post it on python-dev. Last year, I posted this idea to python-ideas but my idea was rejected:

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

On Mon, 13 Nov 2017 17:08:06 +0100 Victor Stinner wrote: > Hi, > > The discussion on DeprecationWarning reminded me my old idea of a > "development mode" for CPython: -X dev. Since Brett likes it, I post > it on python-dev. Last year, I posted this idea to python-ideas

Re: [Python-Dev] PEP 561 rework

Thanks Ethan for all the work! I will be glad to see this accepted and implemented in mypy. -- Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

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

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

> 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

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

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.

Re: [Python-Dev] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

Guido van Rossum wrote: But Python's syntax changes in nearly every release. The changes are almost always additions, so there's no reason why the AST can't remain backwards compatible. the AST level ... elides many details (such as whitespace and parentheses). That's okay, because the AST

Re: [Python-Dev] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

On Mon, Nov 13, 2017, 13:37 Greg Ewing, wrote: > Guido van Rossum wrote: > > But Python's syntax changes in nearly every release. > > The changes are almost always additions, so there's no > reason why the AST can't remain backwards compatible. > > > the AST level

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Sun, Nov 12, 2017, 10:22 Koos Zevenhoven, wrote: > On Nov 12, 2017 19:10, "Guido van Rossum" wrote: > > On Sun, Nov 12, 2017 at 4:14 AM, Koos Zevenhoven > wrote: > >> So actually my question is: What should happen when the annotation