[Python-Dev] FAT Python (lack of) performance (original) (raw)

Sven R. Kunze srkunze at mail.de
Wed Jan 27 13:40:44 EST 2016

On 27.01.2016 12:16, Nick Coghlan wrote:

On 27 January 2016 at 03:35, Sven R. Kunze <srkunze at mail.de> wrote:

I completely agree with INADA.

It's like saying, because a specific crossroad features a higher accident rate, people need to change their driving behavior. No! People won't change and it's not necessary either. The crossroad needs to be changed to be safer. Umm, no, that's not how this works

That's exactly how it works, Nick.

INADA uses Python as I use crossroads each day. Daily human business.

If you read his post carefully, you can discover that he just presented to you his perspective of the world. Moreover, I can assure you that he's not alone. As usual with humans it's not about facts or mathematically proven theorems but perception. It's more about marketing, little important details (or unimportant ones depending on whom you ask) and so on. Stating that he has a wrong perspective will not change anything. Believing that Python is treated unfair will not change that either.

Most people believe what they see. When they see a "FUNCTION CALL", it's the same in every language. Why? Because it looks like a function call ( name + parentheses ), it's called "function call" even if it's implemented completely differently. It even doesn't matter if we use commas, 'def', return types, etc. Because people understand the bigger concept, so that is what people want to compare.

Average Joe doesn't care and does not understand. He looks at the benchmarks. That is something he can understand. "While performance is not a matter when choosing first language, slowest of three makes bad impression and people feel less attractive about Python." << just like that

Not saying that INADA is an Average Joe, but I think you get the idea.

- developers contribute to community driven projects for their own reasons. Nobody gets to tell them what to do unless they're paying them.

Bit off-topic.

Micro-optimising a poor algorithm won't deliver macro level improvements because macro level code uses things like space-speed trade-offs to improve the algorithmic efficiency (as in the example of applying functools.lrucache to a naive recursive fibonacci implementation).

I completely agree, Nick. :) But that isn't the issue here.

Victor's work on FAT optimiser is interesting because it offers opportunities to speed up even code that is already algorithmically efficient, as well as making CPython a better platform for experimenting with those kinds of changes.

Exactly. :)

More generally though, much larger opportunities for improvement lie in persuading people to stop writing code, and instead spending more of their time on finding and assembling code other people have already written into solutions to interesting problems. That's the kind of improvement that turns enormously complex problems like facial recognition into 25 line Python scripts: https://realpython.com/blog/python/face-recognition-with-python/

Interesting post. :) Thanks.

Btw. I completely agree with you on the "improve programming education", but not everybody can do it; and not everybody wants to learn and to practice it properly.

Best, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160127/3d97ab08/attachment-0001.html>

More information about the Python-Dev mailing list