Hacker News Reader

Hacker News

Comment by fingerprinter | Hacker News Reader

Full thread

fingerprinter

I didn't realize there was a fight going on.

It seems like this is where everyone settled and is a good solution:

Virtualenv + pip for development

system wide (apt, dpkg) python etc for system tools and packages.

This makes sense to me. Keep your personal code sandboxed from your system tools.

As an aside, I know there are quite a few tools and programs in both Debian and Ubuntu written in Python. I wonder if we'll look back in 5-10 years and realize/think this was a mistake. Particularly for UI code. I love me some Python, but I cringe every time I have to interact with a Python GUI application.

View on HN

> I cringe every time I have to interact with a Python GUI application.

How are Python GUI applications worse than C GUI applications?

Yeah, both wx & QT applications in Python look exactly like their C/C++ counterparts for the most part.

Performance

Performance (I assume speed) for GUIs? When do you need that? Most people are fine with web apps and their internet latency speed.

If you mean a scenario, where you click a button and the app freezes for a few seconds then this is an architecture problem. Whateven happens should happen asynchronously to the GUI. This can be right and wrong in Python and in C.

I have a python GUI app. When I press a button, it probably takes a few tens of milliseconds to chew on it. I suspect it could be done faster with other tools, but I doubt I'd notice it.

As for the actual work being done behind the GUI, that's a different matter.

I never noticed any performance problem with Python-based GUI programs. Well, calibre's start-up time is a little too long, but once it's running I don't notice any slowness. If you have a special program in mind, would you explain a bit about it?

I use Ubuntu, so I don't know if these are in Debian as well, but Jockey and Ubuntu Software Center come to mind.

My main issue with them is the common symptom where both "hang" or "freeze" for a few seconds. Visually this can look like the window gets grayed out for a bit (common in Jockey) or it it is just stuck for a few seconds with no clear indication anything is happening (more common in Software Center).

EDIT: I should note that I've previously written a few PyGTK apps and have recently started writing Ubuntu Touch apps via their Ubuntu SDK (Qt/QML). I've found that Qt/QML/Ubuntu SDK is a much better experience in both writing the app and the responsiveness of the resulting application. And I'm by no means proficient in QML, I'm just starting out.

This is probably psychosomatic. Python GUI libraries are usually a thin layer on top of C/C++ libraries like GTK and Qt, so the drawing and input handling is all happening quickly.

on the .deb files for deployment agreed - Hynek's rant on this solidified the meme about two years ago. there is a parcel project and my own pyholodeck (up but not exactly working yet - pre alpha, should get sometime this week)

mostly I think we shall cringe that we thought complex operations could benefit from a GUI - it's either a matter of education or curation. either we teach you to use the complicated .conf file or we make sure that the setup and default are so intelligent it's like a mac

It's not clear cut like that. Sometimes your application will depend on a particular release of lxml or PIL, while the base system is already providing one (because it's a dependency of something else). Or sometimes you can't install python packages that require compiling on your server because it doesn't have gcc and family installed (a common security practice). That's when apt/python packaging starts falling apart.

I have to say, I've not had the issue where I don't have nearly full control of a server. I do imagine this would provide many different challenges overall.

Does PIL need to be compiled when you use it via Pip (I'm not familiar with PIL, tbh)? Can you just install those via pip and be done with it? So far using virtualenv + pip, I've not encountered a system library vs project dependency clash...but maybe I've just been lucky.

And what do you do if the dpkg'd version is a year older than the one you'd like to use and is available in pypi? Install just that one via pip? But what if that package has dependencies newer than what's installable with apt?

In the end you find yourself installing as much as possible with pip, and resort to apt for the really heavy stuff like numpy.

And what for production? A lot of the argument seems to be around the dev/ops divide.

There's probably a bunch of different ways to do this, but I just use virtualenv + pip still.

Here's some documentation on Django (as an example): https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/...

I think a more interesting question is not around the python side of things, but the infrastructure. Do you compile all your infra tools from source or do you use the system packages? Like, if you want to use RabbitMQ, if debian/Ubuntu provides it, would you use that or grab the source?

I personally prefer to use the debian/ubuntu ones in these cases unless they are horribly outdated, which isn't generally the case. I can understand, however, if someone thinks this is a terrible idea.

Reply on news.ycombinator.com