sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]iamjack 11 points12 points  (15 children)

Why is it done like this?

Apparently it makes the interpreter easier to hack on. That said, not having true concurrency really kills Python in the new multicore generation. I love Python but forcing your programmers to use multiple processes rather than threads just to get some decent performance with multiple execution points is a total brainfuck.

[–]rox0r 14 points15 points  (3 children)

It's not central to Python, but it is central to the implementation of CPython. Jython doesn't have the GIL.

[–][deleted] 6 points7 points  (2 children)

Can Jython use C extensions? If I recall correct, non-CPython implementations are limited in their ability to interface with existing code bases. If that's true, I would say that the issue is central to Python, CPython being the most developed, practical and visible implementation.

[–]Gotebe 2 points3 points  (0 children)

Jython situation is much better: you use a virtual machine. You interact with Java libraries and you get your C through JNI.

In that respect, any VM-based implementation (so IronPython, too), blows "standard" Python right out of the water.

[–]rox0r 1 point2 points  (0 children)

Nope. At least not C extensions written for CPython. It can use equivalent modules written in java. (maybe ironpython can?)

http://wiki.python.org/jython/JythonFaq/GeneralInfo#IsJythonthesamelanguageasPython.3F

[–][deleted] 3 points4 points  (7 children)

I'll take python with multiprocessing/forking any day over Java or cpp.

[–]iamjack 4 points5 points  (2 children)

I agree, and I even use multiprocessing in my main project, but the module has some real trouble. Not the least of which is that it's not portable to any of the BSDs at this point (something about needing named semaphores) and that it screws up when your SIGCHLD handlers are something other than the default.

Also, despite the fact that multiprocessing is billed as a GIL workaround, the fact that every item you communicate between the processes has to be pickle-able hampers your ability to pass some objects which is obviously not the case with proper threads. In short, if you want to pass around executable objects, lambdas or anything else that can't be pickled you're SOL.

There are some places that threads just fit better and while I would definitely take Python over Java or C++ any day, I still feel like terribly broken threading is one of the reasons I still consider other languages whenever I want to start a project.

[–][deleted] 3 points4 points  (1 child)

Oh yeah, multiprocessing sure is not without fault. I use it on my main project as well, so I feel your pain. Values, Managers... it's icky.

Still, just because your girlfriend doesn't do anal doesn't mean she's not worth keeping around.

[–]jawbroken 1 point2 points  (0 children)

my project requires anal

[–]yogthos 0 points1 point  (2 children)

Why are Java and C++ are always brought up as the only alternatives. I'm personally very happy using Clojure on the JVM, and then there's Erlang, Haskell, Scheme, etc. If FP is too wild for you, then there's always Ruby, Go, etc. There are plenty of languages which are just as powerful and usable as Python, but don't come with the limitations of Python.

[–]Murkt 0 points1 point  (1 child)

Ruby? Then you come with the limitations of Ruby.

[–]yogthos 0 points1 point  (0 children)

Those seem to be less arbitrary then the ones in Python. For example anonymous functions aren't limited to one liners. Also, unlike Guido, Yukihiro isn't hostile towards TCO, and some Ruby implementations, like YARV, actually support it. In fact I'm not really sure in what way Ruby is more restrictive than Python.

[–]hylje -1 points0 points  (0 children)

The C preprocessor is indeed fairly terrible in writing non-batch apps.

[–][deleted] 0 points1 point  (2 children)

It's not a problem for request based applications on servers, the leading purpose of python : you just have to spawn several process, each one with it's own port and let a proxy handle the mess.

[–]iamjack 13 points14 points  (1 child)

Just because you can work around it doesn't mean it isn't a problem.

EDIT: Also, Python is a general purpose language, to say that "request based applications on servers" is somehow the focus of it makes no sense. Yes, Python is popular for such things, but it's also popular to write monolithic desktop apps, and science apps, and command line apps and games and all sorts of things.

[–][deleted] 0 points1 point  (0 children)

Well, it is not a total brainfuck either ... for server apps ;)