Python 3.8 - alpha release

Hi all

For anyone who’s interested, I have built an alpha release of Python 3.8, which can be downloaded from here..

http://www.mediafire.com/file/m0vxr49pmphzyy6/Python3.zip/file (it’s a RISC OS zip file)

It’s an elf program and uses shared objects, so you will need !SharedLibs installed.

Please be aware that this really is alpha quality software. I am releasing it to get feedback, comments, bugs and suggestions.

You can comment here, send an email to the address in the ReadMe file or on the issue tracker at https://github.com/c-jo/cpython/issues

Happy pythoning!

Chris

Good work, Chris!

Yes, very good news. I will get into Python at work soon so once I get used to it I would like to try it on RISC OS as well. Good to see the current version ported. Unfortunately I don’t have enough experience with it now to test it.

This seems in pretty good shape for an alpha release.

There doesn’t seem to be support for <Python$Path> as an equivalent to PYTHONPATH on Posix and Posix-like systems. Is this something you plan to implement? Or is there another way to get that functionality?

I’m getting failures in pathlib, I guess you just haven’t got to it yet. Do you have plans for a RiscOsPath (And RiscOsPurePath) implementation for that package? It could be a tidy way to handle file types, use the MimeMap module to convert them to extensions, then return them from .suffix(). And vice-versa of course.

Thanks Chris, early tests on my PineBook are very positive. Many thanks for bringing the current version of Python to RISC OS.

Thanks for the feedback.

There doesn’t seem to be support for <Python$Path> as an equivalent to PYTHONPATH on Posix and Posix-like systems.

Ah.. yes… I cut a fair bit of the path searching stuff out to concentrate on getting the basic system working first, so now need to put the missing bits back :)

I’m getting failures in pathlib, I guess you just haven’t got to it yet.

Thanks for pointing that one out. I’ve started to add the RISC OS ‘versions’ of Path and PurePath.

As you might’ve guessed, so far it’s really been a case of ‘enough to get to the >>> prompt’, getting the extensions working and trying to use a more RISC OS-like way of handling files (which is still not fully complete).

Thanks Chris, early tests on my PineBook are very positive.

The PineBook is my main development platform for it now. :)

At the moment I am working my way through the Python Primary School examples that featured in DragNDrop a few years ago. So far the example programs work. StrongEd makes a great RISC OS version of IDLE. I am sure you already knew that but just in case someone else is starting to use Python.

No working here i get system is a Titanium running ver 5.27 19/12/19
Python path configuration:
PYTHONHOME = (not set)
PYTHONPATH = (not set)
program name = ‘ADFS::225SSD.$.Programming.Python\xa03.!Python.python3’
isolated = 0
environment = 1
user site = 1
import site = 1
sys.base_executable = ‘ADFS::225SSD.$.Programming.Python\xa03.!Python.python3’
sys.base_prefix = ‘ADFS::225SSD.$.Programming.Python\xa03.!Python’
sys.base_exec_prefix = ‘ADFS::225SSD.$.Programming.Python\xa03.!Python’
sys.executable = ‘ADFS::225SSD.$.Programming.Python\xa03.!Python.python3’
sys.prefix = ‘ADFS::225SSD.$.Programming.Python\xa03.!Python’
sys.exec_prefix = ‘ADFS::225SSD.$.Programming.Python\xa03.!Python’
sys.path = [
‘ADFS::225SSD.$.Programming.Python\xa03.!Python.Lib’,
‘ADFS::225SSD.$.Programming.Python\xa03.!Python.Lib.lib-dynLoad’,
]
Fatal Python error: init_fsencoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named ‘encodings’

Current thread 0×00291d94 (most recent call first):

Any ideas?

The error makes it sound like it doesn’t care for your machine’s ADFS or perhaps something about the disc/folder paths.

Have you tried running it from another FS such as SDFS, RAM or SCSIFS?

the same error with scsi set as the filesystem and the python directory on a second drive

Python path configuration:
PYTHONHOME = (not set)
PYTHONPATH = (not set)
program name = ‘SCSI::Panda.$.Python\xa03.!Python.python3’
isolated = 0
environment = 1
user site = 1
import site = 1
sys.base_executable = ‘SCSI::Panda.$.Python\xa03.!Python.python3’
sys.base_prefix = ‘SCSI::Panda.$.Python\xa03.!Python’
sys.base_exec_prefix = ‘SCSI::Panda.$.Python\xa03.!Python’
sys.executable = ‘SCSI::Panda.$.Python\xa03.!Python.python3’
sys.prefix = ‘SCSI::Panda.$.Python\xa03.!Python’
sys.exec_prefix = ‘SCSI::Panda.$.Python\xa03.!Python’
sys.path = [
‘SCSI::Panda.$.Python\xa03.!Python.Lib’,
‘SCSI::Panda.$.Python\xa03.!Python.Lib.lib-dynLoad’,
]
Fatal Python error: init_fsencoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named ‘encodings’

