6 ms·

I wish the community would just switch entirely to pypy. Being able to just slightly performance sensitive code in python is a huge win.

masklinn 12y ago
> I wish the community would just switch entirely to pypy. What purpose would that serve? > Being able to just slightly performance sensitive code in python is a huge win. I think you slightly this phrase, but aside from that pypy does not work for everybody and everything (e.g. at best it's no slower for sphinx, it really doesn't like the way docutils works). It's not like pypy's a magic wand.
- deleted 12y ago
  [deleted]
- quacker 12y ago
  > What purpose would that serve? If PyPy became the official/canonical implementation, PyPy would receive more attention and third-party library compatibility would be a requirement. Complaints about Python's slowness would be somewhat less relevant, and Python might see wider adoption. The RPython toolchain would receive more attention and that could be useful to other languages. There are plenty of reasons, but PyPy is usually a free speedup for your Python application. Who's going to complain about that? > pypy does not work for everybody and everything True, but as the official implementation of Python, compatibility with PyPy would then be a must, and this situation would be greatly improved.
  - BuckRogers 12y ago
    I agree with you, but it will never happen. GvR wants a as-simple-as-possible reference implementation, for one, he has to maintain it with a volunteer dev team. Also, there's a split in the Python community between guys like me and you- and the scientific squad. Until the scientific stuff works 100% in PyPy you'd lose a significant portion of the Python userbase by dumping CPython. GvR has done enough damage to Python with Python3. I don't intend to encourage him to do make any more changes. Us Python web developers are better off using what we have (non reference implementations, which don't hurt anyone), or just use Node.js.
    - michh 12y ago
      I don't think it's fair to put the blame of the unfortunate way things have gone with Python 3 solely on the shoulders of GvR. Afaik, a huge part of the community felt this was the way to go. Unfortunely, it wasn't.
      - pekk 12y ago
        Killing Python 3 isn't something a majority of the community wants and it isn't objectively better either.
      - deleted 12y ago
        [deleted]
  - Fede_V 12y ago
    I agree entirely. What's kind of a pity is that until NumPy is ported over, all of the scientific stack is basically unusable on PyPy - and right now, there are several incredibly good NumPy specific JITs (numexpr, numba, parakeet).
ngoldbaum 12y ago
It makes sense to use pypy if you're writing pure python code. The second you need a C extension, you're pretty much out of luck. This kills a lot of the appeal for people in the scientific/analytics side of things, who make heavy use of legacy C and Fortran routines.
- rguillebert 12y ago
  You can use these C and Fortran routines on PyPy, just not with the CPython C extension API.
  - takluyver 12y ago
    There's a lot of established code built around the C API. It's not like it can just be rewritten using CFFI over a weekend.
    - rguillebert 12y ago
      Well, I'm not talking about every C extension in the world, I'm talking about thin bindings around C routines which is what numpy has for fft for example, someone wrote a basic equivalent for numpypy in a few hours with no prior numpypy/cffi knowledge.
      - onalark 12y ago
        Unfortunately, NumPy uses deep knowledge of the CPython API in quite a few places, which is one of the reasons implementing NumPyPy has been so challenging.
        rguillebert 12y ago
        Another approach should be used for those, but to be clear I wasn't talking about the entire numpy library, I'm talking about things like numpy.fft
- dragonwriter 12y ago
jamespo 12y ago
Maybe moving libraries & code to Python 3 should be the priority.
- cookiecaper 12y ago
  Convincing distros to package it as the default "python" should be the priority. Until that happens, Python 3 will see limited adoption. The path of least resistance will always have the most traffic.
  - cwyers 12y ago
    It's a chicken and egg problem. So long as most Python libraries run on Python 2 but not Python 3, distros are going to package Python 2.
    - Luyt 12y ago
      Actually, the majority of PyPI packages are python-3 compatible. For a status overview, see http://python3wos.appspot.com/ http://python3wos.appspot.com/
      - briancurtin 12y ago
        That's not what that site is saying. For my PyCon Russia talk, I pulled down the data for all 44,402 packages (as of May 31). 13.5% of all packages on PyPI support some version of Python 3. 75.5% of the top 200 packages by download count claim to support some Python 3 version (according to their setup.py classifiers). Additionally, 64% of the top 500 support some Python 3 version. Another interesting thing I saw was that of those 44K packages, 44% of them have seen a release within the last 12 months (representing 82% of the last month's download share), and 22% of those packages released in the last year support some version of Python 3.
    - cookiecaper 12y ago
      Someone has to take the first step and break the cycle to get the chicken-egg problem undone. Arch has had Python 3 as the default Python interpreter for a couple of years now and it's been working pretty much fine. Many libraries now support Python 3, and I've done full sites in Py 3. Almost all Python scripts I write these days are Python 3. I don't think I've had to downgrade a script that started in 3 down to 2 for a couple of years now. It's as ready as it's going to get. The groundwork is done, and I think everyone who is going to support Py 3 without any extra prodding has already done so. Now we need the distros to come through and give that extra nudge to the maintainers that are still slacking, or encourage people to replace those libraries that refuse to update.
ris 12y ago
How much memory do you have?
- dagw 12y ago
  For a sufficient performance increase? As much as it takes. Memory is cheap
  - ris 12y ago
    On servers and especially on virtualized servers it is absolutely not.

