Mailman 3 February 2020 - pypy-dev

PyPy Winter Sprint + cpyext
by Stefan Beyer Dec. 21, 2022

Dec. 21, 2022

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

We have officially moved to foss.heptapod.net/pypy
by Matti Picus Sept. 1, 2020

Sept. 1, 2020

As reported in the recent blog post https://morepypy.blogspot.com/2020/02/pypy-and-cffi-have-moved-to-heptapod.…, please do not add content to bitbucket.org/pypy or any of the repos there. From now on use https://foss.heptapod.net/pypy/pypy. The repos will continue to live on bitbucket until May 31, and we are still hosting our wiki and downloads there, but activity should move to the new instance. Anyone can open an issue, but in order to commit (as explained in the previous mail) you will need permissions on the repo. The FOSS heptapod instance does not support personal forks, so for now PRs will be branches (heptapod recommends topic branches but some of us are not convinced) on the main repo. Also take a look at the facelift on www.pypy.org. Matti

3 2

Error running Idle
by Jerry Spicklemire Feb. 28, 2020

Feb. 28, 2020

The error below, once fixed, led to a series of errors in other libs. I gave up, deleted PyPy, installed newer version, same thing. No I don't edit in Idle, but I do use it for a few tasks when it comes handy. C:\>C:\Python\PyPy27-32\lib-python\2.7\idlelib\idle.py Traceback (most recent call last): File "C:\Python\PyPy27-32\lib-python\2.7\idlelib\idle.py", line 12, in <module> from idlelib.PyShell import main # This is subject to change File "C:\Python\PyPy27-32\lib-python\2.7\idlelib\PyShell.py", line 775 exec code in self.locals ^ SyntaxError: Missing parentheses in call to 'exec'

2 1

Making the most of internal UTF8
by Jerry Spicklemire Feb. 27, 2020

Feb. 27, 2020

Thanks for all the replies. Anto, re: "- some_unicode.encode('utf-8') is essentially for free (because it is already UTF-8 internally) - some_bytes.decode('utf-8') is very cheap (it just needs to check that some_bytes is valid utf-8)" I guess you mean the processing load for such operations will be low. So that's good then. Just wish they would both go away ... Matt, re: "The defaults are generally better for the programming most people do imo." Probably correct, just got spoiled, that's all. Had a glimmer of hope that the need for either would vanish, and wishing someone knew how. Dan, re: "I think you mostly don't want u'foo' in 3.x or b'foo' in 2.x" Actually, I don't want either, anywhere. If UTF8 is used internally, and ASCII is already UTF8, then it is all UTF8, so ... Sigh ... Thanks anyhow, Jerry S.

2 1

Making the most of internal UTF8
by Jerry Spicklemire Feb. 26, 2020

Feb. 26, 2020

Is there a tutorial about how to best take advantage of PyPy's internal UTF8? The docs say the PyPy now uses UTF8 internally to represent unicode. So, for an old codger, that sounds like were are back to a point where ASCII characters just act normally again, like in Python v.2, since ASCII IS UTF8. In other words, within the range of ASCII characters, the UTF8 representation is identical to the ASCII representation. So, does that mean we can put the 'u' and 'b' prefix nightmares behind us? It would help some diehards finally make the switch to v.3.X, in spite of the bad taste that lingers from early attempts. There is a universe of v.2.X code out there, in production, and something like this would go a long way toward motivating folks so go ahead and update. The fewer the barriers, the more likely the movement. Oh, and incidentally, it would help promote the use of PyPy, as well ... Thanks! Jerry S.

5 4

Help needed: are you running windows with a non-ascii interface?
by Matti Picus Feb. 26, 2020

Feb. 26, 2020

Someone on stackoverflow asked why PyPy cannot run pandas. Here is the error, reformatted from the garbled original: https://gist.github.com/mattip/374e8ba49e2dd2e2b0d5c46a5cd612ed While there was an off-by-one error with the conversion when building time.tzname from the OS c call, I think the issue might be deeper, and related to this still-open cpython bug https://bugs.python.org/issue16322 where non-ascii tznames are a mess to decode. Could someone with a non-ascii (russian, chinese, czech, french, ...) interface in windows - check what pypy3 returns for time.tzname? There is no code to decode it, so it is probably a sting of bytes. What encoding is it in? - try to reproduce the pandas fail on pypy3 (you will need a compiler and a fair amount of time) - see if 6569684f0955 (available after tonight's build on downloads) fixes pandas? Thanks, Matti

2 2

bitbucket.org/pypy/pypy is now in readonly status while we transition to foss.heptapod.net/pypy/pypy
by Matti Picus Feb. 12, 2020

Feb. 12, 2020

Feb 12 is today. We have begun importing the pypy repos to heptapod. I have changed the status of pypy/pypy to readonly during the import, in the hopes that all goes well. Please change your repo push location to foss.heptapod.net/pypy/pypy. Anyone who wants admin status on the new repos can ask me, Armin, or Carl once you create a user on the heptapod instance. If you cannot log in with your bitbucket credentials using Atlassian OAuth, you can create an email login, go to your profile (upper right corner), go to edit profile (pencil in upper right corner), go to "Account" settings, and "Connect to the bucket symbol (not the "bitbucket import" one). Thanks, Matti

1 0

>>>
by René Dudfield Feb. 11, 2020

Feb. 11, 2020

In [1]: >>>> " ".join("abcdef") ...: 'a b c d e f' ...: File "<ipython-input-1-61654c559afe>", line 1 >>>> " ".join("abcdef") ^ SyntaxError: invalid syntax Anyone know the magic spell to change the repl to 3 arrows? cheerio,

4 4

Moving PyPy to https://foss.heptapod.net
by Matti Picus Feb. 7, 2020

Feb. 7, 2020

I would like to propose we move off bitbucket and onto https://foss.heptapod.net. I have opened an issue to request the hosting https://foss.heptapod.net/heptapod/foss.heptapod.net/issues/11. As part of the process, we need to - review the heptapod workflow https://heptapod.net/pages/faq.html#workflow, which - changes our default workflow to "Publishing is restricted to project masters" (I think that means only project masters can push/merge to published branches, but am not sure about the terminology), however we could override that - disallows personal forks on the instance - add an as-yet-undefined logo and link to Clever Cloud and Octobus in our documentation and website - decide which repos to abandon. On the issue above I proposed transferring only a subset of our bitbucket repos, please make sure your favorite is included If I don't hear any dissent by Feb 12 (one week from now) I will move forward with this process. As soon as the repos are copied, I will start to close the bitbucket instances for new contributions: - block changes to the active branches (default, py3.6, py3.7 of pypy, and the HEAD branch of the other repos); any new contributions will have to be done via the heptapod instance - add a notice to the issue tracker that new issues should be done on heptapod - change the links for the buildbot master, documentation, and website to point to the new locations Things that still need resolution before bitbucket closes in May: - what to do about downloads? It is not clear that the gitlab instance has a place for artifacts. Assume we find a solution, how far back do we want to keep versions? - what to do about the wiki https://foss.heptapod.net/heptapod/foss.heptapod.net/issues/14 The CFFI repo will also move in much the same way as the others: transition on Feb 12 and block new contributions on bitbucket soon after. What else have I not thought of? Matti

6 11