| General > General Technical Chat |
| How many people code in C these days, and if so, why? |
| << < (77/99) > >> |
| Karel:
--- Quote from: Nominal Animal on May 13, 2020, 05:59:49 pm --- --- Quote from: Karel on May 13, 2020, 05:28:02 pm --- --- Quote from: Nominal Animal on May 13, 2020, 04:22:00 pm ---That said, PyQt5 documentation is annoyingly hard to locate; --- End quote --- https://doc.qt.io/qtforpython/ https://doc.qt.io/qtforpython/api.html https://doc.qt.io/qtforpython/modules.html --- End quote --- Those are for PySide2, not PyQt5, though. --- End quote --- You are right, my mistake. |
| Nominal Animal:
No worries, Karel! I took a look at the glue interface in the python3-qtpy package (that provides a PyQt5 interface on top of PyQt5, PyQt4, or PySide), and here are the differences it smoothes over between PyQt5 and PySide2 currently: * In PySide2, using Python objects as userData in QtWidgets.QComboBox can cause Segmentation Faults. Should get fixed upstream, is also easily worked around in Python code. * QtCore has four differences between PyQt5 and PySide2: pyqtSignal, pyqtSlot, pyqtProperty, and QT_VERSION_STR in PyQt5.QtCore are Signal, Slot, Property, and __version__ in PySide2.QtCore * PySide2 doesn't have QtMultimedia * .ui file loader in PyQt5 is uic.loadUi(), but PySide2 provides a QtUiTools.QUiLoader class instead, with completely different use patterns. (python-qtpy implements a loadUi() based on the QUiLoader class on PySide2.) So, nothing alarming. This means that a Python3 Qt5 application can use either set of bindings, with just a couple of differences that are easy to fix either at application level or library level, and with the exception of uic and QtUiTools, one should be able to use either set of documentation. It is not difficult to write an application that uses whichever is available at runtime. |
| olkipukki:
--- Quote from: engrguy42 on May 13, 2020, 01:17:54 pm ---A week or so ago I tried to get back in to Python (a short journey which I outlined previously in this thread), and decided the benefit wasn't worth the cost. --- End quote --- You cannot get back to Python, you either "with us or not" >:D I would say same to C++ than need preaching and worship on daily basis, otherwise a few years gap or decade will leave it as just a line in a person list of known languages. On another side, C punched in a brain gonna stay there forever. ;D |
| Sal Ammoniac:
--- Quote from: madires on May 13, 2020, 01:51:59 pm ---I still got ... several weighty tomes from O'Reilly. >:D --- End quote --- Me too. |
| nctnico:
--- Quote from: engrguy42 on May 13, 2020, 05:02:52 pm ---I've actually (as I usually do) been giving examples to show WHY C might not be the go-to language for some in the engineering world. Real world examples. From an engineer. Others rely on vague generalizations and dismissals, and unsupported opinion on stuff I'm increasingly starting to believe they just have no experience with. --- End quote --- That is one of the hard parts of getting older. I know nothing of Python so when a younger engineer I work with regulary suggested to write an application in Python I had to take a bit of time in order not to Pavlov into 'I don't know it so it must suck. Use C++'. But I did tell him to investigate whether an application in Python is easy to deploy for customers (create and installer and so on) first. |
| Navigation |
| Message Index |
| Next page |
| Previous page |