Current thread 0×00291d88 (most recent call first):

merry chrismas by the way all the way from Aus

I am wondering if it’s the \xa0 (non-breaking space) that’s causing some part in the chain to get upset. Can you try renaming SCSI::Panda.$.Python 3 to SCSI::Panda.$.Python3 (or Python_3) and see if that works?

Thanks

Chris

well done chris you hit the ball right out of the park well spotted that fixed it, now i can move on and check other programs.

I do have big questions about what a space (non-breaking or otherwise) is doing in a filename or path.

To quote a colleague “spaces are delimiters”

The space was all down to me I’m afraid I like to make me workspace more readable so if I have version 2 I would write Python 2 so it follows that I would write Python 3 one of my little quirks.

The space was all down to me I’m afraid I like to make me workspace more readable

Smacked wrist :)
There’s a nice key to the right of the 0 (zero) – pressing the shift key at the same time is optional.

All that said, spaces in file and directory names are (sadly) common on other platforms nowadays, and it’s nice when one can share them (relatively) seamlessly between platforms.

Not that I use spaces on the Mac, but then not all the files I handle are named by me.

spaces in file and directory names are (sadly) common on other platforms nowadays

I refrained from mentioning the cretins¹ at Redmond previously.
Yes, they are – how else would you label a set of people that program their flagship document editor to produce a file name from the first text in the document that uses a complete sentence, because spaces are valid, yet produces a filename of “The” from a first line title text of “The-Title-of-this-document” or “The_Title_of_this_document”
Meanwhile, other parts of the system throw a wobbly if file or directory names aren’t enclosed in quotes, yet they persist in putting programs into “C:\Program Files”

¹ I’m normally far more expressive, but I’m in a chilled holiday mood and there may be delicate persons about.

It’s not just Microsoft who do it. The Mac comes full of spaced out filenames as well. Lots of hyphenated or underscored ones too, seems utterly random.

Off to Aldershot

Have just got Python 3.8 alpha up and running on my Titanium machine. Absolutely brilliant work Chris! I look forward to future releases. From my limited experimentations, I have only encountered three issues. The first is in the hello script, where the line print(“Hello {} World”.format(os.name)) could be better written as print(f"Hello {os.name} World"). In the Windows World, I longed to move my huge Python program to Python 3.6 just so I could use f-strings! I love f-strings! The second is in executing the python3 command where I get the “Wimpslot not big enough to run ELF program”. Executing a suitable Wimpslot command beforehand resolved this though as will changing the relevant line in !Boot from ’’’set Alias$python3 Run <Python$Dir>.python3 %0’’’ to ’’’set Alias$python3 Wimpslot -min 16M |M /<Python$Dir>.python3 %0’’’. The third is that I am unable to import ctypes as the _ctypes module is missing.

Thanks for the feedback everyone. I have had some time over the past few days to progress things.

I’ve now added Python$Path which seems to be working, and (finally) tracked down and fixed the problem with the spaces in the filenames (if anyone is interested, it was because passing the utf-8 string to the SWI to get the file type, so that failed so python didn’t try to load it).

I have got pathlib to import, but I need to test it. I had a look at ctypes, which looks like it needs libffi. As I was on a train at the time, I wasn’t able to do a lot of searching online about it. I’ll stick it on the to-do list :)

The first is in the hello script, where the line print(“Hello {} World”.format(os.name)) could be better written as print(f"Hello {os.name} World").

Good call. It was kinda just thrown in to test that double-clicking on a python file does what it should :)

While I’m here – what are people’s views on the naming? At the moment it’s called !Python, but so it Python 2, and they also use the same file type. Is there merit to changing the name to !Python3, using a different type (and Python3$Path) to allow both Python 3 and Python 2 to work at the same time?

I know on linux you can have both installed, not sure about Windows.

As far as issues of identity go I can see arguments both ways.

My initial reaction is to say that Python 3 is intended to replace Python 2 and we are now past the point where Python 2 is officially deprecated. In which case I don’t see a compelling reason to support both working side by side. Afterall they can still both be installed but only one can be active at a time.

On the other hand there may well be people out there who are going to get into a position where they want to use both at the same time. While we should be doing everything we can to encourage them to migrate to the supported platform it may be out of their hands.

One factor which should feed into this is pressure on resources. Filetypes are limited in number, what percentage have been used?

Python 2 and Python 3 are separate things, so keep them separate. Python 3 is (intentionally) breaking backward compatibility.

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

Still no ctypes but some of the other stuff should now be working.