Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Fri, Apr 24, 2015 at 6:05 PM, Ronan Lamy wrote: > Le 24/04/15 19:45, Paul Sokolovsky a écrit : > >> Hello, >> >> On Fri, 24 Apr 2015 18:27:29 +0100 >> Ronan Lamy wrote: >> >> PyPy's FAQ > has an explanation of why type hints are not for performance. > > http://pypy.readthedocs.or

Re: [Python-Dev] Python-versus-CPython question for __mul__ dispatch

We have a similar experience -- Pyston runs into a similar issue with sqlalchemy (with "str() + foo" calling foo.__radd__ before str.sq_concat) and we are working to match CPython's behavior. On Tue, May 19, 2015 at 7:00 AM, Armin Rigo wrote: > Hi Nick, > > On 16 May 2015 at 10:31, Nick Coghlan

Re: [Python-Dev] Intricacies of calling __eq__

My 2 cents: it feels like a slippery slope to start guaranteeing the number and ordering of calls to comparison functions -- for instance, doing that for the sort() function would lock in the sort implementation. It feels like the number/ordering of the calls should be "implementation-defined" in

Re: [Python-Dev] Intricacies of calling __eq__

I think in this case, though, if we say for the sake of argument that the guaranteed semantics of a dictionary lookup are zero or more calls to __hash__ plus zero or more calls to __eq__, then two back-to-back dictionary lookups wouldn't have any observable differences from doing only one, unless y

Re: [Python-Dev] Intricacies of calling __eq__

, Mar 18, 2014 at 9:54 PM, Stephen J. Turnbull wrote: > Kevin Modzelewski writes: > > > I think in this case, though, if we say for the sake of argument > > that the guaranteed semantics of a dictionary lookup are zero or > > I don't understand the point of that argume

[Python-Dev] Pyston: a Python JIT on LLVM

Hi all, I'm excited to announce Pyston, a Python JIT under development at Dropbox, built on top of LLVM. You can read more about it at the introductory blog post, or check out the code on github

Re: [Python-Dev] Pyston: a Python JIT on LLVM

ce" can be very useful ex. in a numerical computing context, but might not apply as well to a "large web application" case. On Thu, Apr 3, 2014 at 3:42 PM, Sturla Molden wrote: > Kevin Modzelewski wrote: > > > Since it's the question that I think most people will i

Re: [Python-Dev] Pyston: a Python JIT on LLVM

On Fri, Apr 4, 2014 at 1:59 AM, Antoine Pitrou wrote: > > I'm a bit surprised by the approach. Why don't you simply process CPython > bytecode, rather than strive to reimplement Python fully? > The original choice to operate on Python AST rather than bytecode was made somewhat arbitrarily, but I

[Python-Dev] Re: Speeding up CPython

I'd love to hear more about what workloads you're targeting and how you came up with the anticipated numbers for the improvements. For comparison, our new jit provides a single-digit-percentage speedup on our django and flask benchmarks. On Tue, Oct 20, 2020 at 9:03 AM Mark Shannon wrote: > Hi

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

fwiw we added immortal objects to Pyston and haven't run into any issues with it. The goal is a bit different: to eliminate common refcount operations for performance, which we can do a bit more of because we have a jit. And we don't mind if unaware code ends up changing the refcounts of immortal o

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

fwiw Pyston has immortal objects, though with a slightly different goal and thus design [1]. I'm not necessarily advocating for our design (it makes most sense if there is a JIT involved), but just writing to report our experience of making a change like this and the compatibility effects. Importa

[Python-Dev] Contributing the Pyston jit?

Hello all, we on the Pyston team would like to propose the contribution of our JIT into CPython main. We're interested in some initial feedback on this idea before putting in the work to rebase the jit to 3.12 for a PEP and

[Python-Dev] Re: Contributing the Pyston jit?

Ah ok thanks for the tip, I re-posted this as https://discuss.python.org/t/contributing-the-pyston-jit/24195 On Thu, Feb 23, 2023 at 6:02 PM Brett Cannon wrote: > FYI you will probably get more engagement if you posted this to > discuss.python.org . > > On Thu, Feb 23, 2023,

Re: [Python-Dev] Stop using timeit, use perf.timeit!

Hi all, I wrote a blog post about this. http://blog.kevmod.com/2016/06/benchmarking-minimum-vs-average/ We can rule out any argument that one (minimum or average) is strictly better than the other, since there are cases that make either one better. It comes down to our expectation of the underlyin

Re: [Python-Dev] [Python-checkins] Daily reference leaks (b78574cb00ab): sum=1120

Hi Yury, you may be interested in some leak-finding code that wrote for Pyston. It uses the GC infrastructure to show you objects that were directly leaked, ignoring indirect leaks -- ie objects that were only leaked because they were referenced by a leaked object. It can often give you a very sm