COM = Component Object Model.
It’s a very long and sordid story, but COM (which was originally cooked up by people at DEC) was for a long time the preferred way to develop component oriented software for Microsoft Windows operating systems.
A COM API presents a binary interface, so you can create bindings/wrappers to a COM interface from multiple languages. The majority of people doing COM development on Windows use C++ or VB, but lots of other languages allow you to call methods in COM interfaces.
COM was followed by COM+ sometime around the release of Windows 2000. COM+ added some useful extensions to COM, but kind of got lost in the .NET frenzy that soon followed it. As it turns out, many of the .NET interfaces don’t do much more than wrap existing COM and COM+ interfaces.
If you want to build Windows applications, you can always write directly to the Win32 APIs. This can be very ugly and painful and is guaranteed to shorten your life, especially if you are not programming in C or C++. COM makes life easier, with usually only a minor performance penalty. Assuming you are very careful and use it in exactly the right way. I’ve seen a lot of really bad, really slow COM code in my day.
You can call COM interfaces from Python because Mark Hammond and others built a set of Python libraries as an add-on to the core Python release. You need to download these additional libraries if you want COM support. I believe that ActiveState’s distribution of Python for Windows includes them.
Mark and Andy Robinson wrote a fine book called Python Programming on Win32. I have a copy of it and I highly recommend it if you need to access Windows specific features from Python. This book contains a couple chapters on COM programming from Python.
The good news, assuming you consider programming Windows specific code to be a good thing, is that people are hard at work integrating Python with the .NET Common Language Runtime. You will then have direct access to all the .NET APIs from Python. Theoretically, that will put Python on the same footing as the other languages that work with .NET (although the reality that Microsoft doesn’t want to talk about is that if you aren’t using C#, you are at a disadvantage with respect to both features and performance). Still, it’s better than a sharp stick in the eye, a.k.a., Win32 and COM.
There are also similar projects ongoing to integrate Perl with .NET.
There are in fact several independent projects working on Python and .NET integration. Early results were decidedly bad. Same for the Perl experiments. Interpreted languages and the CLR don’t mix well. I’m not sure if they have made any better progress since I last checked in on them six months or so ago.
[quote]Did I just learn the wrong scripting language?
IMHO, no. Python is awesome.
[quote]How many am I going to have to learn?
It depends on what you need to do and who is paying you. If you want to be flexible on the job market, you really need to learn a couple languages. Sometimes the APIs you need to access are available only from certain languages, or even just one.
Also, different tasks are often suited to different languages. Perl is great for string processing, among many other things. If you can get past the ugly, ugly syntax, it’s a fine all purpose tool. Python is also an excellent all purpose tool, but with better syntax.
After you learn a couple languages, learning new ones become easier. You will find most of the same programming primitives (variables, loops, method calls, etc.) in each language. The hard part is keeping the syntax straight. I’m in my 15th year of professional programming, and I would estimate that Python is somewhere around the 20th language I have needed to learn. That sounds like a lot, but many times I needed to learn only enough to read other people’s code and figure out what was going on with it. Also, I have almost completely forgotten the first ten or so. Except for C.