Python Version And Tools To Include

[joseluisjazz]

Hi, I want to bring up the conversation about which Python(s) version(s) are going to be in the official Pandora distribution.

Since Python 3.0 just has been released, but the majority of python existing programs are 2.x compatible, my opinion is that we should ship both branches. A version from the 2.x branch (2.6 or 2.5), and also python 3.0, because that's the way the language it's going to be from now on. It'd handy to have a good set of python tools installed by default for coding on the way.

In adittion, the most important/useful/mature python modules should be added too, as they're ported. Things like pygame, numpy, configobj, cerealizer, pyusb, pyvorbis, python-bluez, python-xmpp, python-wxgtk2.8, python-cwiid, cython, etc...

Do you have any ideas?

 

[viridior]

Not saying that it isn't possible, but I know there are problems getting python 2.5 compiling correctly on ARM processors. Maybe there are some patches and it has been working on a couple of distros (I don't know which they would be), but at this point I haven't had much luck with python 2.5+ compiling on a armv7a-softfloat-linux-gnueabi toolchain. If there are workarounds/patches let me know and I will try to compile it. As far as python 3.0, I would imagine that since it is not backward's compatible with 2.x there may be a bit of a lag behind x86/amd64 for it to work with ARM.

 

[joseluisjazz]

Not saying that it isn't possible, but I know there are problems getting python 2.5 compiling correctly on ARM processors.
Ok. I'll look around for info. But I understand that if Ubuntu is going to be ported, that includes python 2.5, so we can take their patches.
QUOTE
As far as python 3.0, I would imagine that since it is not backward's compatible with 2.x there may be a bit of a lag behind x86/amd64 for it to work with ARM.
It's true. 2.6 Isn't even on Debian Sid and it was released on oct 1st . Better concentrate on 2.5 + modules.

 

[skeezix]

If python is included at all (who knows? space is tight..) -- just install whatever version you want, yourself; it won't be that hard (especially for devs.) (If your worry is about building a py3 script and not having others able to run it out of box, first consider that py3 was just announced, and MANY modules are not also fixed yet .. so there is limited things oyu can do right now with py3 _anyway_, without having people freshen up their modules on a week by week basis...

I'd say _stable_ branches, or not even to bother .. though pygame does make it attractive to include if theres space..

jeff

 

[Eniko]

As far as I know 2.6 was intended to be a version bridging old Python and new Python, so it makes sense to me to have 2.5 and 3.

Also what is this about Python 2.5 being hard to get working on ARM? I was under the impression from more than a few developers that Python was practically gauranteed for the Pandora.

 

[viridior]

As far as I know 2.6 was intended to be a version bridging old Python and new Python, so it makes sense to me to have 2.5 and 3.

Also what is this about Python 2.5 being hard to get working on ARM? I was under the impression from more than a few developers that Python was practically gauranteed for the Pandora.

Python IS guaranteed, at least 2.4, I know I have been able to compile correctly for the armv7a cortex-a8, the question is whether 2.5 does... if it does, where are the patches? It may already work under the latest Ubuntu, but I have had problems compiling 2.5 from source (unpatched) using the arm/armv7a optimizations, and I know I am not the only one.

 

[tajuma]

Not saying that it isn't possible, but I know there are problems getting python 2.5 compiling correctly on ARM processors. Maybe there are some patches and it has been working on a couple of distros (I don't know which they would be), but at this point I haven't had much luck with python 2.5+ compiling on a armv7a-softfloat-linux-gnueabi toolchain. If there are workarounds/patches let me know and I will try to compile it.

Just a wild guess, have you been using CodeSourcery 2008q3 (or q1) toolchain? If so, 2007q3 version might produce more correct code. Here is an advice from BeagleBoard community
http://elinux.org/BeagleBoard#Compiler.

 

[sindbad]

2.6 would be ideal, since it it backwards compatible, but has many features from 3.0. 3.0 is not intended for production right now and it shouldn't concern us.

2.5 is in the debian armel repo, so compilation or ARM should be just fine.

 

[joseluisjazz]

2.6 would be ideal, since it it backwards compatible, but has many features from 3.0.
2.5 is in the debian armel repo, so compilation or ARM should be just fine.

Aha. I completely agree. Forget about 3.0, let's focus in porting version 2.5, and after that try to to the same with 2.6.

The thing is I don't see python 2.5 in the armel repo. The only thing I've found by now is this.

 

[sindbad]

It's isn't in etch armel, but it is in both lenny and sid.

 

[joseluisjazz]

It's isn't in etch armel, but it is in both lenny and sid.
Ouch! :lol: How could I miss that. There it is!
It has like 42 patches, there must be the answer.

 

[valhalla]

2.5.2 is also in openembedded and builds e.g. for the beagleboard, so it shouldn't be hard to add to pandora.

 

[rokdcasbah]

It's on the GP2X too, along with pygame and whatever dependencies pygame has. I remember reading about trouble with ctypes. But in any case, Python for ARM exists and has for a while now.

 

[sindbad]

The trouble with ctypes on ARM has been resolved a long time ago, there is a python 2.5.2 ctypes package in Ångström. Everything not explicitly depending on x86 (like psyco) works as expected as far as I know.