PyPy nie jest rozwidleniem CPythona, więc nigdy nie można go połączyć bezpośrednio z CPythonem.
Teoretycznie społeczność Pythona mogłaby uniwersalnie przyjąć PyPy, PyPy mogłoby stać się implementacją referencyjną, a CPython mógłby zostać przerwany. Jednak PyPy ma swoje słabości:
- CPython jest łatwy do zintegrowania z modułami Pythona napisanymi w C, co jest tradycyjnym sposobem, w jaki aplikacje Pythona obsługiwały zadania intensywnie wykorzystujące procesor (patrz na przykład projekt SciPy).
- Sam krok kompilacji PyPy JIT kosztuje czas procesora - tylko dzięki wielokrotnemu uruchamianiu skompilowanego kodu staje się on ogólnie szybszy. Oznacza to, że czasy uruchamiania mogą być dłuższe, a zatem PyPy niekoniecznie jest tak wydajne do uruchamiania kodu kleju lub trywialnych skryptów.
- Zachowanie PyPy i CPython nie jest identyczne pod każdym względem, szczególnie jeśli chodzi o „szczegóły implementacji” (zachowanie, które nie jest określone w języku, ale jest nadal ważne na poziomie praktycznym).
- CPython działa na większej liczbie architektur niż PyPy i został z powodzeniem przystosowany do pracy w architekturach osadzonych w sposób, który może być niepraktyczny dla PyPy.
- Schemat zliczania referencji CPythona do zarządzania pamięcią prawdopodobnie ma bardziej przewidywalny wpływ na wydajność niż różne systemy GC PyPy, chociaż niekoniecznie jest to prawdą w przypadku wszystkich strategii „czystego GC”.
- PyPy nie obsługuje jeszcze w pełni Pythona 3.x, chociaż jest to aktywny element pracy.
PyPy to świetny projekt, ale szybkość wykonywania zadań intensywnie wykorzystujących procesor to nie wszystko, aw wielu aplikacjach jest to najmniejszy problem. Na przykład Django może działać na PyPy, co przyspiesza tworzenie szablonów, ale sterowniki bazy danych CPythona są szybsze niż PyPy; ostatecznie to, która implementacja jest bardziej wydajna, zależy od tego, gdzie jest wąskie gardło w danej aplikacji.
Inny przykład: można by pomyśleć, że PyPy świetnie nadaje się do gier, ale większość strategii GC, takich jak te używane w PyPy, powoduje zauważalne wahania. W przypadku CPythona większość elementów gry wymagających dużej mocy obliczeniowej jest przenoszona do biblioteki PyGame, z której PyPy nie może skorzystać, ponieważ PyGame jest głównie zaimplementowany jako rozszerzenie C (choć zobacz: pygame-cffi). Nadal uważam, że PyPy może być świetną platformą do gier, ale nigdy nie widziałem, aby faktycznie była używana.
PyPy i CPython mają radykalnie różne podejścia do podstawowych pytań projektowych i dokonują różnych kompromisów, więc żadne z nich nie jest „lepsze” od innych w każdym przypadku.