masklinn 12y ago

> I wish the community would just switch entirely to pypy. What purpose would that serve? > Being able to just slightly performance sensitive code in python is a huge win. I think you slightly this phrase, but aside from that pypy does not work for everybody and everything (e.g. at best it's no slower for sphinx, it really doesn't like the way docutils works). It's not like pypy's a magic wand.

deleted 12y ago
[deleted]
quacker 12y ago
> What purpose would that serve? If PyPy became the official/canonical implementation, PyPy would receive more attention and third-party library compatibility would be a requirement. Complaints about Python's slowness would be somewhat less relevant, and Python might see wider adoption. The RPython toolchain would receive more attention and that could be useful to other languages. There are plenty of reasons, but PyPy is usually a free speedup for your Python application. Who's going to complain about that? > pypy does not work for everybody and everything True, but as the official implementation of Python, compatibility with PyPy would then be a must, and this situation would be greatly improved.
- BuckRogers 12y ago
  I agree with you, but it will never happen. GvR wants a as-simple-as-possible reference implementation, for one, he has to maintain it with a volunteer dev team. Also, there's a split in the Python community between guys like me and you- and the scientific squad. Until the scientific stuff works 100% in PyPy you'd lose a significant portion of the Python userbase by dumping CPython. GvR has done enough damage to Python with Python3. I don't intend to encourage him to do make any more changes. Us Python web developers are better off using what we have (non reference implementations, which don't hurt anyone), or just use Node.js.
  - michh 12y ago
    I don't think it's fair to put the blame of the unfortunate way things have gone with Python 3 solely on the shoulders of GvR. Afaik, a huge part of the community felt this was the way to go. Unfortunely, it wasn't.
    - pekk 12y ago
      Killing Python 3 isn't something a majority of the community wants and it isn't objectively better either.
    - deleted 12y ago
      [deleted]
- Fede_V 12y ago
  I agree entirely. What's kind of a pity is that until NumPy is ported over, all of the scientific stack is basically unusable on PyPy - and right now, there are several incredibly good NumPy specific JITs (numexpr, numba, parakeet).

ngoldbaum 12y ago

It makes sense to use pypy if you're writing pure python code. The second you need a C extension, you're pretty much out of luck. This kills a lot of the appeal for people in the scientific/analytics side of things, who make heavy use of legacy C and Fortran routines.

rguillebert 12y ago
You can use these C and Fortran routines on PyPy, just not with the CPython C extension API.
- takluyver 12y ago
  There's a lot of established code built around the C API. It's not like it can just be rewritten using CFFI over a weekend.
  - rguillebert 12y ago
    Well, I'm not talking about every C extension in the world, I'm talking about thin bindings around C routines which is what numpy has for fft for example, someone wrote a basic equivalent for numpypy in a few hours with no prior numpypy/cffi knowledge.
    - onalark 12y ago
      Unfortunately, NumPy uses deep knowledge of the CPython API in quite a few places, which is one of the reasons implementing NumPyPy has been so challenging.
      - rguillebert 12y ago
        Another approach should be used for those, but to be clear I wasn't talking about the entire numpy library, I'm talking about things like numpy.fft
dragonwriter 12y ago

jamespo 12y ago

Maybe moving libraries & code to Python 3 should be the priority.

cookiecaper 12y ago
Convincing distros to package it as the default "python" should be the priority. Until that happens, Python 3 will see limited adoption. The path of least resistance will always have the most traffic.
- cwyers 12y ago
  It's a chicken and egg problem. So long as most Python libraries run on Python 2 but not Python 3, distros are going to package Python 2.
  - Luyt 12y ago
    Actually, the majority of PyPI packages are python-3 compatible. For a status overview, see http://python3wos.appspot.com/ http://python3wos.appspot.com/
    - briancurtin 12y ago
      That's not what that site is saying. For my PyCon Russia talk, I pulled down the data for all 44,402 packages (as of May 31). 13.5% of all packages on PyPI support some version of Python 3. 75.5% of the top 200 packages by download count claim to support some Python 3 version (according to their setup.py classifiers). Additionally, 64% of the top 500 support some Python 3 version. Another interesting thing I saw was that of those 44K packages, 44% of them have seen a release within the last 12 months (representing 82% of the last month's download share), and 22% of those packages released in the last year support some version of Python 3.
  - cookiecaper 12y ago
    Someone has to take the first step and break the cycle to get the chicken-egg problem undone. Arch has had Python 3 as the default Python interpreter for a couple of years now and it's been working pretty much fine. Many libraries now support Python 3, and I've done full sites in Py 3. Almost all Python scripts I write these days are Python 3. I don't think I've had to downgrade a script that started in 3 down to 2 for a couple of years now. It's as ready as it's going to get. The groundwork is done, and I think everyone who is going to support Py 3 without any extra prodding has already done so. Now we need the distros to come through and give that extra nudge to the maintainers that are still slacking, or encourage people to replace those libraries that refuse to update.

ris 12y ago

How much memory do you have?

dagw 12y ago
For a sufficient performance increase? As much as it takes. Memory is cheap
- ris 12y ago
  On servers and especially on virtualized servers it is absolutely not.