Python 3.8 - alpha release

Since Python 3 is a very different application to Python 2, by a different author/maintainer etc, I’d probably suggest !Python3 and request an allocation for it.

The only argument against that is that when there’s a Python 4 etc, we’ll need new app names, and RISC OS doesn’t normally include the version number in the app name.

However, as others have said, Python 3.x doesn’t completely replace Python 2.x, so I think there is a justification for the 3 in the application name.
I’d probably set some aliases so that “*python ” works as it probably would under Linux or similar, although in Boot I’d probably check for the pre-existence of that variable, and only force-set it in the !Run, to avoid compatibility issues. Although, I’m willing to be swayed on that too!

Filetype-wise, I’d probably re-use the existing filetypes, although if there’s a feeling that the Python3 files that a user would double-click on are substantially different to Python 2 files, then maybe have a new type. The downside is that we’d probably need a Python3 mode for StrongEd/Zap so that it saves with the right filetype.

Again, maybe the solution is to define a new filetype, but recognise the old one if Python2 hasn’t already claimed them. That way, old-typed files will attempt to run, but new files can be clearly marked.

Filetype-wise, I’d probably re-use the existing filetypes, although if there’s a feeling that the Python3 files that a user would double-click on are substantially different to Python 2 files, then maybe have a new type.

Python 2 and Python 3 are different, so they need different filetypes – or we need a wrapper that decides from the content of the file if it is Python 2 or Python 3 and delegates to the correct version.

It sounds like the cleanest way is to have !Python3, a Python 3 type and to use Python3$Path (keeping Python£Path for Python 2). I know on Unix both use PYTHONPATH but RISC OS treats all environment variables as global so if both 2 and 3 use the same variable I can things getting into a bit of a mess if both are in use.

The other two types (for compiled extensions and bytecode) probably don’t need to be Python3 specific. While they won’t be used in Python 2, they may be in Python 4 if/when that happens.

I imagine it would be fairly easy to get StrongEd / Zap to use either file type for it’s Python mode.

It sounds like the cleanest way is to have !Python3, a Python 3 type and to use Python3$Path (keeping Python£Path for Python 2).

I have Python3 and Python27 co-existing here in that way, at a simple “hello world” level. Temporarily user File$Type_020 is used for Python3 with little 3 added to the filetype icon.

hello world - python2
Hello riscos World - Python3
hello world - python2
Hello riscos World - Python3

I imagine it would be fairly easy to get StrongEd / Zap to use either file type for it’s Python mode.

For StrongED, in Modes.Python.ModeWhen :-

Rules Include
! ae5,**
! 020,**
! *, **.py.* **/py*
End

For Zap, in !Zap.Modules.!ZapPython.Types :-

Python		&1AE5			Python
Python		&1020			Python

Can Python3 run Python2 code?

If yes, then Python3 should claim any Python* system variables if they are not already set. This should mean that “stuff just works” for people that only have the (later) one installed. A simple string-not-empty test in the !Run file would suffice.

Can Python3 run Python2 code?

Short answer: no. More complicated answer: some of it.

See here for some hints: https://docs.python.org/3/howto/pyporting.html

Alpha 2 now available from here https://github.com/c-jo/cpython/releases/tag/riscos-3.8.0-a2

I have downloaded the zip file using NetSurf but cannot unpack it.
It has a file type of data. When changed to zip pr archive and attempting to open with SparkFS it gives error message “E00 not found”

Should have said running on ARMX6 using RO 5.25 (25 April)

Hi John,

Well I have just downloaded the archive and changed the file from data to Archive and unzipped it OK.

ARMX6 , RISC OS 5.25 (24-Aug-18) and SparkFS 1.45 (12-Jul-18)

Hope that helps you track your issue down.

The simplest way to deal with a zip or archive that is incorrectly typed (eg Data) is to drag it from the filer window to the SparkFS iconbar icon. If it is a zip/arc which SparkFS recognises it will set the filetype correctly and open the zip. Saves have to set the type yourself.

Thanks Doug and Chris.
All is well again after applying step one of the “MicroSoft Method”.
Ie, power off and power on.

