On Thu, Sep 8, 2016 at 10:23 AM Marcus Ottosson <[email protected]> wrote:
> That's a good idea! > > I'm expecting this initial proposal to mostly get the conversation started > and iterate on it until all is well. Considering the source files are all > automatically generated by another program, I'm expecting a finite set of > edge cases. This does sound like one of them. > True. This problem can occur in an edge case. And you are write about it being a smaller surface space for problems since its auto generated. But part of the output is not auto-generated, such as any text a user may have set into widgets. That is a wide open variable. > > But, don't you feel working at the abstract tree-level is perhaps a tad > premature? Spontaneously I'd first try splitting lines at file-open, via > e.g. file.readlines(). > When it comes to modifying source code in the form of a code generator that you are providing to others, maybe its not so premature. Since you don't have control over what ends up being in the UI file, you may end up string replacing things you didn't expect. Again my example being someone using a newline character in some text of their widget. Or using words that you have set up to be replaced, where you intended for them to be modules or function names, and someone used them elsewhere. > > Another reason for going with .replace() as opposed to jumping straight > into regular expressions is readability and maintainability. I want to > enable others to understand the conversion and make changes to it where > necessary. Both re and AST carry the potential of making these options > fairly limited. > Definitely agree that adding another replace() line is trivial. And you have structured it in a way where it's at the top and easy to see. But again, doing text replacement could have unwanted effects since you have no control over doing syntax-safe replacements here. You just see a line and replace matching text. It could be possible to use the AST approach, but expose it as some kind of high level thing like making a canned set of refactor options, which get added to a list? * replace module name x with y * replace class name x with y * replace function name x with y * replace method name MyClass.x with MyClass.y I 100% agree that this is a more complicated solution than string replacements. It just depends if your refactors will get more complicated or end up being more fragile in the way they are currently done. > > Thanks, and if you have any ui files (I know you generally don't work with > them, neither do I) do let me know! > If I used UI files anymore, I would definitely share them! :-) > > On 7 Sep 2016, at 22:38, Justin Israel <[email protected]> wrote: > > Hey Marcus, > > It's a cool goal that you are trying to make everyone's workflows more > compatible and consistent. Keep it up. > > Quick question about the approach to providing the convert > functionality... Do you think splitting the file on a '\n' and doing > line-by-line string replacements is a viable approach? Could it be possible > to break the code if someone has a '\n' in some text of their widget or the > word 'PySide2"? I know its pretty specific right now with the 2 > replacements its doing, but you might end up adding more changes once you > get feedback. > Have you looked at a safe approach that parses and rewrites the AST? > Something like the rope project > <https://github.com/python-rope/rope/blob/master/docs/library.rst#performing-refactorings> > or even the ast stdlib module if you are really against dependencies? At > least you could be sure that you are only refactoring, say, the renaming of > an import. Or renaming a method of a class. > > Just throwing that out there to see if it helps. > > Justin > > On Thu, Sep 8, 2016 at 9:00 AM Marcus Ottosson <[email protected]> > wrote: > >> Hi all, >> >> Many of you have been asking about working with ui files in a way >> maintains the cross-binding benefit of Qt.py. >> >> The problem has been that: >> >> - a) PySide and PyQt implement the in-memory loading mechanism >> loadUi() differently and >> - b) Files compiled via the command-line leave artifacts behind that >> make it difficult to run the result on another binding. >> >> One suggestion was to: >> >> 1. Compile to Python via PySide2 >> 2. Convert to cross-compatible Qt.py code afterwards. >> >> So that’s what is happening here. >> >> - https://github.com/mottosso/Qt.py/pull/132 >> >> $ pyside2-uic my_ui.ui -o my_ui.py >> $ python -m Qt --convert my_ui.py >> $ cat my_ui_.py >> >> What we need now is: >> >> 1. Loads of .ui files to test with (if you have a stash, now’s the >> time to share!) >> 2. Your feedback on whether this approach is one worth pursuing >> >> Let me know what you think! >> >> Best, >> Marcus >> >> -- >> *Marcus Ottosson* >> [email protected] >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAjdKbcXmfG1LNSyA514-HC9XC3UkxtXq0fNUb6Nj%2BAJg%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAjdKbcXmfG1LNSyA514-HC9XC3UkxtXq0fNUb6Nj%2BAJg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1oNG3qmkTXajcrfnTGLvoonZJ_PBmmnjSO3kqZYVEA9Q%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1oNG3qmkTXajcrfnTGLvoonZJ_PBmmnjSO3kqZYVEA9Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/2060697B-7EFD-436A-8CDD-6E18347070E5%40gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/2060697B-7EFD-436A-8CDD-6E18347070E5%40gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0Kwga%2B3y2g_C7_DyRu0J44rx5GLFZy6uMYTPDN6-_s1Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
