GNOME Bugzilla – Bug 720324
splitlines breaks with python2
Last modified: 2019-03-23 20:50:37 UTC
On system with python2 I get this traceback whenever I run split lines. Traceback (most recent call last):
+ Trace 232911
lambda a, w: split_lines(w))],
forward_to_word_end(current_word_end)
while ord(char) and (not (char in (' ', '\t', '\n', '\r'))):
even though I really don't care about python2 anymore I'd accept a patch for this if somebody else fixes it.
Created attachment 264253 [details] [review] suggested patch Suggested patch. Please, test how it works with python3 based gedit.
Created attachment 264254 [details] [review] some additional PEP8ization fixes. Just when running my patch through flake8 I noticed some previous problems with the code.
Comment on attachment 264253 [details] [review] suggested patch Whole my branch is based on 3.8.3 tag.
Is this still relevant? I think we have other places where we explicitly use python3 things.
I think this was due to the fact rhel 7 was dropping python3 and actually gedit was built without python in that version.
(In reply to comment #6) > I think this was due to the fact rhel 7 was dropping python3 and actually gedit > was built without python in that version. Yes, that's the point ... and I thought that changes which wouldn't break Python3 but allow us to use the code with Python2 shouldn't harm anybody. That much.
I'm not against keeping py2 compatibility unless it starts to be cumbersome. I noticed that we use py3 features at least in snippets: https://git.gnome.org/browse/gedit/tree/plugins/snippets/snippets/shareddata.py#n26 Maybe would be good to run something like pyflakes on all python plugins and see what it reports.
As long as it will be patches like this I am glad to keep patching. However, when it gets more complicated, we will just loose some plugin or other functionality. We already do loost some (e.g., we don’t have libgit2 in RHEL). Perhaps we can eventually create an EPEL-7 package with additional plugins requiring packages outside of RHEL-7.
If it makes your life easier feel free to patch the 3.8 branch. For master I do not want pacthes that make the string manipulation stuff conditional to the py version. py utf8 handling is already complicated as is without supporting py2 and py3
Created attachment 309971 [details] [review] iter.get_char() returns bytes of UTF-8 encoded text. Make shell function which returns always one character long string, either bytes() or unicode() (using py3k terminology). Fixes BGO# 720324
Created attachment 309972 [details] [review] iter.get_char() returns bytes of UTF-8 encoded text. Make shell function which returns always one character long string, either bytes() or unicode() (using py3k terminology). Fixes BGO# 720324
Created attachment 309973 [details] [review] Some PEP8ization fixes.
Commited as bc45084211b36d502f2bc43e176f2cc2133f4418