[BangPypers] When *not* to use Python

[Anand Balachandran Pillai]

On Mon, Oct 25, 2010 at 7:33 AM, Dhananjay Nene <dhananjay.nene at gmail.com>wrote:

> On Wed, Oct 20, 2010 at 4:57 PM, Noufal Ibrahim <noufal at gmail.com> wrote:
>
> >
> >
> > Assuming that most of the people here are mostly python enthusiasts or
> > learners, I'm wondering when you would *not* use Python. Let's not
> > conflate this with Open Source/Closed Source etc.
> >
> >
> Python is the language which has (what in business terms is coined as) the
> right of first refusal.
>
> ie. evaluate something whether it really makes sense in python, and if not
> in python then start exploring what else.
>
> The primary reasons which may encourage me to use a language other than
> python are :
>
> a. Need for raw CPU power. Yes there are a few of such use cases. When
> purely CPU driven and when you really really need the CPU badly (which is
> probably less than 5% cases) python performance is really poor.
> b. Need for high amounts of multithreading even while being largely CPU
> bound.
>
> Yes - both situations can be handled by escaping to C from python, but I
> would much rather handle these in Java (or languages based on JVM) rather
> than C unless I am in a very constrained hardware situation.
>
> On a separate note I do believe as we start heading towards the 32 core
> situation (say in 5 yrs time) - there better exist a better solution than
> the GIL :)
>
>
 I think we should move from the thinking that concurrency <= threading
 and move over to better solutions in languages like Python which have
 better ways of solving the concurrency problem than actually having to
 create OS level threads.

 If you look at it differently, concurrency is the real problem and
threading
 is just one approach to it which is kind of resource intensive and doesn't
 work great in Python due to the GIL. But instead of GIL bashing, one should
 look at other approaches to concurrency such as generator based
co-operative
 "threading" and also look at numerous other concurrency libraries in Python
 before deciding that going the way of actual threads is his solution.

 The following article by Michele Simionato tries to drive home the same
point.
 It is a good read, except the parts where he is trying to plug his
concurrency
 library into it :)

 http://www.artima.com/weblogs/viewpost.jsp?thread=299551

 Python should go the direction shown by languages such as Erlang which has
 true user-space multitasking with light-weight "processes". It already has
 the infrastructure for it with generators etc but support for true
multitasking
 at user level should be part of the language rather than added on by
 third party libraries. Right now if one decides to explore Python
concurrency,
 the scene is truly confusing and a little scary, since there are too many
 approaches out there which also share a lot of similarities.

 Hopefully the "futures" have something to offer here :)

--Anand







>
> > --
> > ~noufal
> > http://nibrahim.net.in
> >
> > _______________________________________________
> > BangPypers mailing list
> > BangPypers at python.org
> > http://mail.python.org/mailman/listinfo/bangpypers
> >
>
>
>
> --
> --------------------------------------------------------
> blog: http://blog.dhananjaynene.com
> twitter: http://twitter.com/dnene
> _______________________________________________
> BangPypers mailing list
> BangPypers at python.org
> http://mail.python.org/mailman/listinfo/bangpypers
>



-- 
--Anand