14 ms·
Thoughts on the future of Python and graphical interfaces
- hatmatrix 10y agoThere is something to be said about the UI approach of R's Shiny interface. As a scientist with limited budget for dedicated IT development, I can focus on creating the content and the UI can easily be built to access it functionality.
- microcolonel 10y agoWithout a miracle, it seems like a bit of a lost cause. I see some pretty glaring reasons why Python has not taken off in writing GUIs, especially on mobile. 1. The Python runtime is not very easy to embed on iOS and Android, and the sheer number of bindings needed to make it worth doing is immense. 2. Python's runtime is completely and utterly incapable of threading. Threading being almost essential to any decent user interface, this whole idea falls flat. 3. If the other two problems weren't enough, Python's single-threaded performance is really not great either. On resource-constrained systems (think phones) this hits doubly hard.
- wiz21 10y agowho said Python mus be running client side ?
- matjazzz 10y agoI wouldn't agree on points 2 and 3. I find multiprocessing routines really easy to implement and they work as they should. However, I have no experience with threading in other languages so I might be missing out ... With regards to performance, I found that one can produce very fast routines through use of specialized libraries for specific tasks, such as numpy etc. There are also great visualization tools, such as pyqtgraph which are blazing fast, at least, in my view, compared to any web interface. I have been skeptical about the html/js interface so far, because I am concerned with how fast large amounts of data can be surfaced from Python data models to HTML plots. That said, I share the Python UI pain :/ As of now, I am stuck with QT and cx_freeze for desktop app development and the whole thing feels very medieval. The QT library in itself is great but at the same time it does not feel very "python". cx_freeze requires constant tinkering and makes debugging very hard at times. What do HN users use for building GUIs for Python? :)
- nzjrs 10y agoI use gtk via pygobject. I find it feels the most pythonic. Cross platform remains difficult however.
- infinite8s 10y agoWhile it feels more pythonic, it does not look at all native on most platforms.
- tluyben2 10y ago1. Using the work done by the Kivy guys fixes that need; you can easily run on mobile. With a native webview on both you can use OP his new and shiny GUI browser framework from Kivy without much issue.
- notzorbo3 10y ago> Python's runtime is completely and utterly incapable of threading. Threading being almost essential to any decent user interface, this whole idea falls flat. This is just plain wrong and the fact that many GUI programs are written in Python (dropbox, NetworkManager, Zim desktop wiki, etc) should be evidence of that. In fact, most people don't even realize these are written in Python. Yes, Python has the GIL. No, that does not mean it can't do multithreading. It merely means it can't do parallel processing on multiple cores with just threading. But that is by no means a requirement for multithreading, especially regarding GUIs.
- shoyer 10y ago> 2. Python's runtime is completely and utterly incapable of threading. Threading being almost essential to any decent user interface, this whole idea falls flat This simply isn't true. Python has the GIL, but that doesn't stop it from making use of threads for IO or CPU bound tasks that release the GIL (using extension modules). There are lots of libraries for multi-threaded IO in Python (e.g., gevent, Twisted, Tornado, asyncio), and, not surprisingly, they are very widely used for web programming.
- toyg 10y agoGlossing over the threading misinformation, Python's requirements are not particularly different from the likes of C#, but unlike C# there is nobody with the commercial incentive and necessary scale to do the hard work. The only platform where Python could flourish without effort was Maemo, and for the very brief time that project lived, it did exactly that.
- zeveb 10y ago> 2. Python's runtime is completely and utterly incapable of threading. Threading being almost essential to any decent user interface, this whole idea falls flat. While you're AFAIK correct about running Python on mobile devices, and I think anyone will admit that Python's performance has never been great, one can have a great UI without threads: use coroutines and channels instead. Fortunately, Python does have coroutines, and a channel library can be built in the fashion of Lua's channel library (https://github.com/majek/lua-channels https://github.com/majek/lua-channels). I don't know if anyone has done it yet, I'll grant, but a cursory look suggests that it's possible. The basic idea is that one would spawn a coroutine to handle each UI element, and the coroutines would send messages to one another on channels. I've no idea how fast it would be (at a guess: terrible), but it should work.
- throwaway13337 10y agoThis article only talks about one aspect of the larger problem in UI Development - the webification of everything. It's good that we've finally been able to agree on a common set of tools to make UIs, it's just too bad it had to be this one. The HTML/JS/CSS/DOM mess is a pretty terrible solution that we seem to be stuck with. History is peppered with UI authoring tools that were better but stewarded by companies that held to tight licensing that stunted their growth. Hypercard, delphi, adobe flash (and FLEX - which looks a lot like react), even unity has more intuitive wysiwyg UI tools that could have proved versatile with the right stewardship. The difference is vertical integration. These companies made their tools complete solutions and often went so far as to put virtual machines on everything to interpret them correctly every time. The article's author touches on the license problem with python's own pretty damn good QT lib. If only someone could find a way to make a good tool without fucking up licensing.
- toyg 10y agoThe licensing issue with PyQt is very simple: it's the main source of revenue for Riverbank, a small UK company founded by PyQt's author, Phil Thompson. He can't give it away for free because it's literally his livelihood. He does a great job of evolving and updating the wrappers -- just ask how "easy" that is to the PySide authors, which are supposed to do the same job and have been struggling (technically and financially) ever since their project lost "free money" when Nokia died. The licensing for Qt itself is very simple: if you redistribute and don't go GPL, you have to pay. It's one of the fairest arrangements out there. PyQt has similar terms.
- throwaway13337 10y agoI'm not implying these vendors should work for free. Just that they could have been more creative with the way they monetized. The way that makes most sense to me is charging for the authoring tools and making the language/VM completely open (e.g. MIT license). Maybe that's too idealistic?
- infinite8s 10y ago
- simula67 10y agoI would like to see more discussion about the speed of Python for user facing applications. Users can perceive delays of upto 100ms ( http://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay http://stackoverflow.com/questions/536300/what-is-the-shorte... ). # time yum real 0m2.147s user 0m1.276s sys 0m0.772s # time apt-get 0.00s user 0.00s system 91% cpu 0.004 total
- andybak 10y agoI'm not sure you can throw the 100ms figure around without context - and especially not when making the jump to discussing console applications. The psychology of button clicking is very different to the psychology of command typing.
- simula67 10y agoIt is true that console applications would have different constraints. But GUI applications written in Python, like 'Ubuntu Software Center', were also perceptibly slow last time I checked. yum vs apt-get was a quick comparison I could show. I find yum very annoying compared to apt-get/pacman. The author wants more Pythonic GUI apps because s/he thinks it produces more readable code. It has been argued that such code can be slower ( http://lukauskas.co.uk/articles/2014/02/13/why-your-python-runs-slow-part-1-data-structures/ http://lukauskas.co.uk/articles/2014/02/13/why-your-python-r... ) and maybe it will lead to trading too much developer pleasure for user pleasure.
- andybak 10y ago> maybe it will lead to trading too much developer pleasure for user pleasure. In many cases - developer time or cost is the constraint. Therefore it might be the difference between something existing and not existing. It's a similar argument with 'native vs other' on mobile. Currently native apps are obviously better in terms of speed and overall quality. However - much non-native software simply wouldn't exist if there wasn't a rapid, low-barrier to entry development option.
- aavotins 10y agoQuote: "I want to write Python code that spits out the HTML and JavaScript required for these interfaces and I still want to handle all the logic in Python." Substitute Python with PHP and it feels like 2004 again. I think we all agreed a long time ago that decoupling presentation layer from business logic was a good thing, no?
- gaius 10y agoYou can do that with Bokeh.
- andybak 10y agoBokeh has a very interesting approach. It has three levels you can jump between: 1. Just write Python and get interactive graphs 2. Write Python and small snippets of embedded js when (1) is too limiting 3. Write Python to generate the datasets, and proper javascript via bokeh.js if you need to dig in deep. And as the project matures - the number of reasons to jump from 1 to 2 to 3 will become less. I'd like to see a similar approach applied to general UI development. It's a great example of "make the easy things easy, and the hard things possible".
- tluyben2 10y agoBut you can still separate them in the same language. He does not like the html/css/js combi and neither do I. I would like to develop all in 1 language (whatever that language may be); that has nothing to do with decoupling presentation from business logic.
- andybak 10y agoThere's no reason that generating html and css necessarily implies 'coupling' in the bad sense. It does however mean an extra (and potentially complex) layer of abstraction. However that's a deal I'd consider taking if it means I could write more Python more of the time.
- robmcm 10y agoI think the argument is that with "single page applications" you duplicate a lot of your business logic in fat clients. This thinking is essentially a return to circa 2004 but with today's APIs like websockets. I think you will see applications that are quite generic (look and feel) and very chatty, but quick to develop.
- nzjrs 10y agoI would suggest everyone check out remi, which feels like a desktop UI library and renders in the browser https://github.com/dddomodossola/remi https://github.com/dddomodossola/remi
- viperscape 10y agoTake a look at earl grey lang, specifically document building dsl it has: http://www.earl-grey.io/#documentbuilding http://www.earl-grey.io/#documentbuilding
- spo81rty 10y agoWhat about using Iron Python to make a Windows UI app?
- Chris2048 10y agoWhat about : http://nucleic.github.io/enaml/docs/ http://nucleic.github.io/enaml/docs/
- infinite8s 10y agoEnaml hasn't seen any sustained development since 2014.
- phantom_oracle 10y agoIs there another option for building native interfaces that are cross-platform (let's say desktop for now: so just Linux, Win and OSX)? Instead of the webapp-as-desktop-app does there exist a language/IDE/tool that has a friendlier license for building native desktop apps?
- infinite8s 10y agoWhat do you mean by friendlier? Meaning you want to build a commercial app without paying any licensing fees?
- spriggan3 10y agoPython supports Gtk+3 and anything that run on GObjects. Let me tell you that it's quite a lot of libraries you can use from Python. Deluge ( torrent client is written with Python and Gtk+3 ).
- mkj 10y agoIt seems the author didn't look far if they just said "PyQt, licensing too hard" (fair enough) without noticing PySide.
- dbcurtis 10y agoTo be fair, the transition to Qt5 has been a slog for pyside, but momentum recently picked up now that the Qt team has the resources to support the effort officially.
- sethish 10y ago> in fact I think the very idea of Django and similar frameworks should go away. I find templates cumbersome, hard to read and non-pythonic. This is incredibly dismissive and hardly a well functioning argument. I don't like to edit html templates, therefor web frameworks shouldn't exist.
- dfox 10y agoI think that the point here is that html templates are oriented towards writing things that are primarily web sites, and not data-heavy and UI-heavy applications that happen to use web browser as thin client. I'm somehow trying to solve this problem by using jinja2 macros to the point of abuse and by having relatively large amount of python code that handles generating complex HTML (navigation, tables, forms, widgets...).
- VT_Drew 10y agofor tables use https://github.com/bradleyayers/django-tables2 https://github.com/bradleyayers/django-tables2 for forms use https://github.com/gregmuellegger/django-floppyforms https://github.com/gregmuellegger/django-floppyforms For navigation just use something like http://purecss.io/menus/ http://purecss.io/menus/
- cafard 10y agowxWindows with PythonCard wasn't at all hard to use, and to my eye looked a lot better than Tk. But wxWindows looked to be dormant last time I checked.
- deleted 10y ago[deleted]
- voyou 10y ago"I want to write Python code that spits out the HTML and JavaScript required for these interfaces and I still want to handle all the logic in Python." This sounds a lot like PyJS: http://pyjs.org/ http://pyjs.org/
- jventura 10y agoI used pyjs (pyjamas) for some personal projects and I liked it a lot. Unfortunately it got stuck in time, and in 2012 the current maintainers did a bad political move, and left the project in even worse shape than it was. Nowadays, I wouldn't consider pyjs to build anything relevant..
- pbreit 10y agoDoes anyone have definitive information on how all the Slack clients are built?