u/thinkwelldesigns

JIT topics: guard-compatible, and the subsequent research project to save and reuse traces across processes

Is that re-using traces in multiple process when using the multiprocessing module, or re-using traces between program launches / restarts?

That would be a game-changer for PyPy! Very glad to hear of your progress!

+1 to @LightShadow's list. For JSON, I recently switched from ujson to rapidjson. Is mostly as fast as ujson and more compatible with the std lib json package. Works better with rest_framework UUIDs for example.

Very glad for the release, especially the native partitioning and parallel query improvements!

One question - does anyone know if v10 does anything for the write amplification problem that Uber blogged about?

Odoo ported v11 to Python 3.5+

Um, this would be Victor Stinner writing (and on a scratchpad at this point). He's a core dev and probably the most consistently focused on speed improvements.

The GIL replacement section wasn't a serious proposal but an overview how it would become easier to remove / mitigate the GIL problem. GC and the C API always come up in every discussion of the GIL problem, so a short reference to how the PEP might change the GIL landscape is reasonable.

Thanks for the blog post, the draft PEP, and everything you do for Python performance, Victor!

Thanks for this library!!! I'm already using centrifugo in my app, and this will make it easier! 16 stars now. :-)

Is this project really alive or has Victor moved on to other optimization ideas? There was some discussion on python-dev here and here but it doesn't seem to be a foregone conclusion that this will be implemented.

Is there more recent work & progress on this?

+1

Edit: 6 hours later and thread locked. I'm self employed; so no, there are no other views than my own represented. To those who express such concern, I would point out that the comment was about the institution of gay marriage, and not any persons in particular.

Having said that, I suspected that even a +1 would be unpopular. Why the unpopularity is perhaps an interesting question; but not for this time and place. I love you all, and for religious reasons.

Yep. That is in regards to Pyjion (https://github.com/Microsoft/pyjion) and is being worked on by two of my excellent coworkers!

But is it being worked on? I've been watching the Pyjion project closely ever since it started but it seems like it has stalled. The latest commit mentions it's a side project and work is sporadic. In any case, I don't see that it can be called an "official JIT".

Pep 523 is the basis for Pycharm's debugger performance enhancements so 523 benefits the ecosystem regardless of whether or not an official JIT is produced.

Will it ever be possible to target the Android platform / JVM with Nim?

Joined! Thank you for allowing us to share the financial costs of developing. I'm quite impressed with the VOC approach to getting python on android. Your idea seems like an original and most-likely-to-succeed solution.

Here's to you getting 2,000 supporters!

Intriguing! I've never heard of intercooler before. Will have to check this out; looks very elegant.

Thanks for the post!

Nope. We use Python 2.7 for Odoo work; 3.6 for everything else.

I'm on python 3.6, and haven't found any packages that don't work. And I use quite a number of the popular ones, although not numpy. So I don't know about that one. Unless you actually find a package that breaks, I'd recommend 3.6.

3.4 was the first "feasible to use". 3.5 was "great to use". 3.6 is "must use", IMO.

This! I saw the title and thought, I'm going to post about django-rules. Supremely powerful, but simple, library.

Python 3.6 is already the fastest python ever on a number of benchmarks. I expect 3.7 will be the fasted of all time across the board. Watch the bug tracker. Victor Stinner and Serhiy Storchaka submit a steady stream of performance-improving patches.

Excellent series of articles. Very timely in my case as I have a few such modules to work on very soon. Numbers of times as I read I sensed pitfalls averted. Thanks for writing/posting!

So Pyston doesn't provide the speedup scale that Dropbox needs. Python just can't become Go, but many workloads would be happy with a more modest speed improvements in cPython.

Would there be any lessons learned that can be pulled into cPython?

I went through the commits in this thread and manually applied them to v1.10 and it's running without errors on Python 3.6.

I had a similar cycle of tutorials, resources, and never quite getting it. Then a few years ago I took the MITX 6.01 Introduction to Computer Science and Programming Using Python

It was a temptation to skip over the early parts that I was already familiar with, and to waffle on the harder exercises later in the course. But by then I was desperate to get my head around Python and so I ground through, following the course as presented.

In the end, it paid off; it was the course that truly broke me through to the sunny uplit lands. Well, not quite that dramatic, but it was literally the turning point.

So many courses and tutorials don't teach you the underlying computer science basics, which this course does. It's not a Python course, per se, or a CS course, but a mix of both. It really builds a solid foundation of what you'll later use, but that may only be clear in retrospect.

After taking the course, then keep working on interesting problems. CODE EVERY DAY!

Thanks for this article! We need to keep a comprehensive perspective when thinking about new protocols. I hope that Google and Facebook don't get to bully their way on this.

Because of the current inability to filter QUIC, we block UPD on ports 80 and 443 on our networks.

I don't have anything automated at the moment but would be happy to provide command lines for any of the tools.

That'd be awesome.

I'll try to compare Jinja2 to Django templates to see how that affects stack performance. That'd be very interesting too. If that makes a measurable difference, I'd consider switching.