PyPy Blog

Maybe not "daily", but very frequently: here is a small selection of some of the small sites on my newsblur newsfeed list: [0]

http://www.jamesaltucher.com : Much self-pity, but also sometimes quite funny.

http://www.astrobio.net/latestnews_rss/news.xml : Is there life on other planets?

http://kaygun.tumblr.com/

http://www.friday.com/bbum : Coding, hardware projects, generally interesting.

http://bestyoucanbe.blogspot.com/ : Insights into the education system in regard to the raising of his neurologically non-typical son.

http://blog.lmorchard.com

http://ex-muslim.org.uk : Oppression of atheists in the Muslim world.

http://clojurefun.wordpress.com : Clojure!

http://scientopia.org/blogs/goodmath : Bad science, denialism.

http://blog.willbenton.com : Music, logic, programming, etc.

http://www.groklaw.net : Maybe not "small"; detailed analysis of important legal cases.

http://hicksdesign.co.uk/journal : Web design.

http://www.holovaty.com/ : "I'm co-creator and co-Benevolent Dictator For Life of the open-source Django Web framework"

http://prometheus.med.utah.edu/~bwjones : Combines talented photography, photoessays, and study of the retina.

http://lee-phillips.org : I regularly check my site to see if it's still working.

http://chronicle.com/blogs/linguafranca : Language issues; can be amusing or stupid.

http://freethoughtblogs.com/maryamnamazie : Freedom for women in the Muslim world.

http://math-blog.com : Infrequently updated, but often…

> I was mostly replying to your assertion that "that's not even remotely how strcmp is implemented", which, for most definition of "even remotely", is false.

eglibc's SSE2 implementation of strcmp is just over 5k of machine code, whereas the simple implementation compiles to 56 bytes on x64-64. That was my definition of "not even remotely." I did not mean to imply that it was a fundamentally different algorithm, only that it was a far more sophisticated and optimized implementation of the same algorithm. My apologies if this was unclear or appeared overstated.

> That's a tautology at best, and meaningless at worst.

By "these abstraction possibilities" I meant the ones you mentioned, which is true.

> And similarly, any Python application that requires (insert some uncommon requirement ..) can do what C can with the same kind of help that strcmp() gets - by delegating to the layer that does it best.

That's great and I fully support that. What I am arguing against is high-level language cheerleading that discounts the importance of C (or assembly for that matter). Since you mention PyPy, I have to say that their PR is some of the worst in this regard; some of their "faster than C" claims are actively misleading, like this one that benchmarks some generated string formatting code against sprintf() (which re-parses the format string every time): http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html

PEP 412 makes __dict__s more memory efficient than they were before, but not more efficient than no __dict__, which is the point of __slots__. The following program demonstrates the difference. Note that it lowers the available address space to 1GB so that memory exhaustion occurs sooner, and thus only works on UNIX-like systems that provide the resource module.

import resource
import sys

class WithoutSlots:
def __init__(self, a, b):
self.a = a
self.b = b

class WithSlots:
__slots__ = ('a', 'b')
def __init__(self, a, b):
self.a = a
self.b = b

resource.setrlimit(resource.RLIMIT_AS, (1024 ** 3, 1024 ** 3))
cls = WithSlots if sys.argv[1:] == ['slots'] else WithoutSlots
count, instances = 0, []
while True:
try:
instances.append(cls(1, 2))
except MemoryError:
break
count = len(instances)
del instances
print(cls, count)

Here are numbers from my laptop:

$ python3.6 /tmp/slots.py
<class '__main__.WithoutSlots'> 5830382
$ python3.6 /tmp/slots.py slots
<class '__main__.WithSlots'> 16081964

That's almost 3x more instances with __slots__! This isn't the case with PyPy, though, thanks to a more efficient representation of objects:

https://morepypy.blogspot.com/2010/11/efficiently-implementing-python-objects.html

Thanks for that link. In that video Travis Oliphant is proposing "EPython", the goal of which is to allow multiple Python implementations to share the same extensions. Currently NumPy and other extensions are very tightly coupled to CPython.

But I just saw a very similar project by the name "HPy" on the PyPy blog:

https://morepypy.blogspot.com/2019/12/hpy-kick-off-sprint-report.html

The idea of HPy was born during EuroPython 2019 in Basel, where there was an informal meeting which included core developers of PyPy, CPython (Victor Stinner and Mark Shannon) and Cython (Stefan Behnel). The ideas were later also discussed with Tim Felgentreff of GraalPython, to make sure they would also be applicable to this very different implementation, Windel Bouwman of RustPython is following the project as well.

And they even say NumPy is a major use case:

Eventually, we will also want to try to port parts of numpy to HPy to finally solve the long-standing problem of sub-optimal numpy performance in PyPy.

Anyway there's nothing wrong with competing projects. Progress gets made faster that way. But I guess it's weird that the video and the blog post have very similar dates but don't mention each other. The problem they're solving seems essentially identical, and they even mention all the same Python interpreter implementations.

Hi Alex, mine might be a minority view/request, but I think RPython is an interesting and useful language in its own right and should be standardized and highlighted. Possibly separated out with a website of its own to emphasize its existence.

When I write Python it is rarely the case that I assign values of different types to the same identifier, or add attributes to a class outside of its definition, or monkey patch a module. In other words most of the time I am not really making use of the dynamic properties of the language. In this scenario Python is a language that saves me "finger typing", and I do not needs its dynamic typing as much. I am more than willing, in these scenarios, to trade some of that unused dynamism for better performance. I think there might be others who are similarly inclined.

The one thing that I miss in RPython is generators. Is there a particular difficulty because of which it was left out ? I assume so, because all the statically typed variants of Python leave it out as well, but I do not have enough background to know what that difficulty might be. The other is Numpy :) but I believe you guys are working on that.

@wbhart A lot of what you ask is answered in some detail in the PyPy blog http://morepypy.blogspot.com/ I wouldnt call PyPy less well known though.

Quick how-to:

1. (optional) install PyPy "JIT compiler" binaries [0]

2. get and extract the PyPy source[1] from bitbucket release packages, which includes the RPython translator, written itself in Python and, although working on CPython, best run under PyPy as installed on step 1.

3. write a (R)Python module including a def target returning the entry point function[2], and call the translator upon your module, like so:

python ./pypy/pypy/translator/goal/translate.py example2.py

I wish getting the translator was more 'packaged' and did not involve getting the whole PyPy source but I hear this is in the works, and it is reasonably easy already. The hardest part is actually figuring the translator is not part of PyPy binary release, and that it's available straight from bitbucket.

[0]: http://pypy.org/download.html

[1]: https://bitbucket.org/pypy/pypy/get/release-1.9.tar.bz2

[2]: http://morepypy.blogspot.fr/2011/04/tutorial-writing-interpreter-with-pypy.html