Why I love python.

Dave Brueck dave at pythonapocrypha.com
Fri Aug 13 23:47:19 CEST 2004


Nick Patavalis wrote:

> On 2004-08-13, Dave Brueck <dave at pythonapocrypha.com> wrote:
> 
>>Nick Patavalis wrote:
>>
>>>I also mentioned web-browsers, ray-tracers, circuit-simulators. I
>>>could add word-processor, spreadsheets, video editing programs, and
>>>GUI toolkits to the list. Are they still too exotic?
>>
>>No - but I still don't think they reflect anywhere near a majority of 
>>the development that goes on.  
> 
> 
> Yes, the majority of development goes on little *glue programs* that
> take data from a database, and format is as XML/HTML, or aggregate and
> analyze data stored in a database, and stuff like that. But for all
> these to be possible a massive amount of *infrastructure* is
> required. And this infrastructure cannot be created in Python. So you
> don't say that Python isn't a glue language, but that the greatest
> percentage of development that currently goes-on *is* glue-stuff
> development

Well, at my current company we've implemented web and file servers, 
cache log parsers, web applications, Windows desktop applications, 
Windows COM objects including web browser plugins, video splicers, and a 
host of tools, all in Python. These aren't "little glue programs" - they 
are just programs; normal programs we'd have to write in _some_ language 
and Python turned out to be the best fit. What's more, a whole heck of a 
lot of the functionality implemented in Python would most definitely 
fall under the category of infrastructure, not glue.

> Put yourself in this position: Its a few years ago (say 1998 or 1999),
> and no graphical web-browser exists for Linux. You are planning to
> develop the "iso-standard" web-browser for this operating
> system. Would you do it in Python? Remember that no HTML parsers
> exist, no decent HTML renderers, the GUI toolkit is more or less
> primitive, and the low-end desktops runs at about 200-something
> MHz. You might argue "this is not the case today", but how can you
> preclude that *similar* challenges do not occur today, or will not
> occur in the future?

This is so far removed from what I'm trying to say that I don't even 
know how to respond. I'm not arguing that at all.

> 2004 again, and you decide to scrap and replace the age-old X11 window
> system; do away with it and start from scratch. Build a moder
> windowing system; 3D all over, fully network transparent, with widget
> support on the server-side, fully object oriented interface, and so
> on. How much of it would you be able to code in Python? 

Python is not the right tool for every job. There do exist cases where 
more performance is required than can be delivered.

Having said that, the cases where it is too slow make up a small (and 
shrinking) portion of the total amount of development going on. As such, 
better performance is always welcome, but it won't benefit as many 
people and as much as other things can. IOW, anytime you say, "wouldn't 
it be great if Python were faster?" you can easily get everybody to 
respond, "sure!" - everybody's on board with you there. It's when you 
try to fit it into the list of priorities that you'll find that there 
are other things higher on the list. Higher because they provide more 
benefit overall and/or to the people who are interesting in helping out.

To your specific question, I actually _would_ use Python for most of an 
X11 replacement system. Obviously low-level stuff would be handled by 
one of the existing 3D libraries out there (no need to reinvent the 
wheel there - the goal is to build a better window system, and we'd want 
a good hardware abstraction lay). I've seen a few proof-of-concepts with 
Pygame that lead me to believe that it's doable - their performance is 
already better than X11's performance for the first decade or so of its 
existence.

 > How much *more* would you rather be able to code in Python?

You can't consider the benefit in isolation. You have to take into 
account the costs involved.

-Dave



More information about the Python-list mailing list