Why I love Python (warning: rambling)

[KefX]

I've been following the group a bit (somewhat loosely; discussions involving
other languages or advanced concepts kind of lose me), and I see all this
negativity (OMG Python's lambda is borken roflol, use teh othar langauge). I as
a relative newcomer to Python pay little heed to the criticism, though. A few
things in Python are counterintuitive, yes, but what language doesn't have such
things? And I feel that one can master the syntax of Python in far less time
than one can for many other language (at least this was true for me). For
little reason other than to take a break from all the trolls, I've decided I'd
write why I love Python. Most of you will already know these things, but for
the other newbies and the outsiders who need to be convinced...

I come from mostly a C background. Now, let's get something straight here: I
never had a real job programming, nor have I ever completed any large programs
(however many times I have made large portions of programs). But I've still
written a substantial amount of code in some languages, including testing and
such, and I also have many books. So I still know what I like in a language.

Here are the languages I've learned: BASIC (several variants, including
QBasic), Visual Basic, C, C++, D, Small, Java, Python, Turbo Pascal, Perl,
Assembly (x86, Z80, 6502), and there's always one or three that I forget. I was
tempted to add Delphi, but I didn't really learn much of it that Turbo Pascal
didn't have. I probably will learn LISP or Ruby next. Of course, I know some of
these better than others...I've forgotten much of Perl and Pascal (however some
documentation is probably all I'd need to get up to speed).

I actually learned C as a stepping stone to C++, sort of...eventually I grasped
the OOP concepts and had been writing full-fledged C++ for some years before I
realized that I hate C++. That language is a monster. It looks easier to
understand than it is. Some of the things in my advanced C++ texts give me
nightmares. I'm not saying C++ users are stupid for using C++ or anything like
that -- it's just not for me. I was in AP Computer Science for three years in
high school (because it was so easy, and gave me time at school to code REAL
stuff)...some of the things that they don't teach in the book kind of freak me
out (their teaching of exception-handling was atrocious, for instance). I still
use C++, in fact one of my current projects embeds Python into it, but I don't
have to like it. C++ may well be the right language for certain jobs...I try
to stay away from those jobs.

But I grew dissatisfied with C, too, as a general-purpose language because it's
more on the opposite end of the scale. You have to type so much just to do
something simple sometimes. And doing OOP code in C is a hassle. Not doing OOP
code in C sometimes leads to inflexibility...meaning C's not the tool for that
job, unless you have to have it hyper-omega-ultra-fast while still
portable...I'm more of a designer than a programmer. I like being able to think
something and just typing it out. I don't want to do pointer arithmetic, I want
to just implement my ideas.

So I became a Java nut for some time. Java, when it comes down to it, its
taking both C and C++ and fixing anything that is too complex or too low-level
(and then trying to make it portable). But it has some oddities...it wants to
be type-strict, but if you want an abstract container, you have to cast to
object. Huh? It looks to me like in Java, you're doing high-level things using
low-level thinking. Sometimes it's too easy to do what you want...other times
it's near impossible. Again, I'm not bashing any of these languages, I just
don't like them as general-purpose tools.

