Mailman 3 July 2019 - pypy-dev

PyPy Winter Sprint + cpyext
by Stefan Beyer 21 Dec '22

21 Dec '22

Hey everyone! Those of you who attended or followed one of the last two winter sprints in Leysin might know me, the others probably won't. I'm (still) a Master's student writing my thesis on PyPy's current issue with cross-heap cycles when using cpyext. The main point is, that they are not collected and stay around as floating garbage, even if they are not reachable any more. Correct me if I'm wrong, but I didn't notice anyone else working on that topic (and/or committing something) since I've picked it up two years ago (yeah, I know, that long ago...). I saw that you would be working on "cpyext performance and completeness" during the current winter sprint this week and thought that this might also concern my thesis. So I thought I'll give you an update. I recently pushed my current (non-optimized, breaking-some-tests, but more or less working) implementation of the "CPython-style" GC-extension for cpyext. It is still in an early stage and not all cases (legacy and non-legacy-finalizers, weakrefs) are handled. However, I picked up some pace during the last couple of weeks and I'm determined to finish this implementation during the following weeks (some quirks with the tests have been haunting me, but I think I figured most of them out by now). After that, I will implement a second alternative implementation (to compare to, mostly for the sake of my thesis), which will take some more time. I also added a couple of fancy test cases (the so called "dot-tests"), so that we can test complex object graphs a little bit easier (and also because it was kind of cool to have another language inside PyPy/RPython, even if it was only for the tests...), with more test cases to come (the current ones are a bit messy). None of the new changes concerning low-latency applications are currently integrated, but that should not be too hard. I guess it won't make much sense for me to join you at this year's winter sprint, especially as I won't be able to get there before Thursday, but I might be able to join you over the IRC channel (or some other form of communication if you like). If there is anything that is worth discussing please let me know! Also feel free to comment on my code, but beware that I might change some things once I try to do some optimizations (probably not many, but at least fix the worst issues) and make it a little bit more readable. You can find my code on the cpyext-gc-cycle branch.<https://bitbucket.org/pypy/pypy/commits/branch/cpyext-gc-cycle> Looking forward to hearing from you! Greetings, Stefan

2 2

better line number information in PyPy3
by Carl Friedrich Bolz 08 Aug '19

08 Aug '19

Hi all, This is a discussion mail about improving the traceback line number quality in PyPy3. Some context: CPython has started supporting negative line number offset from one bytecode to the next in its lnotab encoding, see here: https://bugs.python.org/issue26107 https://github.com/python/cpython/commit/f3914eb16d2#diff-cb296cc5109f5640f… (Please don't ask me why not a single test was added for this new feature.) However, the support is so far only theoretically possible, the Python 3.7/3.8 bytecode compiler does not seem to make use of the feature. Negative line number jumps occur quite regularly with continuation lines, eg like this: def foobar(a, b): return "" + (1, a, b, 2 ) If you call this function, the traceback will contain this line: File "x.py", line 5, in foobar 2 TypeError: can only concatenate str (not "tuple") to str Which is obviously misleading. A slightly more realistic example are function decorators. There, the execution order is regularly "backwards": first the function definition is executed, then the individual decorators are run. There is currently a hack to sometimes leave the line number on the line of the first decorator, leading to confusing tracebacks. Example: def works(f): return f def broken(f): assert 0 @works @broken @works def g(): pass Running this, you'll get the following traceback: Traceback (most recent call last): File "y.py", line 9, in <module> @works File "y.py", line 5, in broken assert 0 AssertionError Pointing you again to the wrong line. We could fix this problem rather easily by removing the code that prevents the bytecode compiler from emitting negative line number offsets. Should I implement this? Advantages: - A lot less confusing tracebacks in real-world cases Disadvantages: - Different behavior from CPython (but arguably more correct) - Tracing tools could potentially be confused - Potentially larger lnotab strings due to more jumping around Cheers, Carl Friedrich

2 1

Python 2 vs Python 3 again, and a 2.x-only dependency
by Dan Stromberg 01 Aug '19

01 Aug '19

What is Pypy planning to do with Python 2.x, now that many packages on Pypi are dropping Python 2.x support? EG, I believe Pypy caters to Scientific Computing, but with Numpy dropping Python 2.x support, will Pypy3 become the more relevant version of Pypy? Will Numpypy be revived? Will there be a pypypi or something similar-to-but-different-from pypi just for pypy? Will 2.x in Pypy become mostly relevant for RPython, and not most developer projects written in Python that use Pypy? I'm asking mostly because I have a large, complex dependency that isn't planning to move to Python 3.x, and I'm wondering if Pypy 2.x might be what we need to keep that code alive. But with Numpy and other dependencies dropping 2.x, that might not be enough. Thanks for Pypy, BTW. I really like it a lot.

8 9

Importing error in pypy
by Nabil Memon 29 Jul '19

29 Jul '19

