Thursday, February 03, 2005

Python Reality Check

Sometimes it's hard to see yourself from the outside. I'm looking over the blog (especially the PySpotting hoo-ha), and I'm surprised to see how much here is about Python.

Truth be told, I'm not a Python-├╝ber-alles fanatic. In my day job, I write C++ for an embedded device. [Insert obligatory corporate disclaimer here]. I've successfully proven that it's possible to run a Python interpreter on said device, but you know what? Not gonna happen here... not when the footprint of the language runtime is half the footprint of the OS. When I do crank out some Python at work, it's something like a script to automate a build or test process, which runs on my workstation.

So, no, in my world, Python isn't going to prevent tsunamis, root out the terrorists, and usher in a new age of global eudaemonia.

What it has become is the "uppermost tool" in my development toolbox. When I need to try something to see if it could possibly work, when I need to automate some annoying computer task, or when I just want to hack for the sake of hacking, I usually grab Python first.

9 comments:

Anonymous said...

The thing is, though, that Python is almost like an operating system or at least the upper levels of one - one can call it a platform - and offers the sort of runtime configurability that lower-level languages lack. Really, the fundamental Java platform is the sort of thing one might compare to the Python environment, although I accept that Java operating systems never caught on, and that people presumably feel more comfortable with traditional OS architectures these days.

So that Python is bigger than the C library, for example, cannot really be considered a fair comparison in my view.

Anonymous said...

Someboy says "Python is like a OS"

It become really an OS with free OS Unununium !

http://unununium.org/

"we have chosen to use Python as the language of choice for development."





It becomes very cool soon ...

Anonymous said...

What a relief that someone has at last expressed doubts about some of the claims made for Python. I, like you, find the language very attractive. I, too, was disappointed that py2exe didn't produce an exe but a whole folder full of stuff.

It was a pleasure to find a .msi to upgrade on XP. Trouble is that this format leads one to believe that the upgrade will happen in the Windows way. i.e. it will offer to convert all that is Python on my machine. Upgrading is over complicated.

Another problem, shared with Linux, is that the plethora of tools is a maze that one can get lost in at the expense of getting work done. Part of the problem here is the reluctance we all have to criticise firmly people who work for free. This reluctance may be the biggest barrier to the open source takeover becoming reality in that, in the abscence of a commercial process of natural selection, this it main way that such selection could happen.

In the case of Python there is a leader. Maybe the leader needs to accept that popularity and effectiveness are not easy bedfellows.

Anonymous said...

If you're looking for a scripting language that fits on an embedded device, look no further than Lua (http://www.lua.org). The footprint is only a little over 100k. When you work with precompiled bytecode, you can leave out the compiler and halve the footprint. You can even compile it to use integer instead of floating point numbers thereby again reducing the footprint. And it ports easily: it depends only on ANSI-C / standard C library.

And the language itself is a treat. Python may offer more features, libraries, and convenience, but it doesn't come close to Lua in terms of expressive power per unit syntactic overhead.

Tim Lesher said...

"If you're looking for a scripting language that fits on an embedded device, look no further than Lua (http://www.lua.org)."

Yep, I know lua from my game development days. I've already mentioned to anyone who cares to listen here that if we ever need a real scripting language on the terminals, Lua is probably the best option.

Of course, since somehow I've become known as the local rabid, foaming Pythonista here (at our group's Christmas lunch, my name card read "Tim 'The Python' Lesher"), the next question is always "Not Python?"

freeform said...

Did that size include both compiled .pyc file as well as uncompiled .py files for the standard library? Does your device use a filesystem like jffs2 that compresses data? What options were compiled in? Were all of them necessary? Did you figure out on say a per byte or kilo-byte basis how many features you get from all of that? How about comparing the cost savings of more rapid application development vs. the costs of adding a little flash to the device?

Kevin said...

Depending on the embedded device, that 100K might even be too thick. Years ago we had great luck with embedded S-Lang in a smaller real-time embedded application (engine diagnostics). You are trading elegance and abstraction in the scripting language for the run-time memory and code space minimization. Certainly depends what you are planning to do with the scripting language.

Anonymous said...

Okay, I can see that I've stumbled on a somewhat ossified discussion, but Feb 2005 wasn't too long ago.

I've been a script language user since, well if you consider HP 2000e BASIC ca. 1975 a scripting language, then 1975.

Once I got my brains around z80 macro assembler I learned FORTH and really got addicted to it. So while I was writing my own FORTH interpreter in z80 my first year CS prof at university suggested I check out LISP. I wrote a Zork-like interpreter in that. Another fantastic language. Check out SIOD (scheme in one-defun).

Through various misadventures in the early 1990s I learned PERL and thought it was kind of cool, but the syntax was inelegant and I had to figure out which of the 10 forms I should use to read a sequential file and stop at EOF.

When Python came out (in 1992 I think) I was immediately attracted to it. It was highly interactive (though the default shell was and is a little unforgiving -- try pysh), natively object-oriented, highly readable and borrowed many concepts cleanly from PERL, BASIC, LISP, (I can't believe I'm mentioning them all at once) without feeling really overloaded.

Yes, it's not the fastest scripting language. But as anyone who has ever worked on scripting internals knows, you purchase immediate flexibility at the price of performance. If you really want high performance you can either use a profiler to hunt down where you are wasting time or re-code parts of python in C or C++. (Personally I'm not a big C++ fan -- never was really. 'D' is a much cooler language. What C++ and Java should have been).

I'm about to use Python as the core of a tutorial / game system and I think it should work well. I know that Python works much better if you extend it rather than embed it in gaming. I'm familiar with the threading issues. We'll see.

In any case, pick up the right tool for the job. Just because you have that new black and yellow $249 power drill, that's no reason to try and use it to remove the screw from your watch. Pick up the slick little, Swiss, medical-stainless steel jeweler's screwdriver. You can love them both. It's all good.

In today's world it's all free. An embarassment of riches!

Enjoy.

Anonymous said...

That is so great!
It's also possible to run python in parallel on SMP: Parallel Python