I was led to try D sometime (http://www.digitalmars.com/d/). I'd always been
interested in it and tried a recent version of the language and compiler. Nope.
Doesn't click for me...it seems as schizophrenic as C++, both in its goals and
in its implementation. I liked it at first, but...nah.

You'll notice that these languages all share a common style of syntax and
semantics. C++ is based on C, and Java is indirectly based on C++, and D is
based on all of the above. I decided I just didn't like the syntax and
semantics, and one day when I needed to write a script to process a text file
and spit out the result in another file, I knew I didn't want to use one of
these languages. I decided to try Python.

I'd already tried to learn Perl by this point. I sort of succeeded. But Perl's
so hairy that if you put it in the forest, people will have their definitive
proof of the existence of the sasquatch. I can't read Perl code even if I wrote
it. So while I respect it, as I respect most languages, as a specific-purpose
language, I didn't really want to bother with it for this task, as I wanted to
try a general-purpose language, other than the "general-purpose" languages I
already knew. So Python it is.

Wow.

This is the language I've always wanted to see. Bad indentation is nearly
non-existent (if you've seen an AP Computer Science classroom and took a look
at the C++/Java code on the students' monitors, you WILL shriek with horror at
half of it). The language and the library complement each other well, and if
you can't do it simply with the language, you probably can with the (massive)
library. Types are rendered almost unimportant. Python, to put it simply, asks
the programmer that crucial question: "What is the ESSENCE of the problem?"
Rarely do I find myself wrestling with the language's syntax. I feel I've
mostly mastered the syntax and semantics and I needed little more than the
Reference Manual and the Python Tutorial!

I personally feel that the performance worries that put C and C++ as the
industry standard (with Java not far behind because "it looks like C++ and it's
not THAT slow") are becoming increasingly unwarranted. It's kind of ironic for
me to say this as I have a current program I'm working on where Python is
certainly running too slow for me (though I'm working on that). But that's a
special case, in this case, digital signal processing.

Of course, I still have my own (minor) issues with Python. The way name binding
works is kind of odd to me, but it does make sense to me more often than not,
and I'm getting used to it quickly, unlike some trolls^H^H^H^H^H^Hpeople I
know. The immutability of strings is also kind of strange, but I understand why
it's done...namely so people don't accidentally do this:

foo = 'this is a string'
bar = foo
foo[:4] = 'that'
print bar # Prints 'that is a string'!

And instead the interpreter provides a helpful traceback on line 3 saying in
essence 'You can't do that'. (Then people who don't understand why will then
rail about it on the newsgroup instead of discovering that foo = 'that' +
foo[4:] produces the intended result...) I don't think there's anything
preventing anybody from making a 'mutable string' class, though, especially
with how we can inherit from basic types, though I wouldn't be sure of the
wiseness of doing that. Wait. Hold on a minute.

[checks to make sure standard library has no mutable string class...crap! There
is: UserString.MutableString, though it's semi-deprecated. ]

Yup. That library does have everything. Anyway, to get back to what I was
saying, Python has some oddities...but hey, what language doesn't?...and these
oddities are a lot easier for me to put up with than the ones I've found in
other languages.

I was going to say more, but I've rambled enough for one night/morning/whatever
it is now...time to get back to actually coding, and then sleeping. I hope I
didn't make myself, or anybody else, look too foolish.

- Kef

 

[Oren Tirosh]

.

I probably will learn LISP or Ruby next.

Ruby is a great language but it will not change anything in the way you
think about programming when you already know Python; LISP will.

If you already knew Ruby I could probably say that learning Python will
not change anything in the way you think about programming. Hanging out
on python-list will change the way you think about programmers, though.

Oren

 

[KefX]

Hanging out on python-list will change the way you think about programmers,
though.

In a good or a bad way?

- Kef

 

[Andy Jewell]

Kef,

Funny, a lot of people make testemonials about Python, just like you have...

(I'm sure people also make testimonials about any given language, too).

I think the difference is the way people tend to come to Python: search the
archives and you'll see hundreds of instances of 'seekers' having 'come
home'.

Python seems to engender an almost 'born again programmer' style response from
most who bother to try to master it. Most say that when they eventually /do/
take the step, the transition is surprisingly easy - Guido's claim in the
tutorial that you can learn most of what you need to know to become
productive in an afternoon is not too far from the truth.

When it comes to the finer, weirder, and (dare I say) darker secrets of
Python, c.l.py is the place to learn about them. You can learn everything
from 'just for fun' tricks that you'd never dream of incorporating into a
real program to powerful magic that makes your program run n-times faster,
without losing readability.

Still, the guys here are generally quite firmly grounded on reality; there are
certain scenarios where you just *wouldn't* employ Python, and the peeps here
in c.l.py will freely admit that. For some, the obvious answer is to write
the appropriate parts in, say, C and use Python as a 'wrapper' around that,
saving the bits that Python is good at for Python and the bits that C is good
at for C. Others would advocate simply using the *right* language in the
first place. I think a realistic motto would be "one size *does not* fit
all".

Still, given the 'performance limitations' of python, I've not really found it
to be too deficient at the things I want it to do. In fact, often, due to
its exceptionally well optimised high-level data types, I'm often surprised
at exactly *how* fast it is ;-)

For my part, I came in from a firmly Wirthian perspective: Pascal; Modula-2
and Oberon. Aside from the Pascal family of languages, I also know LOADS of
dialects of BASIC; 4GL's like dBase; Assembly (6502, 8080, Z80, 8086, 68000);
DOS/Windows batch language; and a little FORTH.

With Oberon, I though I had found the Grail, but was frustrated by
poor/incomplete implementations of it, or with the licensing terms of the
better implementations. It was at the point that I ditched POW Oberon, that
I made the transition to Python. I, too, was amazed, and I continue to be,
too. That was about 3 years ago...

Python does generate certain problems of its own, though: I recently had to
learn RPG III and IV for work, and going 'back to the dark ages' was
incredibly frustrating and just felt 'bad'. I guess you get spoiled by the
beauty of Python... and by the facilities, libraries and support
infrastructure (i.e. c.l.py).

Python does seem to magnify the flaws in other languages: everything else
seems (to me at least) to be second-best now.

Slither On!

-andyj

 

[Ville Vainio]

Python does seem to magnify the flaws in other languages: everything else
seems (to me at least) to be second-best now.

This might be one of the reasons they don't teach Python in schools -
it would be hard for the employers to motivate students to work w/ the
crappy languages the companies expect them to use.

Another aspect of motivation is accomplishment - a thing that might
make a C++ programmer proud of his achievement seems like a trivial 15
minute job for a Pythonista, and when that Pythonista is tasked w/ the
C++ job he doesn't get the kick from the accomplishment. And 6 hours
of debugging that "trivial" program doesn't help either.

 

[Alex Martelli]

This might be one of the reasons they don't teach Python in schools -
it would be hard for the employers to motivate students to work w/ the
crappy languages the companies expect them to use.

Absolutely. That's the same reason why the only writing implement
they teach you to use in school is a chisel and a marble slab -- if
they taught e.g. word processors it would be hard for employers to
motivate you to use pen and paper.

Another aspect of motivation is accomplishment - a thing that might
make a C++ programmer proud of his achievement seems like a trivial 15
minute job for a Pythonista, and when that Pythonista is tasked w/ the
C++ job he doesn't get the kick from the accomplishment. And 6 hours
of debugging that "trivial" program doesn't help either.

Yep. Managing to write even just "SPQR" with the marble and chisel
without cracking the slab makes you proud (that Q is _so_ tricky!) --
with a word processor, or pen and paper, you'd get no kick from the
accomplishment. And six hours of sandpapering and polishing that
marble slab doesn't help either.



Alex

 

[Peter Otten]

Absolutely. That's the same reason why the only writing implement
they teach you to use in school is a chisel and a marble slab -- if
they taught e.g. word processors it would be hard for employers to
motivate you to use pen and paper.



Yep. Managing to write even just "SPQR" with the marble and chisel
without cracking the slab makes you proud (that Q is _so_ tricky!) --
with a word processor, or pen and paper, you'd get no kick from the
accomplishment. And six hours of sandpapering and polishing that
marble slab doesn't help either.

Ah, what fools were those ancient Romans to make such a hassle with their
epitaphs, when a small sheet of paper saying "I'll be back in a minute"
would have done as well...

Peter

 

[Ville Vainio]

Ah, what fools were those ancient Romans to make such a hassle with their
epitaphs, when a small sheet of paper saying "I'll be back in a minute"
would have done as well...

They were obviously billing by the hour.

 

[Fernando Perez]

Yep. Managing to write even just "SPQR" with the marble and chisel
without cracking the slab makes you proud (that Q is _so_ tricky!) --
with a word processor, or pen and paper, you'd get no kick from the
accomplishment. And six hours of sandpapering and polishing that
marble slab doesn't help either.

Data point (real world, from a few weeks ago): after spending ~2 weeks (spread
over a month) writing about 1400 lines of C++, debugging a nasty coredump, and
pounding the documentation, I had my 'fast' extension module finished for some
numerical work. Great, sweaty and exhausted but all proud of myself, I turn
my attention to the problem of writing a unittest. I decided to write it in
python, since I figured it would be easier, and an independent implementation
of the algorithm (simple one) should suffice, if tested with enough random
data.

Python code: 15 lines (no, it's NOT a typo: fifteen). Time to write it: 10
minutes.

The sad part (to my ego, at least? The python runs faster! The C++ version
is now in the dustbin. At least I learned a bunch about the STL and
templates. The consolation...

Cheers,

f.

ps for those thinking: you must be an idiot of a C++ programmer. That may well
be true. But still, there are reasons for the difference. The C++ version
uses a heavily templated library for handling multidimensional arrays with a
bearable syntax, and g++ isn't the best compiler out there for that kind of
code. The python version relies on Numeric.innerproduct(), which is very well
optimized, and tackles head-on the problem I was avoiding with the templates,
namely very annoying pointer manipulations for multidimensional tensors. The
Numeric guys got their hands dirty, did it once RIGHT, and it works extremely
well.

 

[Georgy Pruss]

Data point (real world, from a few weeks ago): after spending ~2 weeks (spread
over a month) writing about 1400 lines of C++, debugging a nasty coredump, and
pounding the documentation, I had my 'fast' extension module finished for some
numerical work. Great, sweaty and exhausted but all proud of myself, I turn
my attention to the problem of writing a unittest. I decided to write it in
python, since I figured it would be easier, and an independent implementation
of the algorithm (simple one) should suffice, if tested with enough random
data.

Python code: 15 lines (no, it's NOT a typo: fifteen). Time to write it: 10
minutes.

For a J programmer (www.jsoftware.com) it might as well be just a hundred
characters and half an hour.

Regards,
G-:

 

[Andy Freeman]

For a J programmer (www.jsoftware.com) it might as well be just a hundred
characters and half an hour.

Cool - APL with ascii input and built-in (or at least standard) graphing.

 

[Bryan]

Data point (real world, from a few weeks ago): after spending ~2 weeks (spread
over a month) writing about 1400 lines of C++, debugging a nasty coredump, and
pounding the documentation, I had my 'fast' extension module finished for some
numerical work. Great, sweaty and exhausted but all proud of myself, I turn
my attention to the problem of writing a unittest. I decided to write it in
python, since I figured it would be easier, and an independent implementation
of the algorithm (simple one) should suffice, if tested with enough random
data.

Python code: 15 lines (no, it's NOT a typo: fifteen). Time to write it: 10
minutes.

The sad part (to my ego, at least? The python runs faster! The C++ version
is now in the dustbin. At least I learned a bunch about the STL and
templates. The consolation...

Cheers,

f.

ps for those thinking: you must be an idiot of a C++ programmer. That may well
be true. But still, there are reasons for the difference. The C++ version
uses a heavily templated library for handling multidimensional arrays with a
bearable syntax, and g++ isn't the best compiler out there for that kind of
code. The python version relies on Numeric.innerproduct(), which is very well
optimized, and tackles head-on the problem I was avoiding with the templates,
namely very annoying pointer manipulations for multidimensional tensors. The
Numeric guys got their hands dirty, did it once RIGHT, and it works extremely
well.

i don't think this is an apples-to-apples comparison. in c++ you wrote everything yourself. in python, you used the
numeric package which someone else wrote. i'm interested in knowing _why_ you chose to write it yourself in c++. and
_why_ you didn't try to write it yourself in python, but instead chose to use an already written library. i just did a
google search for "open source c++ numeric" and got several hits. i'm not putting you down in any way. i'm just
interested in knowing why you made these different decisions for each language.

bryan

 

[Fernando Perez]

Out of curiosity, was the C++ compiled without any debugging
information. The STL is really slow with debug on.

Full optimizations on, all debugging off. The bottleneck was not the STL, but
the Blitz++ array code. The problem is that blitz template expressions are
extremely complicated, and g++ is just not up to the task. Tests made by a
blitz developer with the SGI C++ compiler show far better scaling (with the
rank of the tensors), but I needed to run this on linux boxes using g++.

Cheers,

f

 

[Paul Rubin]

Full optimizations on, all debugging off. The bottleneck was not
the STL, but the Blitz++ array code. The problem is that blitz
template expressions are extremely complicated, and g++ is just not
up to the task. Tests made by a blitz developer with the SGI C++
compiler show far better scaling (with the rank of the tensors), but
I needed to run this on linux boxes using g++.

What is that madness? Why not just write in C?

 

[Jeremy Fincher]

What is that madness? Why not just write in C?

Blitz++ is even faster than FORTRAN for some numeric computations. I
doubt C could beat it.

Jeremy

 

[Juha Autero]

Tests made by a blitz developer with the SGI C++ compiler show far
better scaling (with the rank of the tensors), but I needed to run
this on linux boxes using g++.

What kind of Linux boxes? Intel has a C++ compiler for Linux that is
clamed to be better than GCC. It is not free and naturally only
available for x86, but if you can live with those terms, you could try
the free evaluation version to see if it helps.

 

[Fernando Perez]

What is that madness? Why not just write in C?

Have you seen how much fun it is to handle 6-index Numeric arrays in C? That's
why I used blitz++.

Best,

f

 

[Fernando Perez]

What kind of Linux boxes? Intel has a C++ compiler for Linux that is
clamed to be better than GCC. It is not free and naturally only
available for x86, but if you can live with those terms, you could try
the free evaluation version to see if it helps.

I tested ifc on blitz++ code, and it's not significantly better than g++. The
issue is the expression templates used by blitz++, which ifc doesn't seem to
handle any better than g++. Granted, my testing was not exhaustive, but that
was the quick feeling I got.

Note that these issues creep up in blitz++ only when using their tensor index
objects at high rank, a somewhat dark corner case which obviously puts
compilers in a world of pain.

Best,

f

 

[Fernando Perez]

I tested ifc on blitz++ code, and it's not significantly better than g++.

I mean: icc (ifc is their Fortran compiler, not the C/C++ one)

f

 

[Carlo v. Dango]

OK, I'm on the python wagon as well, but I do not really se much
improvement over JAVA... especially when it comes to maintaining and
reusing code (e.g. API's)... here the types are really helpful. So just
saying typing is bad, is to me, plain wrong. I guess its like choosing a
language for the problem... if your code is simple and script-like, you
probably do not get nothing but trouble from the types, but maintaining a
1 billion line of code program, you probably feel less agony by the
restrictions (and promises!) set up by the types. In a sense types are
like contracts (DBC) and we do agree on those as being a good thing,
right??!

Also, I see all this advocacy of python which to me seems more like
religion.. there is no concretenes in it, and I completely fail to see how
python beats any of the other dynamically typed languages such as
smalltalk or self... what is it with you guys?

however, when playing and trying to bend a language a dynamically typed
language is way more fun to play with than a typed one! But the integrated
lexer and parser in smalltalk, makes one wonder why python should be a
choice here? Maybe what people like is all the extra software which has
been and is being written for python, which you do not have in smalltalk?
or what is it?

-carlo