Pythonwin and .NET

[Alex Martelli]

Mark Hammond wrote:
        ...
> So if .NET has all the features necessary to allow Python to be fully
> utilized by other .NET languages, many shops will simply choose to use
> these other languages instead of Python - braces aren't *that* bad :)
> 
> If .NET never has this capability, it will mean that Python itself can
> only take advantage of Python's features - so why use the .NET
> implementation of Python at all?

I think you're confusing "what shows on the outside of a component" (which 
is constrained by CRL rules, etc) with what goes on inside it.  I want to 
use Python (and others will want Eiffel, or Cobol, or Mercury, etc) because 
I am convinced it gives me incredibly good productivity to implement and 
consume those externally-constrained interfaces.  I may want to use Python 
on .NET, or on the JVM, or with COM, etc, if and when deployment issues 
make that preferable to (e.g.) classic Python with C/API extensions -- it's 
as simple as that.  The reflection/introspection abilities of CRL are 
adequate (surely a match for those of the JVM!) but most languages make you 
use a lot of boilerplate to get at them -- Python can make it smooth and 
seamless (if it can on the JVM, why shouldn't it afford the same abilities 
on the MSIL/CRL platform we call ".NET framework"?).

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:-).


> But heck - I thought OS/2 was a sure fire winner :)
> 
> Mark (who is certainly not speaking for his employer:)

No, but you're just as certainly *the* guy with the most experience merging 
Python and .NET at this point in time, so your opinion carries enormous 
weight (and well it should!).  Should one be able to sway your opinion, the 
prospects of Python on .NET might well change for the better;-).


Alex