Python 3 status

We’ve had a few enquiries about Python on RISC OS, and whether we can offer Python as an alternative to BASIC on our platform. I know we had Python 2.7.2 (?) but the rest of the world moved to Python 3 and that dropped RISC OS support.

I think perhaps there’s been some more recent progress though?

Who’s best to talk to?

What caused RISC OS to get dropped for Python 3, and what are the challenges preventing a current port?

I appreciate it may be a case of supporting libraries, but it’d be helpful if I had a better understanding of where we’re at. Also, how much of RISC OS is available via Python (eg. SWIs, wimp library, templates, modules etc?). Can Python files be run on RISC OS as easily as BASIC files, if !python has been seen?

Thanks in advance.

What caused RISC OS to get dropped for Python 3,

No active maintainer. Dietmar Schwertberger, who did the Python 2 port and maintained it for a long time, was no longer available.

and what are the challenges preventing a current port?

As always – not enough developer time? Dietmar’s port was very polished, done with Norcroft C, and added a lot of RISC OS-specific stuff. So it depends what kind of port you really want for Python 3. Chris Johns seems to have started with one: https://www.riscosopen.org/forum/forums/5/topics/14247

Steffen – do you have any contact with Dietmar? I would very much like to hear from him given what you say.

I will also read that topic you linked, but again, would like to hear from Chris if possible. The thing is, I’m going to need a bit more detail than “developer time” given the people involved.

Steffen – do you have any contact with Dietmar?

Unfortunately – no. I exchanged a few emails with him a long time ago (more than 10 years probably), but never met him personally. I’ll ask around.

I guess Chris Gransden solved the problems I mentioned a while ago that made building Python 2.7 a challenge. I don’t remember if there was much stuff in CPython (the “standard” implementation) that was ripped out when Python 3 came along, though I do remember the conference when it was announced that support for legacy platforms wouldn’t be carried over into Python 3. ;)

I suggested that someone could port MicroPython a while back because it might have been easier to port from scratch, is more lightweight than regular Python 3, and supports things like inline assembly code. There’s also been a lot of work done to give it a subset of the standard library.

But for “standard” Python programming, you’ll need CPython, though how many of the useful libraries will work depends on the system features they need.

Hi!

Steffen managed to contact me…
Actually, I’m not the one that did the port.
I just took over the maintenance and also submitted the patches to the main repository.
I’m not sure, but I think Chris T. Stretch did the initial port.
The most work at that time probably was the dynamic loading of extensions via DLK.
A major contribution was also the GUI stuff by David. This was really nice to use.

To answer Steffens questions:
C++ was not used for Python 2 and I’m quite sure that it’s also not required for 3.
The CPython source code is rather portable. On Windows Visual Studio is used for building, on other platforms gcc.

This is certainly not true for the DLK stuff. The loading mechanisms have changed a bit between Python 2 and 3.
If there’s now a standard way for dynamically loading code, then this is probably the way to go.
For a start, it’s possible to build Python without dynamic loading, but then many things like numpy will not be available.

On other platforms, multiple running instances share the core Python interpreter as dynamic library. I think that there were some thoughts about having the core as RM, but that never happened.

Porting MicroPython probably would not help too much. I don’t think that a lot could be learnt for porting CPython.
(For anyone interested in microcontrollers: MicroPython is really the coolest thing of the recent decades when it comes to microcontrollers. At first I had doubts that it could work, but it’s really great.)

If someone manages a port, then it would be a good idea to submit patches again to the main repository. This made maintenance much easier.

Unfortunately, I can’t help too much on this. I switched from RISC OS to Windows around ten years ago, mainly due to the browser situation. Before switching to Windows 10 I still had VirtualRPC installed, but due to the lack of a seamless mouse integration, I did not install it any more. I really miss the RISC OS GUI and e.g. !Draw and also the font display. The Acorn guys were so far ahead.

A few years ago I took over maintenance of wxGlade, a GUI builder for wxPython. Porting wxPython to RISC OS would be nice, but unrealistic…

Regards,

Dietmar

The old website incl. binaries and RISC OS specific additions is still available from here:
http://web.archive.org/web/20071223061900/http://python.acorn.de/

I think that was the latest release. At some point in time when I was not working on it any more, it was transfered from my pages to acorn.de.

Regards,
Dietmar

The old website incl. binaries and RISC OS specific additions is still available from here:
http://web.archive.org/web/20071223061900/http://python.acorn.de/

To give that old stuff a permanent home (useful things have vanished from the Wayback Machine before) for probably the next 20 years, I copied the content to a new subdomain on my website, adjusted a few links to save anyone interested the work I had done anyway and added a link to Chris Gransden’s port of Python 2.7.2:

http://riscos-python2.huber-net.de/

In relation to Chris Gransden’s port of Python 2.7.2 it might be worth highlighting that you’ll need the !PatchSWP utility for it work on a RPi3B. Located here → http://www.tellima.nl/riscos/

I did start a port of Python 3 some months ago, however I’ve not had a huge amount of time to do much more with it. The binary itself is quite big by RISC OS standards although maybe not so much nowadays. I am not sure if I needed to statically link a library to make it work.

The latest Python3 does expect threading, which RISC OS doesn’t have, although UnixLib does some implementation of it, I am not sure if it only works in a TaskWindow.

Then what about things which aren’t ‘core’ python but often included when people talk about using python. Things like the PyPI packages for example.

I would imagine calling SWIs wouldn’t be too difficult to add, and I guess from there libraries could be built but that sounds like a lot of work. So maybe it depends what they want to use it for?

Python3 does expect threading, which RISC OS doesn’t have

The Kernel doesn’t multithread as such, but there’s no reason at all why an application shouldn’t.

Are you thinking of Dan Ellis’s work to add multithreading to the Wimp? I have a copy of that somewhere, and I believe it’s part of the source tree, possibly. However, that was just an exercise in API convenience – any task can do it’s own thread switching.

You mentioned UnixLib – I’m pretty sure that has pthreads in it, and I don’t see why that would be dependent on an unrelated preempter (TaskWindow) sitting on top of it – the whole point about TaskWindow is the child task doesn’t need to know it’s being preempted.

The latest Python3 does expect threading, which RISC OS doesn’t have, although UnixLib does some implementation of it, I am not sure if it only works in a TaskWindow.

The UnixLib pthreads implementation is independent of TaskWindow, but uses internally a similar mechanism to “preempt”. I am not aware of any significant limitation of “our” pthreads other than always running single core (as all of RISC OS does).

The other thing I remembered is it’s all unicode. So far I just convert it to 8-bit, but that’s going to break horribly as soon as something unicode this way comes.

Over the weekend I managed to get the SWI module from the RISC OS verion of 2.7 to at least build for Python 3, and some very simple stuff at least works.

>>> swi.swi(‘OS_NewLine’,’’)

>>> swi.swi(‘OS_Write0’,‘s’,‘Hello SWI’)
Hello SWI>>>

Andrew (Rawnsley) – I sent a few emails to your rcomp address last week – just checking you got them :)

Received with thanks, Chris. I’m just dealing with a lot of stuff at the moment, and trying to think it all through. Expect a reply in the next few days :)

PS, nice work on SWIs!

No rush just checking you got them. If I think of anything else I will bother you again :)

Antigravity support…

https://imgur.com/a/35GNJfQ

I’ve now got Python 3.8 to run.. so the controversial walrus operator is here.