[Python-Dev] Re: [python-committers] Re: Re: Resignation from Stefan Krah

Reading through this thread and the linked comment chains was very educational. While I'm not involved enough to form an educated opinion, it's good to see that the wheels of python org are moving. That being said, I think that "dear stefan" email could have been written better. Also +1 on "not

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

On Thu, Oct 22, 2020 at 09:48:54AM -0700, Guido van Rossum wrote: > After the pattern matching discussion died out, we discussed it with the > Steering Council. Our discussion ended fairly positive, but there were a > lot of problems with the text. We decided to abandon the old PEP 622 and > break

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

On Thu, Oct 22, 2020 at 10:42 AM MRAB wrote: > [Guido] > > - SyntaxError if an irrefutable case[1] is followed by another case > block. > > - SyntaxError if an irrefutable pattern[1] occurs on the left of '|', > > e.g. 'x | [x]'. > > Is "syntax error" that the right term for it? Maybe it should

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

On 2020-10-22 17:48, Guido van Rossum wrote: After the pattern matching discussion died out, we discussed it with the Steering Council. Our discussion ended fairly positive, but there were a lot of problems with the text. We decided to abandon the old PEP 622 and break it up into three parts:

[Python-Dev] Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

After the pattern matching discussion died out, we discussed it with the Steering Council. Our discussion ended fairly positive, but there were a lot of problems with the text. We decided to abandon the old PEP 622 and break it up into three parts: - PEP 634: Specification - PEP 635: Motivation

[Python-Dev] Re: Speeding up CPython

I don’t have much to add to this thread, except to ask whether Mark has been in contact with Carl Shapiro. Carl’s posted here before, but I don’t think he’s an active mailing list participant. Carl has a lot of experience with VMs and has been doing interesting work on performant Python

[Python-Dev] Re: PyPy performance stats (was Re: Speeding up CPython)

Antoine Pitrou writes: > On Wed, 21 Oct 2020 22:48:59 +1100 > Chris Angelico wrote: >> >> SQLAlchemy seems to be slower, but if you're using SQLAlchemy, you're >> probably more concerned about database performance than the CPU cost >> inside Python. > > I certainly wouldn't say that. The ORM's

[Python-Dev] Re: Speeding up CPython

On 22Oct2020 1341, Marco Sulla wrote: On Thu, 22 Oct 2020 at 14:25, Mark Shannon > wrote: MSVC seems to do better jump fusion than GCC. Maybe I'm wrong, since I only take a look at dict, tuple and set C code, but it does not seems to me that there's more than 1-2

[Python-Dev] Re: Speeding up CPython

On Thu, 22 Oct 2020 at 14:25, Mark Shannon wrote: > MSVC seems to do better jump fusion than GCC. > Maybe I'm wrong, since I only take a look at dict, tuple and set C code, but it does not seems to me that there's more than 1-2 GOTOs in every CPython function, and they can't be merged.

[Python-Dev] Re: Speeding up CPython

Hi Paul, On 22/10/2020 1:18 pm, Paul Moore wrote: On Thu, 22 Oct 2020 at 12:52, Mark Shannon wrote: Getting a PGO/LTO comparison against 3.10 is tricky. Mainly because I'm relying on merging a bunch of patches and expecting it to work :) However, on a few simple benchmarks I'm seeing about a

[Python-Dev] Re: Speeding up CPython

On Thu, 22 Oct 2020 at 12:52, Mark Shannon wrote: > Getting a PGO/LTO comparison against 3.10 is tricky. > Mainly because I'm relying on merging a bunch of patches and expecting > it to work :) > > However, on a few simple benchmarks I'm seeing about a 70% speedup vs > master for both default and

[Python-Dev] Re: Speeding up CPython

Hi Nathaniel, On 22/10/2020 7:36 am, Nathaniel Smith wrote: Hi Mark, This sounds really cool. Can you give us more details? Some questions that occurred to me while reading: - You're suggesting that the contractor would only be paid if the desired 50% speedup is achieved, so I guess we'd

[Python-Dev] Re: Speeding up CPython

Hi Greg, On 21/10/2020 11:57 pm, Greg Ewing wrote: A concern I have about this is what effect it will have on the complexity of CPython's implementation. CPython is currently very simple and straightforward. Some parts are not quite as simple as they used to be, but on the whole it's fairly

[Python-Dev] Re: Speeding up CPython

> On 20 Oct 2020, at 14:53, Mark Shannon wrote: > > Hi everyone, > > CPython is slow. We all know that, yet little is done to fix it. > > I'd like to change that. > I have a plan to speed up CPython by a factor of five over the next few > years. But it needs funding. > > I am aware that

[Python-Dev] Re: Speeding up CPython

Hi Mark, This sounds really cool. Can you give us more details? Some questions that occurred to me while reading: - You're suggesting that the contractor would only be paid if the desired 50% speedup is achieved, so I guess we'd need some objective Python benchmark that boils down to a single