The point of the OP was "patterns for fast python", i.e performance. It's absurd to claim that you "advocate abstractions over performance" in the context of achieving performance, so your comparison doesn't make sense to me. Just because you don't advocate performance doesn't mean that these aren't the ways to achieve performance. In addition, it sounds you mostly agree with regard to rewriting in C... use it as a last resort. It sounds to me like you are just trying to disagree.

I don't see where in fijal's comment you got the impression that he doesn't advocate performance. I very much would hope (and believe) otherwise, that he cares very much about it. It also does not seem that he agrees at all with regard to writing in C, since his "last resort" sounds much more last than yours (again, a thing I'd expect from him ;). His point sounds like it is "if you care about performance, these are not really ways to get it, because they sacrifice more important things". If your issue with that is "yeah but I still want performance" I would bet that fijal would point you to PyPy :).

>you should not sacrifice your abstractions in favor of performance

I only point out that a list of optimization techniques that advocates nothing will be different than a list of optimization techniques that advocates certain abstractions at the expense of performance. And there's nothing sad about that.

I repeat, I see nothing there that says "don't optimize for performance".

It says "if you want performance don't do X because X is not a reasonable sacrifice". Then he linked to some better ones.

If you watch the linked talk, "write simple code when given the choice between simple and complex code" seems like fijal's main suggestion (and in my limited experience with PyPy has worked for me). The other main suggestion that I assume is underlying is "if you want performance try PyPy". Neither of those require sacrificing abstraction. Some of Guido's suggestions do.

>The point of the OP was "patterns for fast python", i.e performance. It's absurd to claim that you "advocate abstractions over performance" in the context of achieving performance, so your comparison doesn't make sense to me. Just because you don't advocate performance doesn't mean that these aren't the ways to achieve performance.

He never said he doesn't advocate performance. He said performance should not be achieved by sacrificing abstractions.

>In addition, it sounds you mostly agree with regard to rewriting in C... use it as a last resort.

In CPython, not necessarily in Guido's advice, it's one of the first and most common things you hear about performance. "Just write parts of it in C".

If that was the advice of the early JVM guys ("just write parts of it in JNI"), we would never have gotten a fast JVM.

>He never said he doesn't advocate performance.

Agreed. But Guido didn't advocate performance, or anything, so fijal is trying to disagree with him about a topic he didn't state an opinion on. There's no need to make up a disagreement. Imagine if fijal instead said:

"This is a fine list of techniques if you are willing to sacrifice your abstractions. At PyPy, we're not willing to do that, and we still achieve sufficiently high performance by..."

Do you have any tips from the last third of the talk that you needed to skip?

The value of those tips is unfortunately ephemeral, since we're improving in PyPy in a lot of places. I'll try to put it up in the form of blog post, to have a point of reference. No definite deadline yet though :)

We're talking about PyPy: http://pypy.org/

You seem to be talking about PyPi: http://pypi.python.org/

I personally was confused by this for a decent amount of time.

Now we need a "PiPy" (I suggest it simply be python implementation of the algorithm to calculate decimal places in pi) and PiPi (not idea what it would do). (Sorry about fluff comment, couldn't resist. We digress.)

Pipi is weewee in German. You pick what the project does :) (OT)

Ah thanks!