Hacker News Reader

Comment by amelius | Hacker News Reader

Why didn't the Python committee opt for a compiled system (like PyPy) when they moved to the 3.0 series (and had to break backward compatibility anyway)?

View on HN

I don't know specifically but the CPython ethos has often been to prize simplicity of the implementation over performance.

You are right, i think that Python is trying to be as expressive and succinct as possible. A runtime like pypy is very difficult to change, and it would therefore make it much more difficult to evolve the language.

Luckily „Faster CPython” is now a thing and even Guido participates in it.

Reasoning given for course correction was (AFAIR) that Python really could be faster for things like data science or ML.

> Why didn't the Python committee opt for a compiled system (like PyPy)

Because compilers are complicated and have trade-offs.

> and had to break backward compatibility anyway

A compiler shouldn't break backward compatibility.

> A compiler shouldn't break backward compatibility.

I don't understand what you mean by this in context (since they introduced a new language in python3).

They asked why didn't Python 3 introduce a compiler when they were able to break backwards compatibility.

That question doesn't make sense, because a compiler shouldn't have any impact on your compatibility.

They can introduce a compiler without breaking compatibility, so they don't need to do it with a new language version.

Oh I see what you mean, I misread the sentence. Switching between language backends has nothing to do with compatibility. Yup makes sense. They can swap implementations at any time.

The point really is that PyPy has some compatibility issues with the C api I think mostly because of the garbage collector. This has less to do with whether you compile or interpret bytecode, yes.

Reply on news.ycombinator.com