Make PythonOS ready for Python 3

[linusg]

I really like this project, however, it's still Python 2 only. It would be nice to see it run under e.g. Python 2.7 - 3.x (or even 2.6 to the newest Python).

To be honest, I don't know how hard this would be, I guess simply replacing all the prints is not enough.

I guess this is important to have a stable codebase in the future, and would possibly bring some (small) speed improvements too.

[Yardanico]

Yeah, because Python 2 is obsolete now, Python 3 contains many useful features

[Yardanico]

@linusg python 3 is slightly slower directly compared to python 2, because it's easier to write code to

[linusg]

@TiberiumPY - I just read that PyGame under Python 3 is a bit faster, sorry don't know more. Beside of that, Python 2 has some well known issues and Python 3 code is just less hackish.

[Yardanico]

@linusg pygame is slow itself, because it uses old SDL, new SDL2 is much faster because it does hardware acceleration and many other things (but it's not SDL compatible)

[furmada]

Development of Python OS began when Pygame did not support Python 3. However, porting Python OS to run on 3x is an eventual goal. I do not have experience porting code over, but anyone would be welcome to try forking the code and trying to make it work.

Python OS does run on Python 2.7, in fact, it is developed using 2.7.9.

[ghost]

I think the project need to flush out major bugs first and doing a few improvements before porting to Python 3. It's not fun to fix inherited bugs from the original project in a platform that has different quirks and pitfalls.

[overdev]

I managed to run PythonOS on Python34 once. The porting to another version is not the dificult part. What PythonOS needs the most at the moment is to have its code in full Python idiom (PEP8 compliant plus basic in-code documentation and type annotation*). There's too much Java or Cpp code style in there. This is true for the initial releases, at least.

*type annotation: for python versions that do not support it, there is a convention used by PyCharm devs that looks like this:

def sum(a, b):
    #type: (int, int) -> int
    """Returns the sum of a plus b.
    """
    # 'result' variable has an inline type hint
    result = a + b                          # type: int
    return result

I believe I still have de code refactored in PEP8.

[Yardanico]

@overdev keeping almost all core code in one file isn't very good too

[linusg]

@overdev - Hey, I would love to see the ported code! And I fully agree with your full comment. Being a huge fan of PEP8, I also think of refactoring the code style. However, I didn't know about the alternative way of type annotations for Python 2, I will definitively keep that in mind!

[overdev]

@linusg - I have refactored the code of the first PythonOS stable release and not completely (most apps needs refactoring). I don't know what changed since then. Anyways, I'm refactoring PythonOS 1.01 hoping it does not take too long (better before any significant comit to master).

About type annotations, It is only helpfull with IDEs that recongnizes them, like PyCharm (wich is the one I know of). The type hints for variable and attributes is explained better in this PEP; the function type annotation I mentioned is just a suggestion.

The most dificult parts are:

• too broad exception clauses in contexts that could raise absolutely any kind of exception (like in thread functions);
• the overwhelming number of hardcoded string values;
• long method call chains;
• turning getters and setters into properties;
• removing unecessary statementes or replacing by something more pythonic;
• refactoring the messy code of the apps... :'(
• a single file of 2800 lines, as TiberiumPY said (easy at the top, hard at the bottom of the file). After doing all that, porting to Py34+ becomes a breeze.

[Yardanico]

@overdev type annotations are also helpful if you use mypy or pytype

[overdev]

@TiberiumPY - You're right. I always forget to try mypy. pytype is new to me.

[linusg]

@overdev - I really appreciate your explanation. I'm also using PyCharm, however, with Python 3 and its regular type annotations only. Again, I agree with all your suggestions on refactoring the code, and to be honest, @furmada closed this way too early. Please keep us up to date!

[overdev]

@linusg - I'll do everything in a single commit, so the best news I can give is that 30% (telling by the number of lines) of pyos.py is already done. Maybe in 4 or 5 days (the best case) the core file will be done.

[furmada]

@overdev Thank you for your input. I agree that the code can definitely be cleaned up. This started as a project just for fun, so I did not put the appropriate amount of effort into standards compliance or annotations.

I hope to find time to finish the docs in the wiki and then put type annotations etc. into the file.

However, some of what you listed as "difficult parts" are there for a reason:

• Broad exception clauses are necessary to provide OS-like functionality, where the main program shouldn't crash if an error occurs, and where the type of error is unknown - such as in Threads. The error itself is not silenced but is displayed to the user and written to last_error.txt.
• Some getters and setters are necessary - such as setText - because they do additional work in addition to changing the value.
• Hardcoded string values - at least the ones you pointed out - are there because they are not intended to ever be changed, they are part of the OS API.

I am glad to see vibrant discussion surrounding my project. Therefore, I am reopening this issue. Thank you for your interest in Python OS.

[overdev]

@furmada - Oh, you're welcome!

I understand (at least partially) the reasons you provided. I'm trying not to change what does not need to change, I mean, as you pointed out, some getters must continue to be as such. Only those getters/setters that does not computates too much will be turned into properties.

The only concern about broad exceptios is due to the KeyboardInterrupt exception. I believe it is the only exception that should not be treated, even by PythonOS. I must confess I don't have a better solution, but I'm investigating a way to avoid the current situation (help is appreciated). It would be good if python allowed the not operator to be used with except in the same way it allows with the in operator:

try:
    ...
except not KeyboardInterrupt:
    handleIt()

The best I can suggest is:

try:
    ...
except Exception:    # handles all subclasses of Exception
    ...
except KeyboardInterrupt:    # subclass of BaseException, not caught by the clause above
    raise

It is good to know that the string values are not intended to change, but I still have a question: Do you intend to add more of them (or to allow user code to do so) in future releases? My suggestion to this is to replace the strings by pseudo enumerated constants, e.g., namedtuples and, therefore, avoid mistypings that pass silently. Let's take the Thread events as example. I grouped all event names into a namedtuple that looks like this:

# The Thread events as pseudo enumerated constants. The string values are kept intact and used in the same way as before.
ThrEvt = namedtuple("ThrEvt", "on_start on_stop on_pause on_resume on_custom".split())(
    "onStart", "onStop", "onPause", "onResume", "onCustom")

# usage (in __init__() of Thread class):
def __init__(self, method, **data):
    ...
    self.event_bindings = {
            ThrEvt.on_start: None,
            ThrEvt.on_stop: None,
            ThrEvt.on_pause: None,
            ThrEvt.on_resume: None,
            ThrEvt.on_custom: None
        }
    ...
    # then:
    self.event_bindings.update(data)        # updates the dictionary with the **data kwargs.

Thanks for reopening the issue, anyways. I'll try to finish the refactoring of 1.01 as soon as possible.

[overdev]

Finished refactoring of pyos.py. The code is not 100% PEP8 but is very close. Visually, it does not look prettier and nothing was done with that in mind. Type annotations cover all the important parts (function signatures, ambiguous variable types). A second pass would be good, later, to optimize a little and beautify everything.

The bad news is that I've introduced some hard to find bugs. For some yet unknown reason, every mouse press is triggering a LongClick event, wich causes the function bar clock to show the rescue menu when clicked rather than the notification menu.

requests module is not in the standard lib. I didn't know that... wolfram-alpha will no longer cause fatal error for those who don't have it installed. But it won't work too.

I'll be uploading the code to my repo in the next 6 hours— with all current bugs, and continue from there.

@furmada, there is no way to tell, from the code, the current pythonOS version. Maybe its good to add it somewhere.