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` mode, since it enables a lot o
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 pico
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 https://github.com/python/peps/pull/467). I
>> agree with
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 Nick that we don't hav
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
>>
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 foo
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 o
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 boo
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
foo
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 is
>> already a string literal?
>>
>
> The PEP answers tha
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 ... elides many details
> > (suc
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
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 break the catch_warnings() A
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.:
>
> distributed/tests/test_client.py::test_get_versions
>
> /home/a
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 you completed to port al
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 think it was
useful while p
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 my case yet :-) (I'm th
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 but my
> idea was rejected:
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
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:
https://mail.python.org/pipermail/python-ideas/2016-March/039314.htm
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:
https://mail.python.org/mailman/optio
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
___
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
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
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 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
>> directory name on sys.path to avoid col
32 matches
Mail list logo
