51–60 of 176 posts
Sadly, we still don't have the seamless UI building functionality Delphi had 15 years ago, allowing making a fairly advanced desktop app in a day. Jumping between Qt Designer and IDE back and forth is still an order of magnitude more complicated than it needs to be.
I just took a look at delphi. What’s so unique about its ui builder?
Earlier quoted context omitted.
It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time. At the end of the day, PEP8 is just a convention and we're free to break with it where it makes sense. Imho, this is such a case.
> It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time. Those are things that make it better for the library maintainers, sure, but presenting (and documenting) an API that is idiomatic, both in structure and behavior, for the host language is better for library consumers, as it doesn't force them to con…
There are already examples in the "Hello Qt" which are easily solvable:
app = QApplication([])
# should read instead:
app = QApplication()
app.exec_()
# should be instead
app.exec()
These small things make the difference.
Earlier quoted context omitted.
> It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time. Those are things that make it better for the library maintainers, sure, but presenting (and documenting) an API that is idiomatic, both in structure and behavior, for the host language is better for library consumers, as it doesn't force them to con…
Agree with having a pythonic API. There are already examples in the "Hello Qt" which are easily solvable: app = QApplication([]) # should read instead: app = QApplication() where the empty list is the default argument. Also app.exec_() # should be instead app.exec() as it is also in the C++ API. These small things make the difference.
Earlier quoted context omitted.
> It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time. Those are things that make it better for the library maintainers, sure, but presenting (and documenting) an API that is idiomatic, both in structure and behavior, for the host language is better for library consumers, as it doesn't force them to con…
Agree with having a pythonic API. There are already examples in the "Hello Qt" which are easily solvable: app = QApplication([]) # should read instead: app = QApplication() where the empty list is the default argument. Also app.exec_() # should be instead app.exec() as it is also in the C++ API. These small things make the difference.
I agree on your first example.
Does anyone know of a Qt binding for Python that is actually pythonic (as in follows PEP 8)? Both PyQt and Pyside are just one-to-one wrappers that use C-style naming for everything. I find that really strange. The same holds for most other GUI libraries, like WxPython. It seems the only real pythonic GUI libraries are Tkinter and PyGobject.
It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time. At the end of the day, PEP8 is just a convention and we're free to break with it where it makes sense. Imho, this is such a case.
I find PyQt to be Pythonic in all the ways that count, e.g. replacing `self.setFoo(bar)` with `self.foo = bar`, decorators for signals/slots, etc.
Earlier quoted context omitted.
It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time. At the end of the day, PEP8 is just a convention and we're free to break with it where it makes sense. Imho, this is such a case.
> It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time. Those are things that make it better for the library maintainers, sure, but presenting (and documenting) an API that is idiomatic, both in structure and behavior, for the host language is better for library consumers, as it doesn't force them to con…
This seems to be the successor for PySide that supports Qt 5. The old PySide died some years ago and only PyQt was offering Qt 5 support. Due to some details PyQt was never officially supported by Qt. Is PySide2 now officially supported by Qt?
The owners of PyQt (Riverbank) depend on that product to survive; whereas Qt has bigger fish to fry most of the time. The incentives are very different.
I used PyQt5 quite successfully a while back. This looks very similar. What is actually new here?
PyQt is not PySide. Qt (the foundation) does not officially support PyQt. PySide (the old one) did not support Qt5. PySide2 does support Qt5.
But the project owners (Riverbank) support PyQt just fine, and arguably much better than Qt ever supported PySide in any previous incarnation.
Earlier quoted context omitted.
> It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time. Those are things that make it better for the library maintainers, sure, but presenting (and documenting) an API that is idiomatic, both in structure and behavior, for the host language is better for library consumers, as it doesn't force them to con…
Parent was taking about PEP8, which is purely syntactic. I would argue that has very little to do with structure and behaviour. It's completely superficial.
Earlier quoted context omitted.
And it's generally worth it. PyQt has been great, and I find the messaging from Pyside a little offputting -- "finally, Qt for Python." Pyside, you weren't there when I needed you, and now you're back and you want to pretend like we don't have history?
When did you need it? Because PySide is not new.
Meanwhile, PyQt just chugged along just fine. Riverbank must keep focusing on it all the time or it will die. The incentives are very different.