10:01 <lesshaste> hi

10:01 <lesshaste> I was sad to see the blog is not being updated any more. The pypy blog updates are a highlight of my year!

10:02 <lesshaste> is pypy development still active?

10:04 <vstinner> lesshaste: hi. the latest commit was less than 1 day ago: https://foss.heptapod.net/pypy/pypy/-/commits/branch/default

10:05 <vstinner> lesshaste: yes, the development is still active :)

10:05 <lesshaste> aha! :)

10:05 <lesshaste> and phew

10:05 <vstinner> lesshaste: the latest release was in May, 4 months ago: https://www.pypy.org/blog/

10:06 <vstinner> lesshaste: are you reading the old blog https://morepypy.blogspot.com/ which says that it moved to https://www.pypy.org/blog/ ?

10:06 <lesshaste> "The 3.8 version of the release contains a beta-quality improvement to the JIT, that we are trying to gain confidence in as well. The improvement tries to better deal with situations where a lot of Python code from the same function is turned into machine code, without any inlining. This kind of situation can occur when Python code gets automatically generated, for example by a string templating engine. Previously, this would

10:06 <lesshaste> prevent compilation of the function and lead to very bad compilation times regardless, leading to much worse performance in such situations than even the interpreter. In the released 3.8 version we solve this problem by chunking up the function into smaller pieces and compiling them step by step."

10:06 <lesshaste> that looks very cool

10:07 <vstinner> lesshaste: ther are also PyPy devs who work on HPy which is also actively developed

10:07 <lesshaste> vstinner, yes. I was usedto more regular updates

10:07 <lesshaste> hpy is even on github!

10:07 <vstinner> i don't know who manages the PyPy releases. i'm not part of the PyPy development

10:08 <lesshaste> vstinner, do you contribute code?

10:08 <vstinner> lesshaste: only to CPython

10:08 <lesshaste> it's an interesting time as pyston and cinder (re)appeared

10:08 <lesshaste> vstinner, oh cool. Which parts do you work on?

10:09 <vstinner> lesshaste: i'm not sure of the future of the cinder project. instagram released the code. that's all

10:09 <vstinner> lesshaste: i'm trying to fix the C API: https://www.python.org/dev/peps/pep-0620/

10:10 <lesshaste> vstinner, actually maybe you can answer my question. I am implementing fast levenshtein distance code in C. If I use ctypes it seems there is an overhead but I am not sure how large

10:10 <lesshaste> I would really like it to be in nanoseconds

10:10 <lesshaste> this seems a relevant question for you :)

10:10 <vstinner> right now, i'm working on a hard problem: convert #define Py_TYPE(obj) (obj->ob_type) to a static inline function: static inline PyTypeObject* Py_TYPE(PyObject *obj) { return obj->ob_type; } ... i don't get a crash on Windows with a debug build, because the compiler doesn't optimize it :-(

10:10 <lesshaste> wow"

10:10 <lesshaste> !

10:11 <vstinner> lesshaste: if you use PyPy, you better have to not use C, but only pure Python, no?

10:11 <lesshaste> vstinner, well that's an option but I was really asking a general cpython question

10:11 <lesshaste> there is cython, cffi and ctypes

10:11 <vstinner> lesshaste: i don't think that #pypy is a good place to ask questions about CPython

10:12 <vstinner> https://vstinner.github.io/c-api-opaque-structures.html <= my latest update article about the C API

10:13 <lesshaste> I think for pypy you are supposed to use cffi

10:14 <vstinner> lesshaste: you _can_ use cffi, but unless pure Python code is way too slow, you should "start" with Python if you use PyPy

10:15 <lesshaste> thanks

10:36 <Hodgestar> lesshaste: There is enough HPy already that writing an extension with one function that does "levenshtein(s1, s2)" seems very possible if you feel like playing with early alpha quality things and giving us feed back. I'm not in any way recommending to do this for anything other than fun or curiosity, because HPy is still influx, but it should work (or work with some small additions to HPy).

10:37 <lesshaste> Hodgestar, cool thanks. Can I expect an overhead of less than a microsecond?

10:38 <Hodgestar> lesshaste: The big picture is that on CPython there should be the same amount of overhead as with the existing / old C API and on PyPy and GraalPython there should be less.

10:39 <lesshaste> I wanted something more exact :)

10:46 <vstinner> lesshaste: you should run your own benchmark for that

10:55 <lesshaste> yes