Mailman 3 September 2011 - pypy-dev

Re: [pypy-dev] bounties for pypy
by Laura Creighton 16 Sep '11

16 Sep '11

>The idea was also to possibly attract new developers ... for example, if >there would be "10 days in money" for adapting py2exe, I am sure many wou >ld >jump to solve this puzzle. This is sort of a bad example. Because py2exe embeds CPython, and we wouldn't want to do that. So what we would probably want to do is to make some general tool that willmake a windows binary, or a mac one, and get rid of the need for bzfreeze and friends. So now you are looking at a general embedding solution, and that is more than 10 days worth of work. But I get the idea. <snip> >> my dream was of a trustee service: after somebody commits to do the wor >k, >the pledgers have to pay to a trustee. then the work is done. then the >trustee pays the worker. This is one of the things I want to talk with fundedbyme about. But having an explicit trustee is a new idea. I think the pypy core developers are already rather well trusted in this community, but this may be important to new developers who aren't as well known. And it handles the problem' of 'I got sick and cannot do this any more' more gracefully than other solutions. >Hmmm.... a structure could be: > >- service provider does the technical stuff, as in: > # website > # collect pledges > # handle project description > # collect money > # distribute money after feature completion fundedbyme has sort of indicated an interst in doing this (except they were talking about distribution before, and I was leaving project description to the project, not outsiders). I will follow up on this when I get back home to Sweden. >- PSF / pypy-foundation / whateverfoundation provides the trust > >Thanks for confirming the need for such a thing! > >Harald Thanks once again for seeing a marketing solution that nerds like us often miss. Laura

6 12

Detecting numpy vs micronumpy
by Peter Cock 16 Sep '11

16 Sep '11

Dear all, I tried asking this on the NumPy mailing list, but realise here is more likely: http://mail.scipy.org/pipermail/numpy-discussion/2011-September/058439.html How should a python script (e.g. setup.py) distinguish between real numpy and micronumpy? Or should I instead be looking to distinguish PyPy versus another Python implementation? Thanks, Peter

3 5

Separate building of the C source files
by Elad Lahav 16 Sep '11

16 Sep '11

Hello, I am trying to build Pypy for an embedded platform, with its own build system. For that purpose, I would like to have the translation process run on a Linux/x86 box, generating the C source files, and then have the platform's own build system do C compilation and linking. With the 1.6 sources, I used the following command: $ python translate.py --opt-jit --source targetpypystandalone.py The source files were created under the /tmp directory. The first thing I am missing, though, is a makefile. Looking at the translator sources, it appears as though a GNU make-compatible makefile should have been created, but I cannot find one. Is such a makefile written to disk as part of the source generation stage, or does the translator use a different mechanism? Instead of using a makefile, I also tried manual compilation of the files under /tmp/usession-unknown-NUMBER/testing_1. The linking stage (with -lffi -lm -ldl -lpthread) fails with unresolved symbols, which I do not recognize from any of the common libraries. Nor could I find any documentation of the post-translation build process. Can anyone describe the C compilation and linking commands, or point me to the right place in the code/documentation? Thanks, --Elad

2 3

Re: [pypy-dev] PyPy support for Python 3 -- request for comments
by Zach Kelling 14 Sep '11

14 Sep '11

I'd gladly donate if you throw your proposal for funding up on kickstarter.com, I'd not be surprised if there were quite a few other people willing to donate to get Python 3 supported. -- Zach Kelling http://twitter.com/zeekay

5 4

PyPy support for Python 3 -- request for comments
by Yoann 13 Sep '11

13 Sep '11

