Pythonwin and .NET

Alex Martelli aleax at aleax.it
Mon Sep 10 05:35:29 EDT 2001


"Mark Hammond" <MarkH at ActiveState.com> wrote in message
news:3B9C72EE.5020504 at ActiveState.com...
    ...
> choir.  Python already has excellent Win32 integration capabilities - so

Yes, and that is mostly thanks to YOU!-)

> I am unsure what about .NET will suddenly make Python more visible or
> viable on Windows than the existing Python+COM has.

With the existing Python and COM, I cannot do *EVERYTHING* that I
could do if I wrote my COM servers/clients in (e.g.) Visual C++ with
ATL instead: specifically, I cannot implement nor consume arbitrary
custom interfaces.  I cannot even use Python to access all of the
Win32 API -- only that (large!-) subset of it which your extensions
expose, but time and again some little crucial API call is missing
and it's C++ time again.  Python lets me do, say, 80% to 90% of my
Windows/COM work (others' mileage may differ, depending on what
exactly they're doing with COM and Windows:-), but I still need C++
up my sleeve for the remaining part (and I'm not talking about
_performance_ issues, mind you -- just base interoperability ones).

It's very different with Jython (I haven't used it "in anger" yet,
but dabbled, yes) -- I have not found *anything* yet that I can't do
in Jython, i.e. anything _at all_ that would require me to switch to
Java coding for some part (I even got a surprise when I measured
the speed-up brought by recoding a bottleneck from Jython to Java,
how _modest_ was the speed-up -- too used to the LARGE speed-ups
one gets from recoding from CPython to C++, I guess:-).

I would expect (perhaps naively) that a hypothetical "fully
mature PythoNET" would provide interoperability with the rest
of the .NET Framework as smooth and wonderful as Jython does
with the rest of the Java world -- no peculiar exceptions, etc.
AND the ability to deploy packaged components (.DLL, .EXE, ...)
looking "on the outside" just as if they had been built with
any other .NET compliant language, even better than Installer
and py2exe let me do today.

Incremental, not revolutionary, admittedly.  But, it seems to
me, potentially important increments.


> > Sure, many shops won't get it, and will happily go on Cobol'ing or
> > whatever.  Think of it as evolution in action, as Niven and/or Pournelle
> > used to say:-).  If my competitors get half my productivity because they
> > prefer to use other languages, _I_ am not gonna complain:-).
>
> Again, I agree 100%.  However, this exact same option is available to
> them today.  I am not sure I see anything in .NET that makes Python
> *more* attractive than it already is on Windows, and can see a few

If one starts out with a decision to use multiple languages, no.  But
many shops have this "one language to bind them all" mentality, and
when pressed on this point I have to admit that Python is *NOT* able
to do 100% of what you can do, COM-wise, with VC++, VB, or Delphi
(consume and implement arbitrary interfaces) -- "just" 90% or so.


> And on the more pragmatic side, there is still *significant* work
> remaining to be done before Python on .NET is really viable, and I know
> of no commercial effort underway to implement this.  From memory,
> JPython took a number of years to be considered viable and to transform
> into Jython.

A very important point, yes.  Do you know of any NON-commercial
effort going on, btw?


Alex






More information about the Python-list mailing list