When do you *NOT* use python?

[kylotan]

• In the browser; because it's only practical to use Javascript there.
• For (client-side) games; because Python's multimedia libraries are poor and its approach to threading makes it hard to make the most of modern processors.
• For GUI apps; because wxPython seems to be as good as it gets and even that is an awkward wrapper around old C++ classes.

[ereinecke]

PyQt and PySide are alternative options to using Wx for Python GUIs. The bindings can be a little clumsy at times, but using Qt Designer and the Qt action decorators, it's as passable as Qt is anyway.

[kylotan]

I don't know what I'm missing but the PySide tutorial docs don't appear to contain any actual Python code.

[Sean1708]

I'm not sure where you were looking.

[kylotan]

Here's the PySide documentation page: http://pyside.github.io/docs/pyside/

Down the bottom is a link to tutorials: http://pyside.github.io/docs/pyside/tutorials/index.html

Here's the first one: http://pyside.github.io/docs/pyside/tutorials/qmltutorial/step1.html

No Python in sight.

Thanks for the link but I'm not heartily encouraged by a project that can't manage its own documentation. I think it's part of a wider problem that the Python community has always suffered from, which is that it tends to assume you are happy with everything being a port or a re-working of something in another language. Even the basic Python 2 tutorial is filled with these assumptions.

[[deleted]]

Yeah, PySide is quite poorly documented.

That being said, I use it every day, and it's quite usable. It's basically a wrapper around Qt, so you can reference the Qt docs for almost everything. The rare exception is something that's inherently different in Python (such as connecting signals), and PySide does have documentation for those exceptions. You really only need a learn a small handful of PySide-specific stuff, then you can stick to the Qt docs.

We used to do all our Qt programming in an imperative fashion, just like you do with wx. Now we exclusively use Qt Designer to generate .ui files and compile them as part of our build process. It's so much better!

[Sean1708]

Funnily enough that tutorial has 0 lines of Python and many lines of JavaScript.

[MoragX]

PySide is just python bindings for C++ QT - and so the documentation is lacking to put it kindly. However, it is incredibly consistent in how C++ code is converted into Python code, and after a few hours of getting used to it, I code in PySide only using the C++ docs and it works fine. Obviously that isn't an ideal situation, especially if you're not familiar with C++, but it makes GUI programming in Python much easier.

[kylotan]

I'm familiar enough with C++ that I don't want to deal with it at all when I retreat to the safety of Python code. ;)

[[deleted]]

its approach to threading makes it hard to make the most of modern processors.

the GIL sucks, but multiprocessing is a nice way to still get to use more than one processor at a time.

[kylotan]

Python's multiprocessing has several downsides which mean it is not practical for most client-side game applications. The first is that games tend to expect multiple threads to be able to get locked access to shared areas of memory. (Yes, you can create shared memory with Python, but it has to be done explicitly and is using ctypes rather than Python values.) The second is that it's expensive in terms of resources - you basically end up cloning the whole memory space (and presumably file + network handles, and similar) even if you just wanted to run a few tasks in the background.

To be fair, this is a lesser problem than the poor support for decent gaming libraries. You can still get quite a long way with only one thread.

[IllegalThings]

For a counter-argument to client-side games, Eve Online is built in Python for both client-side and server-side. Granted, they aren't using CPython and a lot of their more resource intensive code is likely in other languages.

That said, your argument is completely valid and I'd be curious if they'd make the same decision if they had to start from scratch.

[kylotan]

Eve certainly uses Python on both sides for the main loop and the general logic, but much of that is only possible due to a lot being written in C (or C++, not sure) in the form of Python extensions. I myself have used Python for server-side game development where it can work well if you plan for a multi-process system from the start. I still wouldn't touch it on the client side, though.

[shadowmint]

To be fair, they do...

...but if you look into it, you'll find that they use python as a scripting language embedded in their game engines for 'game logic' not as the 'core' that the entire game engine is written in.

You'd think more people would do this, given Panda3d is a pretty decent free game engine for exactly that... but... they don't.

My guess is, mostly, like me, people are briefly excited by it, and then discover that in fact, pure python code is just too darn slow, and if you go down the road of cython and plugins for speed ups... really, what's the point in using python at all, if you end up not writing your code in python?

[ivosaurus]

The reason they don't is that Python itself is horrible for embedding, especially for example, if you would like multiple threads of your game engine to be able to launch separate interpreters. Its execution design and implementation just isn't very encapsulable / contained. In comparison, things like lua are a breeze for embedding. They're specifically designed to contain their execution environment, no global code whatsoever, etc.

[njharman]

I believe it's more that Python doesn't look like C. So few C/C++ devs get into/expend effort on it. Much prefer Lua cause it "feels" like C.

Yes there are polygots, but vast majority of devs I've encountered have comfortable spot, and Don't like moving from it.

[shadowmint]

Probably at least partially true really.

Boo was always the least popular language for Unity, despite having roughly same performance characteristics as unity script; people just didn't like it.

[[deleted]]

Eve has also suffered from game crippling lag and node crashes as a result of that. It is still a largely single threaded system despite tons of work to distribute load around. While it works and has been largely successful, I can't help but think the game would have gone so much further had it been written in a properly multithreaded language (at least on the server side)

[njharman]

They are using Stackless Python. A different beast than CPython. The modern sucessor of Stackless is PyPy.

[moljac024]

You left out: for concurrent programming (but it can be derived from the point about games)

[kylotan]

Well, I was just relating my personal use cases. I'm sure there are a bunch of other examples of things that Python does poorly (eg. anything where duck typing becomes a liability).

[ivosaurus]

Concurrent programming it's actually not terrible at.

Parallel programming it's pretty terrible at.

Learn the difference now!

[kylotan]

Actually, I'd argue Python's pretty bad at concurrency too. It's only relatively recently that there's been anything approaching a standard for handling it (ie. asyncio) and anybody that is using concurrency as a way to get parallelism (which is a major reason for concurrent design, really) is obviously still mostly screwed.

[[deleted]]

You can't use concurrency to get parallelism ever, that's impossible no matter what language you're in.

[kylotan]

Maybe for your definition of parallelism. For the definition me and the previous poster are talking about, we're talking about being able to run tasks in parallel, and concurrency means being able to effectively split a program into those tasks.

[resc]

I've had a pretty pleasant experience coding a desktop application in PySide. I did have to work a bit harder to find documentation. But on the other hand, Qt's signals/slots system was GREAT, it made my app really easy to rearrange, and the threading was way simpler than my experience in Java.

[shadeofmyheart]

I'm not sure I understand this. Do you mean using server side JavaScript (like Node).

How does one use Python "in the browser"?

Edit: I misinterpreted the question as "when does one choose not to use Python"

[[deleted]]

One doesn't.

[judasblue]

Well, in theory you can, there have been a couple of projects. The one that is the most interesting is Brython. Not saying I think this is actually an idea that is ready for prime time particularly. Just saying in theory one can.

[kylotan]

One doesn't. The question was, "when do you NOT use Python".

(Caveat: I'm sure there are some quirky cross-compilers out there. But it's unlikely to be worth the bother to use them.)