Hello, We just launched a website that can help you with the funding process : https://elveos.org Elveos is a website created specifically to fund open source software. Instead of using a simple donation box, it offers a fully functional fundraising tool, with capacity to track the progress, to comment, to check who made contributions ... Of course this come at a cost but it will also be a huge timesaver on your side as you will just have to create the fundraising (and advertise for it) and we'll take care of everything else, including the payment issues. We also provide you with tools helping you communicate on the campaign such as small buttons than can easily be inserted into a blog. As you can imagine, working with pypy would be an important project for us, and we'll be more than happy to help you using elveos, and can develop new functionalities if you see fit. We created an example on pre-production website of what your fundraising campaign could look like : https://test.elveos.org/features/635/description (you have to accept the certificate for the test server). We'll read answers on the list, but if you want to discuss directly with us, you can find on the #elveos irc channel on the freenode.net server. P.S: A few more technical details : * We are based in France and use euro as our operating currency. We accept payment from most currency though. * We accept payments by credit cards or wire transfers (wire transfers didn't make it on live yet, they're coming soon) Regards, Yoann for the elveos team

3 3

Re: [pypy-dev] Gothenburg Sprint Dates
by Laura Creighton 13 Sep '11

13 Sep '11

Fscons has asked for somebody to speak on PyPy. So far I have said 'yes' and nothing specific about the content. Laura

1 0

PyPy support for Python 3 -- request for comments
by Yoann Plénet 13 Sep '11

13 Sep '11

Hello, We just launched a website that can help you with the funding process : https://elveos.org Elveos is a website created specifically to fund open source software. Instead of using a simple donation box, it offers a fully functional fundraising tool, with capacity to track the progress, to comment, to check who made contributions ... Of course this come at a cost but it will also be a huge timesaver on your side as you will just have to create the fundraising (and advertise for it) and we'll take care of everything else, including the payment issues. We also provide you with tools helping you communicate on the campaign such as small buttons than can easily be inserted into a blog. As you can imagine, working with pypy would be an important project for us, and we'll be more than happy to help you using elveos, and can develop new functionalities if you see fit. We created an example on pre-production website of what your fundraising campaign could look like : https://test.elveos.org/features/635/description (you have to accept the certificate for the test server). We'll read answers on the list, but if you want to discuss directly with us, you can find on the #elveos irc channel on the freenode.net server. P.S: A few more technical details : * We are based in France and use euro as our operating currency. We accept payment from most currency though. * We accept payments by credit cards or wire transfers (wire transfers didn't make it on live yet, they're coming soon) Regards, Yoann for the elveos team

1 0

Re: [pypy-dev] PyPy support for Python 3 -- request for comments
by Serhat Sevki Dincer 12 Sep '11

12 Sep '11

> From: Dirkjan Ochtman <dirkjan(a)ochtman.nl> > To: Antonio Cuni <anto.cuni(a)gmail.com> > Date: Mon, 12 Sep 2011 22:44:10 +0200 > Subject: Re: [pypy-dev] PyPy support for Python 3 -- request for comments > Or at the very least state elsewhere how you came up with the > financial numbers... This may also be conducive for companies that > would rather loan you a capable engineer for a few months, perhaps? > > One textual nit: "Note that the distinction between sub-steps 1.1 and > 1.2 is blur, and it": blur -> blurry. > > In general, great idea to take a whack at putting numbers on this, > helping the community understand how much work this project is. http://www.ohloh.net/p/pypy is a reference for current work's value, I guess. Must be useful for the upcoming estimate..

2 1

PyPy support for Python 3 -- request for comments
by Antonio Cuni 12 Sep '11

12 Sep '11