Alpha 3 now available.

An IMPORTANT NOTE Python3 scripts should now be typed A73. The types of the bytecode and extension modules has also changed, so it’s best to remove any pycache directories.

https://github.com/c-jo/cpython/releases/tag/riscos-3.8.0-a3

This will probably be the last alpha release. Not because I am stopping work on it, but because I hope the next one will be beta 1.

I will try to get come up with some sort of ‘roadmap’ as to the next stages for the project. Any input is always welcome.

I found a bit of alpha-ness.

Running this script results in a number of ZeroPains on the Titanium.

print("Hello  World - Python3")

Below is only the first pain the full ZeroPain log is here

Time: Tue Jan 28 16:08:55 2020
Location: Shared Libraries
Current Wimp task: Python
Last app to start: ADFS::Titan4.$.Progm.Progm2.Python.!Python3.python3 ADFS::Titan4.$.Progm.Progm2.Python.hello3a

R0  = 00000000 R1  = 01006aa8 R2  = 002bb078 R3  = 00000000
R4  = 00000000 R5  = 002bb080 R6  = 0000002c R7  = 002bb0c0
R8  = 0025b2b8 R9  = 01006ae8 R10 = 010021e8 R11 = 01006aa4
R12 = 0000004b R13 = 01002b7c R14 = 0013ee98 R15 = 699a8824
DFAR = 00000000  Mode USR32  Flags nZCv if   PSR = 60000010

