digitaldomain / qtpyconvert Goto Github PK

I had a thought about how to increase the use, adoption and value of QtPyConvert, which in turn can help improve contribution and increase the number of eyeballs on the project.

For background, I think conversion from one binding to another is an interesting concept to many people, VFX artists and app developer alike. But the fact that they get to the README of this project and read about how it takes their precious code and converts it to a third-party, relatively unknown library such as Qt.py I think can be a little discouraging. I think most people, especially those unfamiliar with Qt.py, would be able to appreciate it further had it converted to something more "official" and known, like PySide2.

PySide2 is a stone's throw from Qt.py, so once it's there it would be a matter of search-and-replace of a few keywords (in fact, just PySide2 -> Qt). That part is actually already built into Qt.py,

python -m Qt --convert my_pyside2_project.py

I think the end result could be:

1. People who aren't interested in Qt.py could still be interested in QtPyConvert
2. Both those who are and aren't would benefit from a conversion to a binding they could later Google about and find answers for and potentially have pre-existing knowledge about as they fix any kinks coming out of the conversion.
3. Finally, as a third-step of the process, if they wanted cross-compatibility, they could convert to Qt.py

You could call it PySide2Convert. :)

Just a thought!

Hey @Ahuge,

About the name, considering there is another project with a very similar name, the difference being letter case and a missing dot - Qt.py versus qtpy - do you think it would make sense to call this project Qt.py Convert, or the like? Granted Qt.py is a tricky name to add suffixes too..

Some ideas.

• Qt.conv
• Qt.all
• Qt.pyconvert
• ConvertQt.py
• convert.Qt.py
• QtConvert.py
• convert-to-Qt.py

Not confident either of these are better, just thought I'd bring it up for discussion before any official announcements of the project (at which point it'd be a shame to change it!)

When converting a file the tool seems to append a new line to the end of the file under certain conditions - Not sure what conditions.

When it appends a new line it seems to always append a "\n" unix style new line. Even when the rest of the file may have different line endings.

1. Does the tool have to append a newline? If so.
2. Can the output file have consistent line endings that ideally match the sources line endings?

Before source:

from PySide import QtGui
if __name__ == '__main__':
    QtGui.QApplication([])

Before source as Hex:

00000010: 7274 2051 7447 7569 0d0a 6966 205f 5f6e  rt QtGui..if __n
00000020: 616d 655f 5f20 3d3d 2027 5f5f 6d61 696e  ame__ == '__main
00000030: 5f5f 273a 0d0a 2020 2020 5174 4775 692e  __':..    QtGui.
00000040: 5141 7070 6c69 6361 7469 6f6e 285b 5d29  QApplication([])

Source after:

from Qt import QtWidgets
if __name__ == '__main__':
    QtWidgets.QApplication([])

Source after as Hex:

00000010: 7457 6964 6765 7473 0d0a 6966 205f 5f6e  tWidgets..if __n
00000020: 616d 655f 5f20 3d3d 2027 5f5f 6d61 696e  ame__ == '__main
00000030: 5f5f 273a 0d0a 2020 2020 5174 5769 6467  __':..    QtWidg
00000040: 6574 732e 5141 7070 6c69 6361 7469 6f6e  ets.QApplication
00000050: 285b 5d29 0a                             ([]).

Note the 0a \n newline at the end of the file even though the file previously contained 0d0a \r\n windows style newlines.

Calling subprocess.Popen on tput falls on windows...

We should catch this

The conversion fails with the following error when you have trailing whitespace inside of an indentation block.

2018-05-08 12:24:04 - ERROR | [QtPyConvert.run]
Line 1
from PySide import QtGui
Traceback (most recent call last):
  File "Q:\Tools\eng\bjarrett\qtpyconvert\venv\lib\site-packages\qt_py_convert\run.py", line 489, in run
    red = redbaron.RedBaron(text)
  File "Q:\Tools\eng\bjarrett\qtpyconvert\venv\lib\site-packages\redbaron\redbaron.py", line 36, in __init__
    self.node_list = base_nodes.NodeList.from_fst(baron.parse(source_code), parent=self, on_attribute="root")
  File "Q:\Tools\eng\bjarrett\qtpyconvert\venv\lib\site-packages\baron\baron.py", line 49, in parse
    tokens = tokenize(source_code, False)
  File "Q:\Tools\eng\bjarrett\qtpyconvert\venv\lib\site-packages\baron\baron.py", line 70, in tokenize
    return mark_indentation(inner_group(space_group(_tokenize(group(split(pouet)), print_function))))
  File "Q:\Tools\eng\bjarrett\qtpyconvert\venv\lib\site-packages\baron\indentation_marker.py", line 24, in mark_indentation
    return list(mark_indentation_generator(sequence))
  File "Q:\Tools\eng\bjarrett\qtpyconvert\venv\lib\site-packages\baron\indentation_marker.py", line 85, in mark_indentation_generator
    the_indentation_level_changed = get_space(current) is None or get_space(current) != indentations[-1]
  File "Q:\Tools\eng\bjarrett\qtpyconvert\venv\lib\site-packages\baron\indentation_marker.py", line 38, in get_space
    if len(node) < 3 or len(node[3]) == 0:
IndexError: tuple index out of range

The source that causes the error:

from PySide import QtGui
if True:
    app = QtGui.QApplication([]) 

Note there is a trailing space after the QApplication constructor. Here's the hex for clarity

00000000: 6672 6f6d 2050 7953 6964 6520 696d 706f  from PySide impo
00000010: 7274 2051 7447 7569 0a69 6620 5472 7565  rt QtGui.if True
00000020: 3a0a 2020 2020 6170 7020 3d20 5174 4775  :.    app = QtGu
00000030: 692e 5141 7070 6c69 6361 7469 6f6e 285b  i.QApplication([
00000040: 5d29 200a                                ]) .

black has a really really high quality replacement system.

Ideally we should investigate their tokenizing system and see if we can remove our redbaron dependency.