Hacker News new | past | comments | ask | show | jobs | submit login

- Fast CPU performance. The PyPy implementation in my tests (JSON processing) was faster than Go and CPython (module used was a C library)

- Compiles to standalone binaries, C++ using Nuitka and other methods such as PyInstaller

- Fast speed of development

- Syntax: matter of personal taste. But overall Python is very terse

- Large community, ~20 year vast resources for use and learning

- IronPython for .Net libraries and Jython for Java libraries

- Versatile and already in largescale use for systems, web, administration scripting, game scripting, 3d applications, data modeling, game creation, crossplatform GUI applications, glue code

- iOS/Android/desktop support with Kivy

- Portable, embeddable and extendable

- Focus on readability/maintainability

- One of few languages that covers nearly every possible need well, though not top tier in all

- Bridges nicely to either exploring lower level aspects, strongly tied to C (and by extension assembler). Also offers ways to start learning functional programming within Python

- Already installed on Mac and most Linux distros

- The culture. Join us in a Python Meetup, and find out.

I did my homework before choosing to learn Python, and there is a huge con with Python3 (which many of my items do not apply to right now). But overall I'm not sure what your definition of better is, but I haven't found anything better or even close.




Citing "fast CPU performance" alongside "large community" and "already installed" sounds a bit disingenuous. The version that is fast has a smaller community and is unlikely to be already installed while the one that is already installed and has a large community is not fast.

Like it or not, "Python" means CPython to most people, inducing most library authors, and you run into problems using PyPy if you assume it's "just Python", especially if you have come to rely on Python's easy interfacing with C.


It wasn't stated alongside. "Most people" aren't ones I want to be around or work with. I come here to associate with those who do their homework. CPython and PyPy are the same Python community as PyPy runs Python code unmodified. PyPy also interfaces just as well with C, inform yourself.

Python is a language. Languages don't have speed. Implementations do.


>"Most people" aren't ones I want to be around or work with. I come here to associate with those who do their homework.

I am not sure what you mean here in the context of what I said. My was simply that most users of Python don't use PyPy, so most library authors don't test against it.

>CPython and PyPy are the same Python community as PyPy runs Python code unmodified.

Not all of it, as https://bitbucket.org/pypy/compatibility/wiki/Home will confirm.

>PyPy also interfaces just as well with C, inform yourself.

Sorry, this is where I did not make my point very clear. I meant to point out that the way in which PyPy interfaces with C is different from the one used by CPython, so libraries that rely on it don't work in PyPy without an extra porting effort.


CTypes and CFFI still work with PyPy. Also, 'not all of it'- well yes, this is a WIP with a ~2 man project/implementation. Not bad. What are you using that's not on the list? The intention isn't so that authors have to test against PyPy.. PyPy's intention is to be as compatible with CPython as possible.

Either way, while you attempt to discredit PyPy the fact remains that Python code is and can be very fast for CPU heavy work. There's no way around that other than trying to poke holes.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: