Python vs. Perl

[Thomas Wouters]

On Thu, May 24, 2001 at 04:37:54PM -0700, Jonathan Gardner wrote:
> On Thursday 24 May 2001 01:56 pm, Thomas Wouters wrote:

> > [ Jonathan discovers Python is a great programming language ]

> I already knew that Python had to have something. This email is my quest to 
> figure out what it is.

I know, that's what my introduction says: you know it's a great programming
language ;)

> > Python is incredibly easy to extend. The API is fairly simple and very
> > powerfulnn

> This point should be stressed more and more. What use is a langauge if it 
> cannot do something useful? 

Every point should be stressed more <0.5 wink>. You can do a lot of useful
stuff in Python, without resorting to programming C extentions or wrapping
existing libraries. You might have to install a few existing extentions or
wrappers, but you don't necessarily need C knowledge to do anything useful.

> > And if that isn't enough reason, there's more! Writing code in Python is
> > very easy, because you can write code almost as fast as you can type.

> Is it true? I've heard rumors of Python programmers programming as fast as 
> they can write...

I think it was Eric Raymond who first coined that phrase. I also think it's
true -- I have it myself (and I'm a fast typer.) Not that I can type out a
program in one long haul, not at all. What I mean, and what I presume Eric
means, is that once you know what you want to write, (say, a function that
takes X and Y and does Z to them) you don't have to waste time thinking how
you have to write that function, or what builtin functionality you have to
use. Sure, you'll have to look up modules and functions in modules and
optional extentions every now and then, but for the most part, those modules
are very contained modules, with sensible functions. Using them is usually
straightforward, and very adaptable (by way of subclassing to override some
behaviour, for instance.) Take sgmllib and its derivatives, for instance.
They are complicated pieces of code, but the use of them, by subclassing and
providing hooks for the entities *you* are interested in, only, you can
start using them almost immediately, without much thought.

And the interactive interpreter makes a superb way of finding out what a
modules has or how it works, what functions expect and what they return, and
what you can do with those return objects. You don't *have* to dig around
for documentation, you can just try almost all functionality interactively.

> Counterpoint: I don't think it can always be considered a good thing to write 
> code as fast as you can type, because that means you should probably be using 
> a function or something to do what you are doing. If you are typing the same 
> thing over and over again, you aren't programming - you are typing something 
> that should be typed once and used multiple times, right?

Not everything can be done in functions. The threshhold between writing code
or calling a function is a lot higher in Python, because Python is a higher
level language (than C). You can also avoid a lot of function calling by
putting the smartness in the class, not the use of the class. For instance,
if you want to keep statistics on how your functions are used, you don't
have to change all your functions. You simply create a wrapper-class around
all your functions, that logs how and from where they are used, and then
calls the original function. (Python classes can be callable, too.)

And if you want a datatype to be converted to a string in a particular
manner, you don't code a 'print_datatype' function and call it explicitly.
No, you add a 'str' and/or 'repr' (depending on your exact needs) method,
that does the logic for you. Same thing goes for arithmatic operators,
sequence operators, and anything else you can think of.

> The programmer should ask himself, "Is this exactly what I want to be
> doing? Is this comparison a '<' or a '<='? Is this off by one?"

And you have plenty of time to think of that. You also can easily go back
and fix the error, or rethink the aproach, exactly because you don't have to
waste so much time typing needless characters ;) But another result of
Python being high-level is that you usually don't need to think about such
details, so you'll end up with a lot less worries of that kind. No need to
index loops unless you really want to. Slicing works intuitively, avoiding
off-by-one errors without effort. Strings are sliceable (unlike Perl) and
easily comparable (unlike C ;) and you can meaningfully compare nested
datatypes. The net result of all these small things is the ease of use of
Python.


> > Most of the times it isn't necessary to
> > translate it back into C 'for speed', especially if you want or need to use
> > dicts (hashes.) Python's dicts are just hard to beat.

> I know C/C++ is poorly suited for hashes/dicts/maps, BUT the STL's map is 
> AFAIK very similar to a hash/dict. I use it frequently, along with stacks, 
> lists, arrays, and strings from the STL. Besides, the problem in this aspect 
> of C/C++ is not that you can't do it, it's just that everyone keeps 
> reinventing the wheel. Once you program a hash or a dict in C once, you 
> should never have to do it again, right?

If you code them truly multi-purpose, yes. I've seen a lot of 'general
implementations' that ended up having to be modified or rewritten for a new
application, just because it wasn't general enough :)

> Also, I don't think anyone can claim that Python's dicts are better than 
> Perl's hashes or C++ STL's map. Well, maybe Perl's hashes are a little better 
> because you can do so much stuff with it in so many ways...

And Python dicts allow you to do even more :) As for 'better', I mostly
meant general-purpose/performance, not just 'more features'. You can stuff
any hashable Python object in a Python hash, both as key and as value, and
anything can be a Python object (all it needs is a small struct with the
necessary Python bookkeeping, and a pointer to the original 'thing'.) As for
the algorithm, I've been told it's efficient. Since practically everything
in Python is a dict (asside from lists, tuples and numbers, that is) and all
of Python's performance relies on the speed of Python dicts, and because Tim
Peters is on the case, I tend to believe it ;)

> As with any language, the documentation can never be better than the zealots 
> who write documentation.

Yes. Python has been blessed with Fred, who doesn't only babysit the
documentation (next to his other developerian duties), but also harasses the
rest of the developers to turn in their documentation. I know it helped in
my case ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!