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

[Sven R. Kunze]

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.lru_cache 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>