Hi Dears, I am currently using pypy(pypy-7.0.0-linux_x86_64-portable) and I am facing some issues using it. I installed pip, cython and numpy using commands: $ ./pypy-xxx/bin/pypy -m ensurepip $ ./pypy-xxx/bin/pip install cython numpy After that, I installed one package *"pysubnettree" *thorough pypy's pip. While importing SubnetTree class, I get segmentation fault. It works completely file with python2.7. *test.py:* import SubnetTree Here are some logs that I collected using pypy's falthandler tool. ======================================================================================== Fatal Python error: Segmentation fault Stack (most recent call first, approximate line numbers): File "/root/pypy_7/pypy-7.0.0-linux_x86_64-portable/site-packages/SubnetTree.py", line 13 in swig_import_helper File "/root/pypy_7/pypy-7.0.0-linux_x86_64-portable/site-packages/SubnetTree.py", line 11 in <module> File "test.py", line 1 in <module> File "<builtin>/app_main.py", line 767 in run_it File "<builtin>/app_main.py", line 78 in run_toplevel File "<builtin>/app_main.py", line 568 in run_command_line File "<builtin>/app_main.py", line 848 in entry_point Segmentation fault ========================================================================================= I tried to debug it further, it seems like segfault is observed while loading *(.so)* file using python's inbuild module *imp.load_module('_SubnetTree', fp, pathname, description).* It would be a great help if you can throw some light on this. Thanks and Regards, Nabil

2 5

Mercurial mini-sprint in Leipzig / possible PyPy sprint around that time?
by Manuel Jacob 24 Jul '19

24 Jul '19

Hi, Although this mail is a bit off-topic, I decided to send it to the PyPy mailing list as well. PyPy is one of the bigger open source projects using Mercurial. This increases the chance that there is some overlap, especially considering that we want to improve the hosting and contribution situation ourselves. Also, there might be an opportunity to organize a PyPy sprint around the same time. The time of the Mercurial sprint is not yet fixed and when it is, it might already be too late to organize a PyPy sprint, but let’s see. Here’s the mail I've sent to the Mercurial mailing list: In addition to the sprints that are hosted about every two minor releases, the Mercurial community organizes so called "mini-sprints" in irregular intervals. I attended the mini-sprint in April in Paris and I liked the experience, so I offered to organize one in Leipzig. This email is to gather information about potential participants and their time preferences. So what's the goal of the mini-sprint? It's an opportunity for existing developers to collaborate in person. But even more important, it's a chance for mere users to become contributors. So no matter whether you are a long-term contributor or someone wanting to start hacking on Mercurial, you will be welcome. The sprint will be 2-4 days long, depending on demand. For us, some time in August would be ideal. The location will be an office in Leipzig, which is easily reachable by train. For example, from Paris it's about 8h for about 60€ – 120€. From Frankfurt airport it's about 3h for about 20€ – 50€. It provides space for around 10 people (more on weekends). Lunch will be provided for a contribution towards expenses. At least 2 sleeping facilities can be provided free of charge. I've created a poll for finding a date: https://framadate.org/jIs6Idj4r8tldJKZ Please spread the word by forwarding the mail or the link to the poll. -Manuel

1 0

Benchmark Pypy Python 3
by Jason Xu 18 Jul '19

18 Jul '19

Hello, https://speed.pypy.org/ is a neat site but I can't find speed benchmarks for Python 3. I recall Python 3 support being in beta or not as optimized. But I am still interested in the results. Also the pypy-dev mailing list link http://codespeak.net/mailman/listinfo/pypy-dev listed at https://speed.pypy.org/about/ is dead. It's not clear to me when the mailing list should be used over the BitBucket issue tracker. Jason

1 0

Pre-release of arm64
by Maciej Fijalkowski 15 Jul '19

15 Jul '19

Hey everyone Apparently it's enough that we put a new image on download.html page for docker to officially have arm64 image of pypy, since that's where they download it from. Is it ok if I put there a pre-release for arm64? Best, Maciej Fijalkowski

2 1

Issue creating virtualenv on new pypy install
by JP B 06 Jul '19

06 Jul '19

Hi, Apologies, new to pypy and virtual envs. Following the instructions for creating virtualenv for pypy from: http://doc.pypy.org/en/latest/install.html#installing-using-virtualenv *So* virtualenv -p /pypy3.6-v7.1.1-linux64/bin/pypy3 pypyenv Note above ^^^ I have changed the documented target file from pypy to *pypy3*, as *pypy* did not exist in the downloaded tar archive *Get Error* The path /pypy3.6-v7.1.1-linux64/bin/pypy3 (from --python=/pypy3.6-v7.1.1-linux64/bin/pypy3) does not exist This is on Ubunto 19.04. Grateful if you can help, many thanks :) JP <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0

Pypy - Numpy and Pandas version compatibility
by JP B 06 Jul '19

06 Jul '19

Hi, New to Pypy, thanks very much! Trying to figure compatible versions of Numpy and Pandas that work with pypy. I dont know if Im reading it correctly, but from the packages I see that pypy is OK with numpy version 1.11.1. This is quite an old release from 2016 I believe. Is this the latest compatible version? http://packages.pypy.org/##numpy For Pandas, shown in red with exception below, can you advise? Many many thanks! JP <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0