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.

¯\_(ツ)_/¯