Hello pypy-dev, in the past weeks, I and the other core developers have talked a lot about supporting Python 3 in PyPy. The task is huge and it's unlikely that it will be completed shortly based only on volunteer work, so we came up with the following proposal, which splits the work into several steps and sub-steps, togheter with an estimate of how much money is needed to complete each one. The plan is to publish the proposal on the blog, and publicly ask for donations, with the hope to collect enough to cover the whole work. However, before putting it on the blog we would like to ask for your comments/thoughts about it. Any feedback will be appreciated! Thank you, Antonio (on the behalf of the PyPy team) Python 3 on PyPy ================= The release of Python 3 has been a major undertaking for the Python community, both technically and socially. So far PyPy implements only the version 2 of the Python language, which creates a very dangerous potential for a community split. We believe that by supporting both versions of the language we will help to fill the gap. This project should help both the part of the Python community which is reluctant to use PyPy because it does not support Python 3, and the part which is reluctant to move to Python 3 because they are already PyPy users. However, porting PyPy to Python 3 requires a lot of work, and it will take a long time before we can complete it by relying only on volunteer work. Thus, we are asking the community to help with funding the necessary work, to make it happen faster. High level description ----------------------- The goal of this project is to write an interpreter that interprets version 3 of Python language. To be precise we would aim at having Python 3.2 interpreter together in the same codebase as python 2.7 one. At the end of the project, it will be possible to decide at translation time whether to build an interpreter which supports Python 2.7 or Python 3.2 and both versions will be nightly tested and available from nightly builds. The focus of this project is on compatibility, not performance. In particular, it might be possible that the resulting Python 3 interpreter will be slower than the Python 2 one. If needed, optimizing and making it more JIT friendly will be the scope of a separate project. Step 1: core language ---------------------- In this step, we implement all the changes to the core language, i.e. everything which is not in the extension modules. This includes, but it is not necessarily limited to the following items, which are split into two big areas: * **Sub-step 1.1**: string vs unicode and I/O: - adapt the existing testing infrastructure to support running Python 3 code - string vs bytes: the interpreter uses unicode strings everywhere. - the ``print`` function - ``open`` is now an alias for ``io.open``, removal of the old file type. - string formatting (for the part which is not already implemented in Python 2.7) - the _io module (for the part which is not already implemented in Python 2.7) - syntactic changes to make ``io.py`` importable (in particular: ``metaclass=...`` in class declarations) - **Estimate cost**: 35.000 $ * **Sub-step 1.2**: other syntactic changes, builtin types and functions, exceptions: - views and iterators instead of lists (e.g., ``dict.items()``, ``map``, ``range`` & co.) - new rules for ordering comparisons - removal of old-style classes - int/long unification - function annotations - smaller syntax changes, such as keyword-only arguments, ``nonlocal``, extended iterable unpacking, set literals, dict and set comprehension, etc. - changes to exceptions: ``__traceback__`` attribute, chained exceptions, ``del e`` at the end of the except block, etc. - changes to builtins: ``super``, ``input``, ``next()``, etc. - improved ``with`` statement - **Estimate cost**: 25.000 $ Note that the distinction between sub-steps 1.1 and 1.2 is blur, and it might be possible that during the development we will decide to move items between the two sub-steps, as needed. For more information, look at the various "What's new" documents: - http://docs.python.org/py3k/whatsnew/3.0.html - http://docs.python.org/py3k/whatsnew/3.1.html - http://docs.python.org/py3k/whatsnew/3.2.html **Total estimate cost**: 60.000 $ Step 2: extension modules -------------------------- In this step, we implement all the changes to the extension modules which are written in C in CPython. This includes, but it is not necessarily limited to: - ``collections``, ``gzip``, ``bz2``, ``decimal``, ``itertools``, ``re``, ``functools``, ``pickle``, ``_elementtree``, ``math``, etc. **Estimate cost**: this is hard to do at this point, we will be able to give a more precise estimate as soon as Step 1 is completed. As a reference, it should be possible to complete it with 35.000 $ Step 3: cpyext -------------- The ``cpyext`` module allows to load CPython C extensions in PyPy. Since the C API changed a lot between Python 2.7 and Python 3.2, ``cpyext`` will not work out of the box in the Python 3 PyPy interpreter. In this step, we will adapt it to work with Python 3 as well. Note that, even for Python 2, ``cpyext`` is still in a beta state. In particular, not all extension modules compile and load correctly. As a consequence, the same will be true for Python 3 as well. As a general rule, we expect that if a Python 2 module works with ``cpyext``, the corresponding Python 3 version will also work when this step is completed, although the details might vary depending on the exact C extension module. **Estimate cost**: 10.000 $

4 3

"checkout benchmarks failed"
by Armin Rigo 12 Sep '11

12 Sep '11

Hi all (particularly Fijal or Antonio), Can you explain the current state of the benchmarks, and possibly fix it? As far as I understand it runs fine but no longer updates the benchmarks themselves: http://buildbot.pypy.org/summary?category=benchmark-run A bientôt, Armin.

4 4