Python vs. Perl, which is better to learn?

Patrick W quitelikely at yahoo.com.au
Wed May 8 07:48:24 EDT 2002


"James J. Besemer" <jb at cascade-sys.com> writes:

> [...]
> 
> These are but two example of computations unsuitable for Python out
> of an entire application domain where I expect Python would have a
> lot of trouble.  And this isn't even real time image processing!
> 
> [Of course, now somebody is going to point me to some Python C
> extension for processing Image data....  ;o} But my main point still
> holds unless the entire library is written in Python.  ;o]

I can only assume there's a misunderstanding between Peter and
ourselves.

I started out arguing that a mid-level language (more abstract than C,
faster than Python) is useful because there is a substantial sweet
spot between C and Python. When Aahz asked me to elaborate, I thought
more about my assumption and compared it with my actual experience,
and concluded that for everything I do these days, C and Python are
sufficient. 

In theory it still sounds reasonable that there are ... dare I say
... "some" situations in which it is convenient to have both
higher-level abstraction capabilities and excellent runtime
performance in the same language, but in practice I think those
situations are less common than I had thought. (I have used C++
extensively in the past, but in hindsight it was a very high price to
pay for runtime efficiency that probably did not justify the extra
development time and effort involved).

But the reason Python is sufficient (for me) is _because_ of the
existence of C and C++ extension modules. Without the ability to write
(or, more often, use existing) C extensions, this would be utterly
impractical. I don't think for one minute that Peter _could_ be
arguing against the proposition that Python _by itself_ is
unacceptably slow for a range of purposes wide enough to be called
"many", by reasonable people.

Where would we be if graphics/multimedia systems, OS kernels, RDBMSs,
internet infrastructure, GUI libraries, 3D modeling tools, complex
scientific simulations, or other systems too "many" to mention, were
written in _pure native Python_?

This _must_ be a misunderstanding, else one (or two, or even three) of
us are insane. ;-) 

I look forward to the day when Moore's law (or a super-intelligent
native code compiler for Python;-)) makes this a genuine
possibility. But we're a long way from that.

> > I believe quite the opposite, if it wasn't clear: it will /rarely/
> > be the case that Python is found to be too slow.
> 
> (a) Nobody ever questioned or criticized your experience.  I only
> suggested that it was not representative of all applications.
> 
> (b) Neither Patrick W nor I ever said or implied that Python "often"
> would be too slow.

When I say "Python", what I really mean is Python + Extension modules:
PyQt, PyOpenGL, Numeric, PIL, and so on. (PyGame - SDL wrapper - is a
lot of fun too!). Python is a wonderful language, and these extensions
make it possible to use it in most of the circumstances that matter to
me.

But if we are talking about "pure" Python, I'd want to upgrade "often"
to "usually". ;-)

Cheers,
P.



More information about the Python-list mailing list