699a87dc : bbfcc3a1 : BLLT    &698D9668
699a87e0 : e1a06000 : MOV     R6,R0
699a87e4 : ebfcc83d : BL      &698DA8E0
699a87e8 : e2800001 : ADD     R0,R0,#1
699a87ec : e1a04100 : MOV     R4,R0,LSL #2
699a87f0 : e1a00004 : MOV     R0,R4
699a87f4 : ebfcc209 : BL      &698D9020
699a87f8 : e2505000 : SUBS    R5,R0,#0
699a87fc : 11a01006 : MOVNE   R1,R6
699a8800 : 11a02004 : MOVNE   R2,R4
699a8804 : 1bfccccd : BLNE    &698DBB40
699a8808 : e1a00005 : MOV     R0,R5
699a880c : e91ba870 : LDMDB   R11,{R4-R6,R11,R13,PC}
699a8810 : 6c736377 : LDCVSL  CP3,C6,[R3],#-476
699a8814 : 00006e65 : ANDEQ   R6,R0,R5,ROR #28
699a8818 : ff000008 : Undefined instruction
699a881c * e5903000 * LDR     R3,[R0,#0]
699a8820 : e3530000 : CMP     R3,#0
699a8824 : 0a00001f : BEQ     &699A88A8
699a8828 : e5903004 : LDR     R3,[R0,#4]
699a882c : e3530000 : CMP     R3,#0
699a8830 : 0a000020 : BEQ     &699A88B8
699a8834 : e5903008 : LDR     R3,[R0,#8]
699a8838 : e3530000 : CMP     R3,#0
699a883c : 0a00001b : BEQ     &699A88B0
699a8840 : e1a03000 : MOV     R3,R0
699a8844 : e3a02000 : MOV     R2,#0
699a8848 : ea000009 : B       &699A8874
699a884c : e5931014 : LDR     R1,[R3,#20]
699a8850 : e3510000 : CMP     R1,#0
699a8854 : e2833010 : ADD     R3,R3,#&10         ; =16
699a8858 : e2821005 : ADD     R1,R2,#5

R15 = 699a8824 = Shared Libraries +114824 = wcslen +8
R14_usr = 0013ee98 = +136e98 in application memory = _PyPathConfig_Calculate +71c
          Function call to 00020110 = +18110 in application memory

See this is what I get for saying “I think this will be the last alpha” … thanks, I will look into that.

It looks like there are some debug print statements left in pathlib. Every time I create a RiscOS path object it prints to the terminal.

I understand the desire to get a release out of the door so after that’s done it would be great if there could be some more development on pathlib. Particularly around the issue of file types.

he current implementation for RiscOS paths doesn’t allow any access to file type information as it is assumed this will be done by suffixes. Having the path object synthesis suffixes from file type might be the way to go.

But then there’s another issue: What to do about filenames which use the “/suffix” convention. These are often coming from or being prepared for systems which do use file extensions. It would be nice to be able to handle those as well.

Then for extra complication there’s my particular usage scenario which is that I want to access files based on filetype (they exist in RiscOS world) but write files with character swapped extensions for export to a foreign system.

Please don’t think I’m ungrateful for the work already done. I’m just keen to make use of it in the best possible way.

It’s been a bit of a balance of getting releases out and progressing things. So far the focus has been mainly on getting things to ‘work’ to at least a basic level. The 3 alphas have really been a pre-christmas release, almost the same again only git tagged and with the new types. I suspect alpha 4 will be soon, as I found it can’t import files relative to the main script. I tend to release when I’ve got a load of stuff in git (which currently means copying it to linux first).

I agree that pathlib needs a bit of thought. Internally, python will look for suffix and type when loading files. This means that you can use types on RISC OS, but if you just get a load of files from another system that will work too. Something that has also occurred to me is you may want to handle things differently on a FAT-formatted memory stick to filecore formatted hard drive. I am not sure, however, if you can tell the difference without “knowing”.

I’ve setup a mailing list which can be joined by mailing ‘subscribe’ in the subject to riscos-python-request@freelists.org for anyone who wants to join it, or if you can email me directly (the email address is in the !Help file).

I don’t have as much time as I’d like to work on it (this work stuff gets in the way), it makes sense to target the things people have a need / use for first.

Alpha 4 uploaded https://github.com/c-jo/cpython/releases/tag/riscos-3.8.0-a4

I hope this fixes the zeropain stuff – please let me know if it doesn’t.

There is also a very simple toolbox app to play with, although it only does a few widgets at the moment :)

I hope this fixes the zeropain stuff

Yes it does. Thanks.

I dug out the RO stuff for my Pi3 to try this out. Nice work! For fun I tried bootstrapping pip. Didn’t work. Wasn’t expecting it to. Speaking of functionality; if something approximating WiringPi worked with it, it’d probably be way easier to use than fighting with Linux to do it.

I also just learned via this thread that there is native RO support for PineBook now. On testing, not for the 1080 though :(

I also just learned via this thread that there is native RO support for PineBook now.

Hmmm, how much support did you want?
R-Comp brand ARMBook is essentially what you’re talking about I think.

Hmmm, how much support did you want?

An entry in a monitor definition file for 1920×1080, or AnyMode installed maybe? Perhaps it’s more complex. The ability for the screen buffer to have the right amount of data for a horizontal line would be nice. The disc image is a black box so I can’t fix it myself.

Anyway I swapped my RO Pi SD card to a Pi Zero and tried Python3.8. Seems to work. I kind of like Zap’s chosen colour scheme. It reminds me of using my BBC Micro with an amber screen many years ago. I do still remember that it was horrible to look at, but the memory is still generally positive :)

Tristan,

The 11" Pinebook /ARMBook does 1920 × 1080 but the 14" doesn’t.

Nothing to do with RISCOS as its a limit in the hardware.

If you already own the pinebook, you can simply buy the OS/support from us (current ROMs work with both 14 and 12" Pinebooks, but not Pro). Why does it cost? Because we actually pay for the programming to happen and fund RISC OS work. Then we open-source it. Yikes!

work with both 14 and 12" Pinebooks, but not Pro).

I don’t recall which model Tristan (I think) was playing with previously, but perhaps a bit of “cross-fertilization” would be useful?

Why does it cost? Because we actually pay for the programming to happen and fund RISC OS work. Then we open-source it. Yikes!

I think we may have stumbled across a flaw in your business model :)

I think we may have stumbled across a flaw in your business model :)

Yes, it’s supposed to be more like:

Program stuff

???

PROFIT!

(at least, that seems to be the principle behind anything dot-com)