Wanted to pump this Thread, because I am very interested in Python for AROS, too. I just started to learn Python on RaspberryPi2 and it would be cool too use this knowledge for AROS-coding.

Are there any news in this matter? I am willing to spent some money for the bounty (if there is still a bounty?)

I've updated a bit my last post, since now there are Python 2.7.8 and 3.4.2 available.

Another thing: it's obvious to me that all sources should be released, with a license which is at least compatible with APL, but it's better to remark it.

Like to bump this because more languages = more people to use it on AROS and more projects for us:
is this ever been approved as bounty?

Soon 2 month ago 20130429 i sent a USD 20 donation to the Pyaros advanved project to keep it alive..

Still did not register so now I mailed them to look my donation up. I hope there is not a problem to donate to the project and others had the same experience that I had.

I will wait and se what power2people will ansver on my question on the missing bounty money...

-----------------

I got an answer from p2p and the donation got stuck in the spam filter for som reason.. but still good since it was not lost..

good if the maintainer keep an eye open to add any donations made so anyone see the project is alive..

That list is all fine by me. But whom have the mandate to cancel the present bounty (or make changes to it)? I belive making an update/change to the old one would be the easyest solution.

I belive it would be apropriate to contact the people already donating to it if it is possible to reach then in any way.

perhaps someone in aros exec know who they are ?

I already suggested what to do here and here.

I try to reformulate the points into which the old bounty could be split:

1) port the MorphOS Python 2.7.3, upgrading it to 2.7.11 (since they are just security fixes).

2) Create a complete Python binding for the Zune library (PyZune), starting from the PyMUI project.

3) Complete some external libraries (bzip2, db (Berkeley db), openssl, sqlite3) port.

4) Complete some external libraries (tcl, tk) port.

5) Update the port to support Python 3.5.1.

Part 4 is optional or with a very low priority, since Tcl/Tk is used to build application with GUI, but for AROS the priority is making the same, but using Zune instead.

For each part, all related tests in the standard library (Lib/test/) must pass. Tests for different platforms/o.ses (Windows, Linux, etc.) should not necessarily pass, of course (if some passes, it's OK/welcome).

For PyZune, a complete unit test suite must be built, that tests all Zune APIs / functionalities.

If GUI automation is not possible for some or all PyZune features, tests for such functionalities aren't required to be integrated in the unit test, but specific samples should be written on a separate suite to allow manual testing. It means that a person can run some PyZune scripts, interact with the GUI, and see if everything is working fine.

Python sources changes must be released when the bounty is completed. Python's PSF license must be used, except for Python's third-party external libraries (which belongs to their corresponding licenses). Changes to the external libraries, if needed, must be released as well.

PyZune sources must be released, with APL or compatible license. GPL is not recommended, because it reduces the audience.

Parts 3 and 4 cannot be started until Part 1 is complete, but they can be started independently once Part 1 is fulfilled.

Part 5, as well, cannot be started until Part 1 is complete, because Python 2.7 port takes precedence: it's the most common and used Python version.

All Python code (like the new one for PyZune) must follow the PEP8 guideline. Only the AROS-specific code should follow the AROS coding style.

The old bounty (PyAROS) should be "converted" to the new point 1.

P.S. I moved the points in order of importance, from the most important to the least one.

So what to do with the present bounty ?
If and how to change it ?

Whar are the roles for the funds present in the old bounty ?

My suggestion would be to create a port from 2.5.2 up to todays 2.7.4 together with some useful librarys to expand the MUI / Zune capabilities.

I started to play around with 2.5.2 on AROS and discovered some bugs that seems to be fixed in the 2.7.4 windows version.

... and in meanwhile a 3.3.1 (or 3.4) port can be done. ;)

Porting the 2.7.4 to Aros would be the best thing to do in my opinion. 3.2.x as today is not really adding much new that can not already be done in 2.7.x version.

2.7.4 was released at april 6 2013 so it is quite up to date and external modules are more compatible with the 2.7.x series I think.

Having a working 2.7.x together with some modules for networking,graphics, audio and zune would be a great platform for any "small time app" developer as well as skilled pyton software developer.

I also belive that 2.7.x will not be "left" so easely just becauce the release of 3.x version.

A full change over to 3.x might take many years to offer what 2.7.x offers today together with external modules/code.

Quote:
I've downloaded it, but it's too old; also, it's strictly related to the Amiga (there's some 68K assembly code). However I found that Guillaume used some parts for his port, so may be he decided to get only what he thought was important, starting the port from the original Python 2.7 sources.

I got MorphOS Python 2.7.3 port by Guillaume, and compared to the official 2.7.3 source. The changes can be grouped in 4 classes: CPython Core (C language), CPython library/modules (Python), MorphOS core (C language), MorphOS library/modules (Python).

He made a lot of work, especially on the MorphOS core (it supports threads, and has written a C subprocess module), but the other changes are simple or affordable (CPython core has little changes).

I think that most of the Python code (both for CPython and MorphOS) can be easily modified to support AROS too or any AmigaOS-like operating system. Default encoding (latin-1), file paths, and most filesystem-related stuff can be shared as "AmigaOS platform". For example, morphospath.py and mosurl2path.py can be reused with just a bunch of changes, and their name changed into something like amigaospath.py and amigaosurl2path.py.

I don't know how MorphOS and AROS compiler toolchains works (I know that both use GCC, but right now I used Visual Studio as my primary tool for C development), so I stopped here my analysis.

My idea is that we can use Guillaume work to get a Python 2.7.3 (and 2.7.4; the latter has very little changes, carrying only security fixes), since it has many advantages over the partial Python 2.5.2 port already available for AROS. Points 1, 2, and 5 of my list can be completed, and there's a very good base for point 7, thanks to PyMUI.
So, points 1, 2, and 5 can be merged into point 1 ("Port MorphOS Python 2.7.3 to AROS"), and point 7 (now number 5) changed accordingly ("Port PyMUI to AROS, interfacing it to Zune instead of MUI").

The most important thing is that we have a shared library instead of a standalone executable, so it will use little memory. Once loaded the first time, the library will be shared by all Python instances, reducing the loading time as well.

PyMUI is mostly Python based, but there's a 100KB C file that is used as an internal Python module, which is used to interface Python to MUI. From a first look, I don't think that there are problems updating it to interface to Zune, but a Zune expert can say something about that.