[Python-Dev] Re: PEP 617: New PEG parser for CPython

2020-04-18 Thread Nam Nguyen
On Sat, Apr 18, 2020 at 9:45 PM Guido van Rossum wrote: > But I never found the time to make it an appealing parser generator tool > for other languages, even though that was on my mind as a future > possibility. > I simply want to +1 on this. A general purpose parser library in the stdlib woul

[Python-Dev] Re: PEP 617: New PEG parser for CPython

2020-04-18 Thread Guido van Rossum
On Sat, Apr 18, 2020 at 4:53 PM Carl Meyer wrote: > The PEP is exciting and is very clearly presented, thank you all for > the hard work! > > Considering the comments in the PEP about the new parser not > preserving a parse tree or CST, I have some questions about the future > options for Python

[Python-Dev] Re: PEP 554 comments

2020-04-18 Thread Greg Ewing
On 19/04/20 5:02 am, Antoine Pitrou wrote: * How hard would it be, in the current implementation, to add buffering to channels? * In the same vein, I think channels should allow adding readiness callbacks Of these, I think the callbacks are more fundamental. If you have a non-buffered ch

[Python-Dev] Re: PEP 617: New PEG parser for CPython

2020-04-18 Thread Carl Meyer
The PEP is exciting and is very clearly presented, thank you all for the hard work! Considering the comments in the PEP about the new parser not preserving a parse tree or CST, I have some questions about the future options for Python language-services tooling which requires a CST in order to roun

[Python-Dev] Re: Further PEP 615 Discussion: Equality and hash of ZoneInfo

2020-04-18 Thread Chris Angelico
On Sun, Apr 19, 2020 at 3:39 AM Paul Ganssle wrote: > > A few weeks ago, I submitted PEP 615 to the steering council for a decision. > There's been a decent amount of discussion there with some very good > questions. I think they are mostly resolved (though I'm happy to have other > people look

[Python-Dev] Further PEP 615 Discussion: Equality and hash of ZoneInfo

2020-04-18 Thread Paul Ganssle
A few weeks ago, I submitted PEP 615 to the steering council for a decision. There's been a decent amount of discussion there with some very good questions. I think they are mostly resolved (though I'm happy to have other people look over the l

[Python-Dev] Re: PEP 554 comments

2020-04-18 Thread Antoine Pitrou
On Sat, 18 Apr 2020 19:02:47 +0200 Antoine Pitrou wrote: > > * I do think a minimal synchronization primitive would be nice. > Either a Lock (in the Python sense) or a Semaphore: both should be > relatively easy to provide, by wrapping an OS-level synchronization > primitive. Then you can

[Python-Dev] PEP 554 comments

2020-04-18 Thread Antoine Pitrou
Hello, First, I would like to say that I have no fondamental problem with this PEP. While I agree with Nathaniel that the rationale given about the CSP concurrency model seems a bit weak, the author is obviously expressing his opinion there and I won't object to that. However, I think the PEP i

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

2020-04-18 Thread Antoine Pitrou
On Sat, 18 Apr 2020 10:08:27 -0600 Eric Snow wrote: > On Sat, Apr 18, 2020, 01:16 Antoine Pitrou wrote: > > > On Fri, 17 Apr 2020 13:59:46 -0600 > > Eric Snow wrote: > > > > For bytes or buffer objects, I understand that you propose to share > > > > the exact same PyObject objects between int

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

2020-04-18 Thread Eric Snow
On Sat, Apr 18, 2020, 01:16 Antoine Pitrou wrote: > On Fri, 17 Apr 2020 13:59:46 -0600 > Eric Snow wrote: > > > For bytes or buffer objects, I understand that you propose to share > > > the exact same PyObject objects between interpreters, at least in the > > > first implementation. > > > > > >

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

2020-04-18 Thread Luciano Ramalho
It is not clear to me (as an end-user of Python) what is the value of exposing subinterpreters at the Python level except for multi core concurrency, but that requires one GIL per subinterpreter. Paul Moore mentions “alternative code structuring” as a benefit, but I don’t know what that means in c

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

2020-04-18 Thread Paul Moore
On Sat, 18 Apr 2020 at 00:03, Eric Snow wrote: > > On Fri, Apr 17, 2020 at 2:59 PM Nathaniel Smith wrote: > > I know you want folks to consider PEP 554 on its own merits, ignoring > > the GIL-splitting work, but let's be realistic: purely as a > > concurrency framework, there's at least a dozen

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

2020-04-18 Thread Antoine Pitrou
On Fri, 17 Apr 2020 13:59:46 -0600 Eric Snow wrote: > > For bytes or buffer objects, I understand that you propose to share > > the exact same PyObject objects between interpreters, at least in the > > first implementation. > > > > It may be better to have one proxy object in each interpreter whic