Will multithreading make python less popular?

[andrew cooke]

rushenaly at gmail.com wrote:
> Hi everybody,
> I am an engineer. I am trying to improve my software development
> abilities. I have started programming with ruby. I like it very much
> but i want to add something more. According to my previous research i
> have designed a learning path for myself. It's like something below.
>       1. Ruby (Mastering as much as possible)
>       2. Python (Mastering as much as possible)
>       3. Basic C++ or Basic Java
> And the story begins here. As i search on the net,  I have found that
> because of the natural characteristics of python such as GIL, we are
> not able to write multi threaded programs. Oooops, in a kind of time
> with lots of cpu cores and we are not able to write multi threaded
> programs. That is out of fashion. How a such powerful language doesn't
> support multi threading. That is a big minus for python. But there is
> something interesting, something like multi processing. But is it a
> real alternative for multi threading. As i searched it is not, it
> requires heavy hardware requirements (lots of memory, lots of cpu
> power). Also it is not easy to implement, too much extra code...

I understand why you are asking this question - you want to learn, and
that is good - but as you say, you are a beginner, and you are focussing
on one thing that has caught your eye when there are many other issues
that are more important.

The GIL is an implementation detail.  I suspect that it could be largely
removed if there was sufficient need.  But that still wouldn't make Python
a good language for programming on multiple cores.  That's not as big a
deal as you think, because we currently DON'T KNOW what would make a good
language for programming on multiple cores - it's an open topic in the
wider community.

It may be, for example, that the best approaches for concurrent
programming require a lot of automatic pre-processing that needs static
type information.  Or that mutable state is simply too much of a problem
and pure functional programming is the only way forwards.  Both of these
would be much more serious problems for Python than the GIL.  On the other
hand, Python has inbuilt support for co-routines.  Experience gained with
that might lead towards a more actors-like solution that fits naturally
within Python.

So my first point is that you are worrying about a problem that no-one yet
know how to solve, and worrying about a small and largely irrelevant part
of that.


Second, you are committing the common mistake of over-estimating the
importance of efficiency.  Python is not a fast language; it never has
been.  That does not stop it being extremely useful.  This is largely
because when it needs to do "hard work" it delegates to C libraries.  Why
can this not apply to concurrent programming too?  Maybe the top level
logic will stay in a single thread, because that is easier to program, but
libraries will use multiple cores.

So my second point is that you are being too restrictive in considering
what a future solution might look like.


In conclusion, then, I strongly suggest you stop worrying so much about
things that you don't yet have the experience to see completely, and
instead get more experience under your belt.  That sounds more harsh than
I really mean - obviously worrying about this kind of thing is part of
learning.

Incidentally, if you already know Ruby and want to improve your abilities
I am not sure learning Python is the best use of your time.  The two
languages are very similar.  You might be better taking a huge leap to
something like Haskell or OCaml.  Or, if you want to get hands-on
experience of concurrency now, Erlang.

Andrew



> After all of that, i start to think about omiting python from my
> carrier path and directly choosing c++ or java. But i know google or
> youtube uses python very much. How can they choose a language which
> will be killed by multi threading a time in near future. I like python
> and its syntax, its flexibility.
>
> What do you think about multi threading and its effect on python. Why
> does python have such a break and what is the fix. Is it worth to make
> investment of time and money to a language it can not take advantage
> of multi cores?
>
> Thank you...
> Rushen
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>