From matti.picus at gmail.com Wed Feb 5 04:59:00 2020 From: matti.picus at gmail.com (Matti Picus) Date: Wed, 5 Feb 2020 11:59:00 +0200 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net Message-ID: 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 From vincent.legoll at gmail.com Wed Feb 5 05:16:27 2020 From: vincent.legoll at gmail.com (Vincent Legoll) Date: Wed, 5 Feb 2020 11:16:27 +0100 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net In-Reply-To: References: Message-ID: Hello, On Wed, Feb 5, 2020 at 10:59 AM Matti Picus wrote: > 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 about all ? maybe on https://archive.org if that's possible. -- Vincent Legoll From armin.rigo at gmail.com Wed Feb 5 17:57:52 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Wed, 5 Feb 2020 23:57:52 +0100 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net In-Reply-To: References: Message-ID: Hi Matti, Thank you for all the organizational work! On Wed, 5 Feb 2020 at 10:59, Matti Picus wrote: > - 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 -1 (who is a project master? do we need the distinction between two levels of membership at all for anything technical?) > - disallows personal forks on the instance -1 (any reason why?) > - 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 I suppose I'm +0.5 on dropping the old and unused repos. We still have them around anyway in the sense that any one of us with a copy can re-publish them somewhere at any point. (See also below.) > - 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 So you mean, we would still be allowed to push into the various repos on bitbucket as long as it is not on these main branches? Unsure why. > - 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? Would it be possible to just keep this on bitbucket and point to it? I understand the idea of stopping all mercurial services, but a priori they won't delete everything else too? If they do, maybe we just need a hack like convert the pypy repo to git on bitbucket (and then never use it). Same for the wiki. And for all our many-years-old dead repos---we can convert them in-place to git if that means they can stay there. Of course all this is assuming we're fine with keeping a few historical things on bitbucket. If you decide you'd prefer to have nothing more to do with bitbucket soon and they should die instead of continuing to get however little publicity we'd continue to give them by doing that, then I would understand too. A bient?t, Armin. From matti.picus at gmail.com Thu Feb 6 01:23:45 2020 From: matti.picus at gmail.com (Matti Picus) Date: Thu, 6 Feb 2020 08:23:45 +0200 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net In-Reply-To: References: Message-ID: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> My comments are interspersed with yours, On 6/2/20 12:57 am, Armin Rigo wrote: > Hi Matti, > > Thank you for all the organizational work! > > On Wed, 5 Feb 2020 at 10:59, Matti Picus wrote: >> - 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 > -1 (who is a project master? do we need the distinction between two > levels of membership at all for anything technical?) > >> - disallows personal forks on the instance > -1 (any reason why?) This is a Octobus decision, so maybe Georges can chime in. My understanding is that because the heptapod offering is on a trial basis, they do not want to open up the possibility for random individuals to open "groups" on the instance. In order to fork a repo, you need a personal "group" as the target. This means that all contributions must be done on the pypy/pypy repo. Their workflow for drive-by contributions is to allow any random user (who logs in via atlassian, github, or heptapos) to push a branch (or topic branch) to the pypy/pypy repo, but only authorized users (they call them "project masters" can merge ("publish") from those branches to the main development branches. We could override this, as explained on the workflow page. > >> - 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 > I suppose I'm +0.5 on dropping the old and unused repos. We still > have them around anyway in the sense that any one of us with a copy > can re-publish them somewhere at any point. (See also below.) > >> - 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 > So you mean, we would still be allowed to push into the various repos > on bitbucket as long as it is not on these main branches? Unsure why. In order to block changes you need to navigate the UI and disallow each branch separately. It is simply too much work. This is all temporary, on May 31 those repos dissapear. > >> - 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? > Would it be possible to just keep this on bitbucket and point to it? > I understand the idea of stopping all mercurial services, but a priori > they won't delete everything else too? If they do, maybe we just need > a hack like convert the pypy repo to git on bitbucket (and then never > use it). Same for the wiki. And for all our many-years-old dead > repos---we can convert them in-place to git if that means they can > stay there. > > Of course all this is assuming we're fine with keeping a few > historical things on bitbucket. If you decide you'd prefer to have > nothing more to do with bitbucket soon and they should die instead of > continuing to get however little publicity we'd continue to give them > by doing that, then I would understand too. In order to stay on bitbucket, we would have to - reame pypy/pypy to pypy/pypy_hg - create a new pypy/pypy using a git repo - transfer the downloads and wiki to the new repo As May 31 gets closer, we will have to decide what is easier: these steps or something else. I am personally done with bitbucket/atlassian. Hosting the downloads should be simple, if we had the bandwidth we could do it on the buildbot master. Perhaps we could ask the PSF if we can upload them to www.pypy.org/downloads/files. Hosting the wiki is a bit more complicated. Perhaps since we never get outside edits anyway we could just incorporate it into the pypy.org website as static pages. > > A bient?t, > > Armin. Matti From mgorny at gentoo.org Thu Feb 6 01:49:25 2020 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Thu, 06 Feb 2020 07:49:25 +0100 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net In-Reply-To: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> References: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> Message-ID: <7b233270d5ab8bb20af3dc5061715dd9339515d7.camel@gentoo.org> On Thu, 2020-02-06 at 08:23 +0200, Matti Picus wrote: > > > - 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? > > Would it be possible to just keep this on bitbucket and point to it? > > I understand the idea of stopping all mercurial services, but a priori > > they won't delete everything else too? If they do, maybe we just need > > a hack like convert the pypy repo to git on bitbucket (and then never > > use it). Same for the wiki. And for all our many-years-old dead > > repos---we can convert them in-place to git if that means they can > > stay there. > > > > Of course all this is assuming we're fine with keeping a few > > historical things on bitbucket. If you decide you'd prefer to have > > nothing more to do with bitbucket soon and they should die instead of > > continuing to get however little publicity we'd continue to give them > > by doing that, then I would understand too. > > In order to stay on bitbucket, we would have to > > - reame pypy/pypy to pypy/pypy_hg > > - create a new pypy/pypy using a git repo > > - transfer the downloads and wiki to the new repo > > As May 31 gets closer, we will have to decide what is easier: these > steps or something else. > Disclaimer: I don't think I've ever contributed a patch, so don't take my opinion as something important. From an outsider's perspective, I think this is a better choice (or even moving to GitHub). I find Mercurial-based workflows cumbersome, to say lightly. If I have a simple fix, I don't want to spend my time trying to figure out how to use Mercurial, which extensions are required to submit contributions sanely and how to make it all work with some site that seems to try to take advantage of bitbucket removing Mercurial support and that I won't probably use for any other project. Many Gentoo developers have always had mixed feelings about using GitHub. However, even partial GitHub support has drastically increased number of contributions. I agree that PyPy's not the same kind of project -- I suppose there's a different proportional between dedicated long-term contributors and drive-by contributions. Nevertheless, you may really want to consider if using a more common tooling/platform won't result in less people resigning from contributing because it seems too hard. Finally, we're living in times where people start caring about their personal data. Even if it's not explicitly personal, people have their doubts about registering on yet another site that's likely going to track them in ways unimaginable. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From yury at shurup.com Thu Feb 6 02:03:23 2020 From: yury at shurup.com (Yury V. Zaytsev) Date: Thu, 6 Feb 2020 08:03:23 +0100 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net In-Reply-To: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> References: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> Message-ID: > On 6. Feb 2020, at 07:24, Matti Picus wrote: > > I am personally done with bitbucket/atlassian. Hosting the downloads should be simple, if we had the bandwidth we could do it on the buildbot master. Perhaps we could ask the PSF if we can upload them to www.pypy.org/downloads/files. Hosting the wiki is a bit more complicated. Perhaps since we never get outside edits anyway we could just incorporate it into the pypy.org website as static pages. In as far as downloads are concerned, you could try to apply for an account on the OSU OSL mirroring service - they have been hosting downloads for Midnight Commander for almost for a decade by now, and we?ve been very happy with their service. You just scp stuff in your personal directory and trigger a mirroring script per ssh - it gets propagated to the mirrors and there you go - excellent speed, safe storage. Sent from my iPad From yury at shurup.com Thu Feb 6 02:06:15 2020 From: yury at shurup.com (Yury V. Zaytsev) Date: Thu, 6 Feb 2020 08:06:15 +0100 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net In-Reply-To: <7b233270d5ab8bb20af3dc5061715dd9339515d7.camel@gentoo.org> References: <7b233270d5ab8bb20af3dc5061715dd9339515d7.camel@gentoo.org> Message-ID: <584194BE-EE8B-4582-A718-2AD36BEAC37C@shurup.com> > On 6. Feb 2020, at 07:55, Micha? G?rny wrote: > > Finally, we're living in times where people start caring about their > personal data. Even if it's not explicitly personal, people have their > doubts about registering on yet another site that's likely going to > track them in ways unimaginable. In as far as tracking is concerned, their data is way safer with Heptapod as compared to Microsoft ;-) Sent from my iPad From armin.rigo at gmail.com Thu Feb 6 04:54:03 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Thu, 6 Feb 2020 10:54:03 +0100 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net In-Reply-To: <7b233270d5ab8bb20af3dc5061715dd9339515d7.camel@gentoo.org> References: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> <7b233270d5ab8bb20af3dc5061715dd9339515d7.camel@gentoo.org> Message-ID: Hi Michal, hi all, I reworded the entry at https://doc.pypy.org/en/latest/faq.html#why-doesn-t-pypy-use-git-and-move-to-github to account for our decision to move to Heptapod. A bient?t, Armin From armin.rigo at gmail.com Thu Feb 6 05:03:41 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Thu, 6 Feb 2020 11:03:41 +0100 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net In-Reply-To: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> References: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> Message-ID: Hi Matti, On Thu, 6 Feb 2020 at 07:24, Matti Picus wrote: > >> - disallows personal forks on the instance > > -1 (any reason why?) > > This is a Octobus decision, so maybe Georges can chime in. My > understanding is that because the heptapod offering is on a trial basis, > (...) Yes, that makes sense for now (seen the discussion on IRC too). > In order to block changes you need to navigate the UI and disallow each > branch separately. It is simply too much work. This is all temporary, on > May 31 those repos dissapear. OK. > I am personally done with bitbucket/atlassian. Hosting the downloads > should be simple, if we had the bandwidth we could do it on the buildbot > master. OK too. We certainly have the bandwidth to host all the past files on the buildbot master. For future releases it's unclear; there are 200 GB of downloads of just the py3.6-win32.zip for every release... A bient?t, Armin. From georges.racinet at octobus.net Thu Feb 6 06:13:35 2020 From: georges.racinet at octobus.net (Georges Racinet) Date: Thu, 6 Feb 2020 12:13:35 +0100 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net In-Reply-To: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> References: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> Message-ID: Hi there, I'm Heptapod main maintainer. On 2/6/20 7:23 AM, Matti Picus wrote: >> >>> ??? - disallows personal forks on the instance >> -1? (any reason why?) > > > This is a Octobus decision, so maybe Georges can chime in. Yes, I've just subscribed to that effect. I'll try and answer the different concerns separately. > My understanding is that because the heptapod offering is on a trial > basis, they do not want to open up the possibility for random > individuals to open "groups" on the instance. In order to fork a repo, > you need a personal "group" as the target. This means that all > contributions must be done on the pypy/pypy repo. This is not completely exact. There are two different aspects to it - Personal forks are just not implemented in Heptapod (the software) yet [1]. I've also written a bit in the FAQ [2] about that. As a side note, it's more complicated to implement properly forks and merge requests from them than other lacking features. - It is true that we don't want to make foss.heptapod.net a space where anybody can create repositories, because we don't have infinite capacity (but we hope we can grow) nor enough work force to watch for illegal content at the scale that implies. But that shouldn't apply to personal forks once we have them. > Their workflow for drive-by contributions is to allow any random user > (who logs in via atlassian, github, or heptapos) to push a branch (or > topic branch) to the pypy/pypy repo, but only authorized users (they > call them "project masters" can merge ("publish") from those branches > to the main development branches. We could override this, as explained > on the workflow page. First I should say that "Master" is standard GitLab terminology in the version we're based upon, but has been renamed to "Maintainer" in later versions. It means you have all rights on the repository, except for the like of removal and transfer [3] We also plan to introduce an intermediate role, that could be labelled "Publisher". All of this is indeed backed by the "phases" concept in Mercurial, in which changesets can be "draft" (amendable) or "public" (set in stone) and the fact that topics are additional metadata for draft changesets only. In Heptapod, by default, we enforce that conversely all drafts must have topics. So, the default Heptapod workflow is to grant the Contributor role to people that wish to contribute ? they can push topics and submit merge requests ? whereas full commit rights translate in the Master role. This is explained and motivated in more detail in the FAQ [4] and in the Octobus blog post [5]. An important implication of all this is that it makes activating the evolve extension [6] almost necessary in practice. It's not meant to be mandatory by itself, see "Mutability and Evolution"? in [5], but once a draft changeset has been amended you'd get surprising warnings if you don't have evolve. Note also that open Bitbucket pull requests are imported as topics [7], and that involves amendments. To conclude, we know that the picture is not perfect and that we could make the transition easier and clearer. We're working on improving all of that, but we have lots of things to do, and we need actual user feedback - such as yours - to prioritize them properly. We're listening. Best, PS: I'm considering coming to the next PyPy sprint in Switzerland. [1] https://foss.heptapod.net/heptapod/heptapod/issues/24 [2] https://heptapod.net/pages/faq.html#forks [3] https://docs.gitlab.com/ce/user/permissions.html [4] https://heptapod.net/pages/faq.html#workflow [5] https://octobus.net/blog/2019-09-04-heptapod-workflow.html [6] https://pypi.org/project/hg-evolve/ and https://www.mercurial-scm.org/doc/evolution/user-guide.html [7] https://foss.heptapod.net/heptapod/heptapod/issues/106 -- Georges Racinet https://octobus.net, https://heptapod.net GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From georges.racinet at octobus.net Thu Feb 6 06:40:47 2020 From: georges.racinet at octobus.net (Georges Racinet) Date: Thu, 6 Feb 2020 12:40:47 +0100 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net In-Reply-To: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> References: <3bf10ab5-870e-327a-b9b7-53a177caf6d6@gmail.com> Message-ID: <6e070b37-4e10-e167-1fd7-85ce8db1d97a@octobus.net> On 2/6/20 7:23 AM, Matti Picus wrote: >> >>> - 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? This is an area of GitLab I've not explored completely yet, but that I'll get acquainted with pretty soon, since Heptapod itself will need to provide packages at some point. >> Would it be possible to just keep this on bitbucket and point to it? >> I understand the idea of stopping all mercurial services, but a priori >> they won't delete everything else too?? If they do, maybe we just need >> a hack like convert the pypy repo to git on bitbucket (and then never >> use it).? Same for the wiki.? And for all our many-years-old dead >> repos---we can convert them in-place to git if that means they can >> stay there. >> >> Of course all this is assuming we're fine with keeping a few >> historical things on bitbucket.? If you decide you'd prefer to have >> nothing more to do with bitbucket soon and they should die instead of >> continuing to get however little publicity we'd continue to give them >> by doing that, then I would understand too. > > In order to stay on bitbucket, we would have to > > - reame pypy/pypy to pypy/pypy_hg > > - create a new pypy/pypy using a git repo > > - transfer the downloads and wiki to the new repo > > As May 31 gets closer, we will have to decide what is easier: these > steps or something else. While it does get closer, I think it's realistic to support wikis in Heptapod before that deadline. > > I am personally done with bitbucket/atlassian. Hosting the downloads > should be simple, if we had the bandwidth we could do it on the > buildbot master. Perhaps we could ask the PSF if we can upload them to > www.pypy.org/downloads/files. Seen from my outsider perspective, it would look great to have the downloads hosted at PSF. > Hosting the wiki is a bit more complicated. Perhaps since we never get > outside edits anyway we could just incorporate it into the pypy.org > website as static pages. You could also import it as a separate repository right now, and then make it a proper wiki once Heptapod supports them. After all, it's backed by a standard Mercurial repository. But I'd suggest to keep it on Bitbucket for a while and make a decision around April, based on where Heptapod stands at that time. Regards, -- Georges Racinet https://octobus.net, https://heptapod.net GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From matti.picus at gmail.com Fri Feb 7 04:59:58 2020 From: matti.picus at gmail.com (Matti Picus) Date: Fri, 7 Feb 2020 11:59:58 +0200 Subject: [pypy-dev] Moving PyPy to https://foss.heptapod.net In-Reply-To: References: Message-ID: <4a9a85bb-7dc6-8e83-5718-fff30cee1b13@gmail.com> On 5/2/20 11:59 am, Matti Picus wrote: > 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 ... > What else have I not thought of? > Here's something I didn't mention: Please make sure you can log in to the instance, preferably using your atlassian login to preserve your identity. This is used to map bitbucket names to the new repo. > Matti > From renesd at gmail.com Sat Feb 8 04:35:06 2020 From: renesd at gmail.com (=?UTF-8?Q?Ren=C3=A9_Dudfield?=) Date: Sat, 8 Feb 2020 10:35:06 +0100 Subject: [pypy-dev] >>> Message-ID: In [1]: >>>> " ".join("abcdef") ...: 'a b c d e f' ...: File "", line 1 >>>> " ".join("abcdef") ^ SyntaxError: invalid syntax Anyone know the magic spell to change the repl to 3 arrows? cheerio, -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Mon Feb 10 20:09:57 2020 From: steve at pearwood.info (Steven D'Aprano) Date: Tue, 11 Feb 2020 12:09:57 +1100 Subject: [pypy-dev] >>> In-Reply-To: References: Message-ID: <20200211010955.GJ8273@ando.pearwood.info> On Sat, Feb 08, 2020 at 10:35:06AM +0100, Ren? Dudfield wrote: > Anyone know the magic spell to change the repl to 3 arrows? Try sys.ps1 -- Steven From luciano at ramalho.org Mon Feb 10 21:03:15 2020 From: luciano at ramalho.org (Luciano Ramalho) Date: Mon, 10 Feb 2020 23:03:15 -0300 Subject: [pypy-dev] >>> In-Reply-To: References: Message-ID: Are you typing those >? Don?t. On Sat, 8 Feb 2020 at 06:35 Ren? Dudfield wrote: > In [1]: >>>> " ".join("abcdef") > ...: 'a b c d e f' > ...: > > > File "", line 1 > >>>> " ".join("abcdef") > ^ > SyntaxError: invalid syntax > > > Anyone know the magic spell to change the repl to 3 arrows? > > > cheerio, > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Tue Feb 11 03:28:41 2020 From: steve at pearwood.info (Steven D'Aprano) Date: Tue, 11 Feb 2020 19:28:41 +1100 Subject: [pypy-dev] >>> In-Reply-To: References: Message-ID: <20200211082840.GK8273@ando.pearwood.info> On Mon, Feb 10, 2020 at 11:03:15PM -0300, Luciano Ramalho wrote: > Are you typing those >? > > Don?t. IPython has a magic %paste command that understands CPython's >>> prompt, but not PyPy's >>>> prompt. https://cmdlinetips.com/2012/12/how-to-paste-code-in-python-interpreter-hint-use-ipython/ -- Steven From matti.picus at gmail.com Tue Feb 11 06:59:31 2020 From: matti.picus at gmail.com (Matti Picus) Date: Tue, 11 Feb 2020 13:59:31 +0200 Subject: [pypy-dev] >>> In-Reply-To: <20200211082840.GK8273@ando.pearwood.info> References: <20200211082840.GK8273@ando.pearwood.info> Message-ID: On 11/2/20 10:28 am, Steven D'Aprano wrote: > On Mon, Feb 10, 2020 at 11:03:15PM -0300, Luciano Ramalho wrote: >> Are you typing those >? >> >> Don?t. > IPython has a magic %paste command that understands CPython's >>> > prompt, but not PyPy's >>>> prompt. > > https://cmdlinetips.com/2012/12/how-to-paste-code-in-python-interpreter-hint-use-ipython/ > You can change the pypy prompt with `sys.ps1 ='>>> '` Otherwise, this is a ipython issue. Their issue tracker is at https://github.com/ipython/ipython/issues/ Matti From matti.picus at gmail.com Wed Feb 12 05:35:12 2020 From: matti.picus at gmail.com (Matti Picus) Date: Wed, 12 Feb 2020 12:35:12 +0200 Subject: [pypy-dev] bitbucket.org/pypy/pypy is now in readonly status while we transition to foss.heptapod.net/pypy/pypy Message-ID: <2d0f8409-faae-dbfc-db6c-614ff1f7795b@gmail.com> 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 From matti.picus at gmail.com Sun Feb 16 13:12:43 2020 From: matti.picus at gmail.com (Matti Picus) Date: Sun, 16 Feb 2020 20:12:43 +0200 Subject: [pypy-dev] We have officially moved to foss.heptapod.net/pypy Message-ID: <8bfdeade-5949-e46b-494b-a3c6721b38e3@gmail.com> As reported in the recent blog post https://morepypy.blogspot.com/2020/02/pypy-and-cffi-have-moved-to-heptapod.html, 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 From anto.cuni at gmail.com Mon Feb 17 08:17:40 2020 From: anto.cuni at gmail.com (Antonio Cuni) Date: Mon, 17 Feb 2020 14:17:40 +0100 Subject: [pypy-dev] We have officially moved to foss.heptapod.net/pypy In-Reply-To: <8bfdeade-5949-e46b-494b-a3c6721b38e3@gmail.com> References: <8bfdeade-5949-e46b-494b-a3c6721b38e3@gmail.com> Message-ID: Thank you for having handled all of this, Matti! :) On Sun, Feb 16, 2020 at 7:13 PM Matti Picus wrote: > As reported in the recent blog post > > https://morepypy.blogspot.com/2020/02/pypy-and-cffi-have-moved-to-heptapod.html, > > 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 > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Wed Feb 26 05:59:03 2020 From: matti.picus at gmail.com (Matti Picus) Date: Wed, 26 Feb 2020 12:59:03 +0200 Subject: [pypy-dev] Help needed: are you running windows with a non-ascii interface? Message-ID: <7b52baf8-55e7-4516-22e7-bbcf5884b675@gmail.com> 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 From armin.rigo at gmail.com Wed Feb 26 08:28:09 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Wed, 26 Feb 2020 14:28:09 +0100 Subject: [pypy-dev] Help needed: are you running windows with a non-ascii interface? In-Reply-To: <7b52baf8-55e7-4516-22e7-bbcf5884b675@gmail.com> References: <7b52baf8-55e7-4516-22e7-bbcf5884b675@gmail.com> Message-ID: Hi Matti, On Wed, 26 Feb 2020 at 11:59, Matti Picus wrote: > - 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? On a french Windows I get, in CPython 3.6, a tuple of two unicodes that seem correct; and on PyPy3 I get instead a tuple of two unicodes that are very incorrect. CPython3.6 (first line) versus PyPy3.6: ('Europe de l\x92Ouest', 'Europe de l\x92Ouest (heure d\x92?t?)') ('Europe de l\Ufffff44fuest (heure d\Ufffff4e9t\u79c0', 'Europe de l\Ufffff44fuest (heure d\Ufffff4e9t\x39') In particular the first escaped character \Ufffff44f really should be two characters, '\x92O', and there is similar mangling later. Also the first of the two unicodes is much shorter on CPython3. Finally, the very last character is rendered as '\x39' but I have no clue why it is even rendered as '\x39' instead of just the ascii '9'. So yes, we have more than one bug here. Armin From armin.rigo at gmail.com Wed Feb 26 08:33:18 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Wed, 26 Feb 2020 14:33:18 +0100 Subject: [pypy-dev] Help needed: are you running windows with a non-ascii interface? In-Reply-To: References: <7b52baf8-55e7-4516-22e7-bbcf5884b675@gmail.com> Message-ID: Hi again, On Wed, 26 Feb 2020 at 14:28, Armin Rigo wrote: > In particular the first escaped character \Ufffff44f really should be > two characters, '\x92O', and there is similar mangling later. Also > the first of the two unicodes is much shorter on CPython3. Finally, > the very last character is rendered as '\x39' but I have no clue why > it is even rendered as '\x39' instead of just the ascii '9'. > > So yes, we have more than one bug here. Uh, in fact time.tzname[0] == time.tzname[1] and if I print separately time.tzname[0] and time.tzname[1] I get twice the same thing: 'Europe de l\Ufffff44fuest (heure d\Ufffff4e9t\u79c0' But if I print the tuple, or manually (time.tzname[0], time.tzname[1]) or even (time.tzname[0], time.tzname[0]), then I see the result above where the second item is repr'ed differently from the first one. Armin From jspicklemire at gmail.com Wed Feb 26 10:08:49 2020 From: jspicklemire at gmail.com (Jerry Spicklemire) Date: Wed, 26 Feb 2020 09:08:49 -0600 Subject: [pypy-dev] Making the most of internal UTF8 Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.rigo at gmail.com Wed Feb 26 10:46:28 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Wed, 26 Feb 2020 16:46:28 +0100 Subject: [pypy-dev] Making the most of internal UTF8 In-Reply-To: References: Message-ID: Hi Jerry, On Wed, 26 Feb 2020 at 16:09, Jerry Spicklemire wrote: > Is there a tutorial about how to best take advantage of PyPy's internal UTF8? For best or for worse, this is only an internal feature. It has no effect for the end user. In particular, Python programs written for PyPy3.6 and for CPython3.6 should work identically. The fact that it uses internally utf-8 is not visible to the Python program---otherwise, it would never be cross-compatible. A bient?t, Armin. From anto.cuni at gmail.com Wed Feb 26 12:32:28 2020 From: anto.cuni at gmail.com (Antonio Cuni) Date: Wed, 26 Feb 2020 18:32:28 +0100 Subject: [pypy-dev] Making the most of internal UTF8 In-Reply-To: References: Message-ID: To expand Armin's answer, the two most "visible" effects for end users are: - some_unicode.encode('utf-8') is essentially for free (because it is already UTF-8 internally) - some_bytes.decode('utf-8') is very chep (it just needs to check that some_bytes is valid utf-8) ciao, Anto On Wed, Feb 26, 2020 at 4:47 PM Armin Rigo wrote: > Hi Jerry, > > On Wed, 26 Feb 2020 at 16:09, Jerry Spicklemire > wrote: > > Is there a tutorial about how to best take advantage of PyPy's internal > UTF8? > > For best or for worse, this is only an internal feature. It has no > effect for the end user. In particular, Python programs written for > PyPy3.6 and for CPython3.6 should work identically. The fact that it > uses internally utf-8 is not visible to the Python > program---otherwise, it would never be cross-compatible. > > > A bient?t, > > Armin. > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at vazor.com Wed Feb 26 13:32:12 2020 From: matt at vazor.com (Matt Billenstein) Date: Wed, 26 Feb 2020 10:32:12 -0800 Subject: [pypy-dev] Making the most of internal UTF8 In-Reply-To: References: Message-ID: <20200226183212.GA1270@Zed.localdomain> On Wed, Feb 26, 2020 at 09:08:49AM -0600, Jerry Spicklemire wrote: > 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. You can think of 'u' as being the default in python3 where 'b' was the default in python2 (not ascii) - but most stdlib functions would accept bytes as strings. So in python3, you don't need 'u' and you only occasionally need 'b' or to convert between the two. The defaults are generally better for the programming most people do imo. m -- Matt Billenstein matt at vazor.com http://www.vazor.com/ From drsalists at gmail.com Wed Feb 26 13:48:32 2020 From: drsalists at gmail.com (Dan Stromberg) Date: Wed, 26 Feb 2020 10:48:32 -0800 Subject: [pypy-dev] Making the most of internal UTF8 In-Reply-To: <20200226183212.GA1270@Zed.localdomain> References: <20200226183212.GA1270@Zed.localdomain> Message-ID: On Wed, Feb 26, 2020 at 10:41 AM Matt Billenstein via pypy-dev < pypy-dev at python.org> wrote: > You can think of 'u' as being the default in python3 where 'b' was the > default in python2 (not ascii) - but most stdlib functions would accept > bytes as strings. > > So in python3, you don't need 'u' and you only occasionally need 'b' or > to convert between the two. The defaults are generally better for the > programming most people do imo. > I think you mostly don't want u'foo' in 3.x or b'foo' in 2.x - except when you're writing code intended to run on both. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspicklemire at gmail.com Thu Feb 27 12:54:45 2020 From: jspicklemire at gmail.com (Jerry Spicklemire) Date: Thu, 27 Feb 2020 11:54:45 -0600 Subject: [pypy-dev] Making the most of internal UTF8 Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at vazor.com Thu Feb 27 13:10:35 2020 From: matt at vazor.com (Matt Billenstein) Date: Thu, 27 Feb 2020 10:10:35 -0800 Subject: [pypy-dev] Making the most of internal UTF8 In-Reply-To: References: Message-ID: <20200227181035.GB1270@Zed.localdomain> On Thu, Feb 27, 2020 at 11:54:45AM -0600, Jerry Spicklemire wrote: > Thanks for all the replies. > 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 ... If you're not writing libs, you only need b'' in Python3 -- bytes and binary data is not utf8; you need bytes for files, networks, compression, etc and in Python3 you'll get errors where you try to use strings in places that need bytes... I think the time where you could work just in ascii is pretty much gone -- even in the US, people use emoji all over the place now, and you can only store such things using some form of unicode. m -- Matt Billenstein matt at vazor.com http://www.vazor.com/ From jspicklemire at gmail.com Fri Feb 28 10:56:42 2020 From: jspicklemire at gmail.com (Jerry Spicklemire) Date: Fri, 28 Feb 2020 09:56:42 -0600 Subject: [pypy-dev] Error running Idle Message-ID: 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 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' -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.rigo at gmail.com Fri Feb 28 12:12:03 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Fri, 28 Feb 2020 18:12:03 +0100 Subject: [pypy-dev] Error running Idle In-Reply-To: References: Message-ID: Hi Jerry, On Fri, 28 Feb 2020 at 16:56, Jerry Spicklemire wrote: > exec code in self.locals > ^ > SyntaxError: Missing parentheses in call to 'exec' This error comes from Python 3; it's not a syntax error in Python 2. When you're executing a Python file directly, it picks whatever Python interpreter is associated with .py files in your Windows. It doesn't matter that the .py file is inside a specific directory like PyPy27-32. In your case it is picking up either CPython 3.x or PyPy3.6, whichever is installed. To run a .py file with a specific version of Python, use a command like "c:\python\pypy27-32\pypy.exe c:\path\to\file.py". A bient?t, Armin.