Python 3 support

[C0rn3j]

Since I didn't see any mention it anywhere, not even any issue open/closed, I figured I'll ask and hopefully make a status issue.

How's Python 3 compatibility going? Any dependencies that are only available on 2.7 and make it hard to transition to 3? (not that I can help much, just curious)

For those stumbling through here and not aware, Python 2.7 is EOL in approx a year and half - https://pythonclock.org/

Python 2 is EOL.

---

C rewrite - https://github.com/kozec/sc-controller/tree/c
Python 3 fork - https://github.com/Ryochan7/sc-controller/tree/python3

EDIT 2024: This repo seems dead and current Python 3 fork resides at https://github.com/C0rn3j/sc-controller

[kozec]

Well, me not knowing anything useful about py3 will be one of major dependencies :D

If I end up having to rewrite everything, I'll probably choose completely different, more stable language.

[rnhmjoj]

So, I run 2to3 on sc-controller and manually fixed stuff like unicode encoding issues. It still doesn't build and I'm not sure what's the problem. If anyone wants to continue here's the progress I made so far: https://github.com/rnhmjoj/sc-controller/commit/976f1dbcec41e4a8e24bcd566dba17ef7cfa4e63

                      if t.type == TokenType.OP and t.value == ')':
                              pass
                      elif t.type == TokenType.OP and t.value == ',':
                              self._next_token()
                      else:
  >                           raise ParseError("Expected ',' or end of parameter list after parameter '%s' - %s" % (parameters[-1], parameters))
  E                           scc.parser.ParseError: Expected ',' or end of parameter list after parameter 'b' - ['b']
  
  scc/parser.py:251: ParseError
  ===================== 8 failed, 132 passed in 0.85 seconds =====================

[kozec]

Well, actions stored in profile are parsed using tokenize module, which is probably not backwards compatible in py3.x.

By the way, just to be clear, even if you somehow managed to convert everything into some usable form, you'd probably have to create fork, as I will be unable to work or support it.

[rnhmjoj]

@kozec so you plan on rewriting scc before the end of life of python 2?

[kozec]

I plan to wait and see whether it will be necessary :)

I don't expect it to be, although I'm trying to get thing running on Android, what may require rewriting a lot of stuff in c.

[Klikini]

I wasn't able to get sc-controller or sc-daemon running on my system with both Python 2.7 and Python 3.5 installed until I edited /usr/bin/sc-controller and /usr/bin/scc-daemon (I installed from a package) to change #! /usr/bin/python to #! /usr/bin/python2. Is that a quirk of my system, or would it be useful to support installations on systems with Python 3 installed without using it?

[kozec]

Is that a quirk of my system, or would it be useful to support installations on systems with Python 3 installed without using it?

Definitely system problem, /usr/bin/python should be pointing to python2.

May I guess you are on Arch? :)

[C0rn3j]

With the Python 2 EOL date creeping up I imagine more distributions will make /bin/python point to 3 by default, wouldn't it be better to point scc to 2/2.7 directly rather than hoping the system is using python 2 by default?

[kozec]

With the Python 2 EOL date creeping up I imagine more distributions will make /bin/python point to 3 by default

I hope not, not only would it be against what python recommends and expects, it would also break everything :)

Anyway, SCC uses python2 everywhere [1], [2], so I'm not entirely sure how could @Klikini end up with wrong shebangs in first place.

// edit: Ok, possible explanation is installing DEB package that OBS generated. But that should be fine, Debian links python->python2.

[Klikini]

@kozec Not Arch, but Linux Mint 18.3

[leycec]

This issue should be reopened, preferably sooner than later.

What part of "Python 2.7 will not be maintained past 2020." is unclear, ambiguous, or otherwise open to interpretation? What do the main developers of SC Controller ^{by whom I mostly mean @kozec} expect to happen to their Python 2.7-based application when package managers and distributions begin dropping Python 2.7 due to a growing laundry list of unresolved insecurities, incompatibilities, and issues?

To quote a several year-old article on the subject:

Most significantly, Python 2 will reach end of life in 2020. From that point onwards, the language will not be maintained and security fixes will no longer be available. If you continue using Python 2, take into account that from 2020, the language will become insecure, and you should start planning your migration to Python 3.

The discontinuation of Python 2.7 effectively means the discontinuation of all Python 2.7-based applications that irrationally refuse to port to Python 3 – including this one. If this application fails to migrate by Python 2.7's expected end of life (EOL) on January 1, 2020, installing and hence using this application will gradually become infeasible on modern platforms. This is a Good Thing™, because insecure and incompatible applications plagued with unresolvable issues should be unusable.

It saddens the devout Pythonista in me that the main developer erroneously believes Python 3 to be:

• "Unstable." This is patently ludicrous, of course. Python 3 has preserved backward compatibility throughout its development lifecycle, excluding an early handful of unavoidable stdlib deprecations (e.g., circa Python 3.3).
• Fundamentally different from Python 2. It's not, of course. Python 3 is simply Python 2 with sane string handling + sane integer division + print() requires parens. That's it. If you know Python 2, you know Python 3.
• Harder to port Python 2 applications to than rewriting from the ground up in completely different languages. It's not, of course. While porting Python 2 to 3 can prove non-trivial for edge-case applications and libraries performing extreme string munging (e.g., parsing, pattern matching), that's absolutely not the average case experience. All else being equal, porting a Python 2 application to Python 3 is substantially simpler and saner than rewriting that application from the ground up in a non-Pythonic language.

The following ASCII art adequately summarizes my evidence-based opinion on this topic: ¯\_(ツ)_/¯

[C0rn3j]

This issue should be reopened

It was never closed.

This project won't get ported to Python 3 unless someone else does it, as kozec is rewriting it in C.

See this experimental release for example:
https://github.com/kozec/sc-controller/releases/tag/v0.4.9.4

[kozec]

expect to happen to their Python 2.7-based application when package managers and distributions begin dropping Python 2.7 due to a growing laundry list of unresolved insecurities, incompatibilities, and issues?

I expect sc-controller to not work on those distros.

¯\_(ツ)_/¯

[leycec]

It was never closed.

I was referring to this:

@kozec added the wontfix label

Effectively, this issue was closed. Would you prefer to debate meaningless semantics?

This project won't get ported to Python 3 unless someone else does it, as kozec is rewriting it in C.

C is a really low-level language to leverage here. I'm surprised that Rust, which has all the benefits but none of the obnoxious drawbacks of C (e.g., a trivially exploitable memory access model), wasn't adopted instead. Rust also has bindings to prominent high-level GUI frameworks (e.g., GTK+, Qt, WxWidgets), whereas C basically does not.

Did you mean C++, perhaps? While Rust would still be dramatically preferable, a C++-based rewrite would at least make a semblance of sense.

But... what's done is done. Mostly, I'm just delighted to hear that SC Controller will live to fight another die. C is absolutely better than nothing. Thanks for all the continued efforts, @kozec!

[DanielJoyce]

expect to happen to their Python 2.7-based application when package managers and distributions begin dropping Python 2.7 due to a growing laundry list of unresolved insecurities, incompatibilities, and issues?

I expect sc-controller to not work on those distros.

¯_(ツ)_/¯

Which means every OS in the world, as Python2 will no longer be available. You won't get bug fixes. There will be no new builds. Nothing. It's EOL full stop. No mac, no windows, no Linux distro, unless people don't upgrade beyond 2019, but then also no security fixes to Python2

[rnhmjoj]

Which means every OS in the world, as Python2 will no longer be available. You won't get bug fixes. There will be no new builds. Nothing. It's EOL full stop. No mac, no windows, no Linux distro, unless people don't upgrade beyond 2019, but then also no security fixes to Python2

Realistically python2 won't be the default install but will be around more or less forever for programs that still dependes on it.

[DanielJoyce]

Oh it will likely struggle on for a while, just no fixes, no improvements, etc. Porting to 3 is not hard...

[KAMiKAZOW]

Porting to 3 is not hard

I'll happily would package your Python3 port for openSUSE and Fedora.

[C0rn3j]

Not only is Python 2 unsupported on its own, even the libraries that sc-controller are starting to or already explicitly do not support Python 2, for example PyGObject.

However, since I made initially made this issue two years ago, there is now a working Python 3 fork that keeps up with upstream except for the Python 3 patches.

The fork is maintained by Ryochan7 over on https://github.com/Ryochan7/sc-controller
I am personally using this port and so do the packages over on AUR - AUR/sc-controller, AUR/sc-controller-git

I see that porting to C is happening, which is nice, but would you consider pulling in the patches from the Python 3 fork and switching the Python version of sc-controller to 3?

[C0rn3j]

@kozec I come to you to renew my plea.

The Python 3 fork has existed for about four years now, adapting for any upstream conflicts, while also trying not to diverge too much from upstream.
It has been tested by Arch Linux users all these years, and possibly also other distributions that I am not aware of.

Now @Ryochan7 is stepping down with maintaining the fork, and if Python 3 support is ever going to happen, now is the best time.

Would you consider pulling in the Python 3 support? There is zero conflicts at the time of writing.

The work has already been done and been through thorough testing.

[kozec]

_Hello. I'm currently unable to log in to github after their last so-called authentication upgrade. At this point, I'm just replying to every of notification emails in vague hope it will do anything._ To reply to your question, I may as well, once I'll be able to get in again.

…

On 2024-01-21 18:21, Martin wrote: @kozec <https://github.com/kozec> I come to you to renew my plea.

[C0rn3j]

@kozec
Friendly ping, have you been able to sort out your GitHub trouble?