Pythonwin and .NET
Maan Hamze
The Buzzword these days is .NET, and quite frankly I have not had the time
to get familiar with this 'new' technology.
However, on all our NT servers we use PythonWin for ASP work; and in
addition, more recently, we got into the regular CGI Python scripts. In
other words, we do depend on Pythonwin for ASP Python scripting. Also,
recently, we are delving into using Python with COM objects beyond the mere
use for web pages.
In other words, PythonWin is emerging by itself to be a centerpiece package.
So the question is:
How will Microsoft .NET affect PythonWin and the way we do things through
ASP and Python at least. If there is a website where you comment on these
things I can look at it. Or you are welcome to offer some of your comments
here.
Thanks,
Maan
Mark Hammond
This is a hard and politically loaded question :)
The new world (.NET) and the old world (Python, Perl, etc) are really
quite distinct. To see all the benefits of .NET, you assume a world
based on .NET. So while .NET has some obvious and significant benefits,
it does require a leap of faith to fully exploit them.
I believe it will be a few years before .NET really starts taking off.
It will be lead mainly by corporates - people commited to being a
"Microsoft Shop" for their own strategic reasons. In my opinion, large
IT shops filled with mediocre programmers have very good reasons for
making such decisions, so I imply nothing negative about such places or
decisions.
I honestly do not know where Python and Perl really will fit in this new
world. .NET imposes certain requirements on programs, so that the
benefits of .NET can be realized. However, these requirements can often
work against languages such as Python. The dynamic and introspective
nature of Python is unlikely to be able to be exploited, unless .NET
itself grows these same capabilities - and when .NET grows them, we can
expect C# to also grow them.
For example, in the ideal world, you could implement a Python class with
__getattr__() functionality, and use that class from Visual Basic or
from C#. This is only likely to be possible if .NET itself grows
support for expressing this level of dynamic attribute access, and if
.NET itself has it, we could expect the popular MS languages to also
grow such features - ie, the equivilent of __getattr__ implementation in
C# or VB. Once everything gets to the point where Python can express
these things in .NET, why would you still use Python? As much as the
*syntax* of Python is very nice, it is not only the syntax that makes us
love the language - it is the language as a whole.
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?
But heck - I thought OS/2 was a sure fire winner :)
Mark (who is certainly not speaking for his employer:)
Maan Hamze
Thanks for the comments. The eye opener came to me at a recent Delphi 6
conference (we use Delphi for most of our compiled applications) when the
offical speaker of Borland/Ingres said that Delphi is moving toward being a
.NET provider. I, personally, am quite wary of these overarching paradigms.
I can not make a good judgement so far since I do not know much about it.
Let me quote something from:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndive/html
/data02222001.asp
"If you plan, like me, to dive into the sea of data access issues and
strategies, then make sure you pay due attention to the submerged, sharp
rocks of existing ADO code.
Software geologists state that this kind of rock originated during the
Post-Internet Era, after the first ODBC glaciation. Several finds of this
mineral code have been discovered in all the DNA systems built over the past
couple of years-a period of time that is no doubt the software counterpart
of a geological era."
This is an attitude that personally bothers me. And quite the truth
Microsoft lacks the power of introspection and imagination to take advantage
of different languages. It is a field that is strewn by unfinished
technologies and bombastic pedagogy from Microsoft.
Meanwhile, as it appears from the .NET Microsoft site, different companies
are scrambling to take advantage of .NET. Incidentally ActiveState appears
in the different lists of 'Vendors and Tools."
What I anticipate is that other languages will make inroads into .NET which
will keep the alternatives open.
I think, anyway, that I am going to send that coupon for a free subscription
in the Fawcette .NET magazine. Meanwhile, I just received from Amazon.com
the book you co-authored on Python and win32 to see what the very near
future may bring :)
Thanks,
Maan
"Mark Hammond" <mham...@bigpond.net.au> wrote in message
news:3B997A5E...@bigpond.net.au...
Roman Suzi
>Maan Hamze wrote:
>
>> This is a question for Mark Hammond.
>I honestly do not know where Python and Perl really will fit in this new
>world. .NET imposes certain requirements on programs, so that the
>benefits of .NET can be realized. However, these requirements can often
>work against languages such as Python. The dynamic and introspective
>nature of Python is unlikely to be able to be exploited, unless .NET
>itself grows these same capabilities - and when .NET grows them, we can
>expect C# to also grow them.
I thought .NET has some kind of assembly-like bytecode, so Python could
just compile into it (like Jython to Java's). If this is not true and
.NET's lowest level is higher than Java's bytecode level, .NET will not
make serious impact. Nobody will buy single highlevel language platform
even from MS. (However, who could imagine several years ago that MS
Windows will be 95% on the desktops?). No. This will not happen with
developers!
Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ r...@onego.ru _/
_/ Saturday, September 08, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Aren't cats just widdle furry balls of love?" _/
infobot
> I thought .NET has some kind of assembly-like bytecode, so Python could
> just compile into it (like Jython to Java's). If this is not true and
> .NET's lowest level is higher than Java's bytecode level,
As I understand it, that is in fact the case. With Java, the language
itself (ie. java) was the "platform". With .Net, a common language
runtime means that we can all continue using our favourite languages.
Or so the theory goes. Personally, it sounds better than Java.
However, I have a sneaky suspicion that, in practise, unless you're
using C# or VB you won't be able to use it to its full potential.
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 :)
Seems to me that if our goal is wider acceptance of Python, then it's
a catch22 situation. Either
(a) python won't be able to work fully with .Net or
(b) python WILL work fully with .Net but then so will
other languages and people will use those languages.
However, if our goal is enabling today's Python developers (as well
as tomorrow's Python developers who are coming to the language for
reasons other than .Net) then being able to use .Net is definitely
a plus.
On that note, I'm now trying to do some win32 work with MSExchange
and Python. However, I have so much Windows-based work ahead of me
that I have to ask myself now whether I should switch over to VB for
the project. May I ask what one can do with VB that can not be done
with Python ? Or should all COM/DCOM services be available to the
Python developer on Win32 ?
chas
ps. Your "Python & Win32" book, btw, is excellent, Mark - taught me
many things about Windows from an OS pov as well as Python that
I was unaware of. Great format too.
Alex Martelli
...
> Microsoft lacks the power of introspection and imagination to take
> advantage
> of different languages. It is a field that is strewn by unfinished
Watch out against rampant generalization. Microsoft employees these days
include guys such as Luca Cardelli -- remember, "Microsoft Research" is a
powerhouse including most of the people who once did research for DEC.
Large companies with fat profit margins can afford splendid research
outfits -- it's quite possible that the company as a whole lacks the
imagination &c to take advantage of their bright lights in research (just
see what AT&T/Lucent, Xerox, DEC, and so some extent even IBM [about which
I cannot be equanimous, since I _did_ use to be in IBM Research:-)] did in
the past...). But it's not always so... the .NET Framework (as opposed to
other, vaguer parts of the .NET "vision") was designed with lots of input
from very bright guys & gals in MS Research, other research outfits (e.g.
the Mercury language guys from Australia), and brilliant practising
engineers such as Hejilsberg (the guy who once thought up Turbo Pascal,
then later Delphi and the VCL). Don't underestimate the power of money to
attract very good researchers and more generally very bright people:-).
Alex
Alex Martelli
...
> 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
Ron Stephens
I hesitate only a few seconds before adding my comments to those of Mark Hamond
and Alex Martelli, for reasons only Alexander Pope might fully understand.
I well make a prediction:
Despite the reservations of a genius, Mark will help secure such a place in .NET
for Python, that this extension of Python will be one of the major reasons for the
ultimate advancement of the language Python to a pre-eminent role in the further
evolution of computer science.
I feel this in my bones. I cannot expect to offer detailed reasons on the level of
Alex and Mark. But my bones are normally prescient, and not to be ignored.
God bless mark Hammond and Python...and .NET.
...from one of the legions who will buy any future Mark Hammond book sight unseen.
Ron Stephens
Ron Stephens
Ron Stephens
Python may well become the one and only language that offers the ability to write
programs that can be equally well integrated into systems using *either or both*
of the two run-time environments, Java or .NET.
Can you imagine the same could soon be said for either C# or VB?
Can you imagine circumstances where such a capability might be useful?
Ron Stephens wrote:
Ron Stephens
""""I'm a sysadmin for several NT, Solaris, and Linux boxes. I currently
use both Perl and increasingly Python to manage my systems. I am
beginning to enjoy Ruby quite a bit but it seemingly is devoid of NT
related functionality in the areas of:
services management
printer and disk management
COM(+)
user and group administration
security
sockets
ODBC
Can anyone comment on any available modules (not in Beta, etc.) that
are available and mature in nature?
I believe that if there is anything that prevents the more widespread
use of Ruby on WIN32 is that it may be lacking these tools."""""
Many people like to use their language of choice, but can only do so if it has
good Windows tools and integration.
Maan Hamze
Beautifully said. When I asked the question to Mark I was hoping to get
different comments from people in the know as I was about to start working
my way through Mark's book.
Also, Mark's reservations are to expected. I believe he is being a bit
cautious which is understood. But, personally, I only expect good things
for Python to come out of this.
Maan
"Ron Stephens" <rds...@earthlink.net> wrote in message
news:3B9B6590...@earthlink.net...
Chris Goringe
> ASP and Python at least. If there is a website where you comment on these
> things I can look at it. Or you are welcome to offer some of your comments
> here.
Having now played with .NET for a while, I'd have to say that its big
selling point is the ability to mix languages, choosing the
appropriate langauge for the appropriate part of the project. I know
you can do that in the current regime, but .NET makes it very easy.
So I'd love to see python integrated into .NET. Python is a great,
easy to learn, powerful, flexible and expressive language, but isn't
the right language choice for every problem. If it were integrated
into .NET, it would have to compete with all the other langauges there
- but that shouldn't be a problem. Everyone I know who has started
using python has continued to use it...
But I don't think its going to be easy to do. To really play in the
.NET sandpit, a language must interface with other languages; this
means it must (in terms of its external interfaces) follow the CLS
(Common Language Specification). And this has been written for C#
which doesn't look a very similar language to python...
Samuele Pedroni
>
> 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 don't get this argument. At least it doesn't work for
Jython and the JVM. If it were true nobody would be using
Jython. But anybody with the right feeling about when performance
is important and when not and grasps Jython knows that is is worth
using in many, many cases ....
regards, Samuele Pedroni.
Mark Hammond
No disrespect to Jython, but I am not sure it has revolutionized, or
made huge inroads into the Java world. I understand that the Gartner
Group expects Java to be the most popular language within the next few
years. I would be interested to know what percentage of Java users have
used, or are even aware of Jython.
Then .NET blurs the issue even further - you will need to look no
further than Microsoft to find JScript, VB, C# and C++ languages that
target .NET. Finding Java targetting .NET will be only one link away.
The existing Python implementation already has pretty good COM support.
We all thought just a few years ago that these COM capabilities would
help make Python a serious contender on the Windows platform - but many
years on, I still shudder to think how few VB programmers in the larger
corporate shops have even heard of Python.
Mark.
Mark Hammond
> ...
> 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.
I agree 100% for the few excellent programmers out there, and also for
the "shrink-wrapped component" authors. However, the majority of
programmers really know only a few languages with a high degree of
competence - I know that I do. I am very unlikely to write code in
either Mercury or Cobol (or even Perl :). A software house selling a
component certainly may choose to, but most users - especially those in
the large corporate shops - will not, and will stick with 1-3 languages.
Python should have a place here, but this newsgroup is preaching to the
choir. Python already has excellent Win32 integration capabilities - so
I am unsure what about .NET will suddenly make Python more visible or
viable on Windows than the existing Python+COM has.
> 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
things that make it less attractive on V1 than C# and VB for .NET, for
example.
> 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;-).
I may have given the wrong impression here :) I believe .NET is very
cool, and Python is very cool. But I don't really see much in the
marriage of Python and .NET that suddenly creates a whole greater than
the sum of the parts.
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.
Mark.
Alex Martelli
news:3e7e9334.01090...@posting.google.com...
...
> But I don't think its going to be easy to do. To really play in the
> .NET sandpit, a language must interface with other languages; this
> means it must (in terms of its external interfaces) follow the CLS
> (Common Language Specification). And this has been written for C#
> which doesn't look a very similar language to python...
To really play in the JVM sandpit, a language must interface with
Java; this means it must (in terms of its external interfaces)
follow the Java semantics. And those are defined for Java, which
doesn't look a very similar language to Python... but DOES look
like a VERY, VERY close one to C#!-)
Yet Jython flourishes. So why not PythoNET (a name I'd find
much preferable to the goofy "Python.NET", just like Jython
was a vast improvement over the original name JPython)?
Alex
Alex Martelli
news:3B9C72EE...@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
Alex Martelli
...
> years. I would be interested to know what percentage of Java users have
> used, or are even aware of Jython.
Considering that Bruce Eckel's books are (deservedly) best-sellers,
and that he touts Jython in his latest "Thinking in Patterns", I
think at least "are even aware of" side of thing is well-placed. As
for "have used"... no idea.
> We all thought just a few years ago that these COM capabilities would
> help make Python a serious contender on the Windows platform - but many
And it does, mind you -- technically, it shines.
> years on, I still shudder to think how few VB programmers in the larger
> corporate shops have even heard of Python.
So maybe we need good marketeers more than we need technical improvements.
Of course, good marketeers are just as rare in the open source world as
they are in the world at large;-).
Alex
Samuele Pedroni
This sounds like a totally different argument.
You first argument ounded like Python.NET
is not technically worth.
Now it seems that the point is that it is not
worth because there is no real audience.
I dont't think that Jython has revolutionized
the java world. But the comments we get
from people using it are more or less
saying that it is "revolutionary". But
yes, on "our" side, there is no VB
in the Java world.
I never tried Python.NET,
it is just a compiler?
or it has an interactive
mode and exec, etc
support? ...
regards, Samuele.
Maan M. Hamze
"Alex Martelli" <al...@aleax.it> wrote in message
news:9nhus...@enews1.newsguy.com...
Python.NET, why not: Pythonette - it is more like the little sister Python
:)
Maan
Maan M. Hamze
"Mark Hammond" <Ma...@ActiveState.com> wrote in message
news:3B9C6FF6...@ActiveState.com...
> The existing Python implementation already has pretty good COM support.
> We all thought just a few years ago that these COM capabilities would
> help make Python a serious contender on the Windows platform - but many
> years on, I still shudder to think how few VB programmers in the larger
> corporate shops have even heard of Python.
>
> Mark.
>
You are right here, but as you state in one of your presentations the issue
maybe that of marketing. I speak from experience. Weeks ago I was going
all out at my work trying to convince many to use Python for a CGI program.
I was just not willing to use Perl with its messy syntax. What won the case
is when I actually made a demo and everyone could see how neat the whole
thing was. Then I made another demo using COM and Python then yet another
demo connecting to a database and showing the results using Tkinter while
using ADODB through COM in Pythonwin. Thus the flurry of posts here from
me - because I discovered that what matters is **the demo** where anyone can
see. And that is what convinced everyone that there is something powerful
here.
The main concern for management is: this is a free software, so there is no
support for it!
My answer: it is not a free software, and, anyway, don't you all use Perl
for example? I do not see you complain that it is a 'free software.' And
also, support for Python is much better than all the tech support agreements
you sign with companies where you end up, on many occasions, talking with
some mediocre person. blah blah etc.. etc.....
There are some deep misconceptions in the corporate shops on these issues.
And marketing is key issue with many corporate shops.
just my 2 pennies :)
Maan
Alex Martelli
news:tppgad5...@corp.supernews.com...
...
> The main concern for management is: this is a free software, so there is
no
> support for it!
> My answer: it is not a free software, and, anyway, don't you all use Perl
> for example? I do not see you complain that it is a 'free software.' And
There's no dearth of _excellent_ commercial outfits that can sell
you support for Python! For example, ActiveState, which is likely
to be where you also buy your commercial support for Perl; SecretLabs,
for pure-Python focus; etc, etc. If somebody's willing to buy,
they can really get their money's worth from any of these outfits --
as well as, I'm sure, from very good freelance consultants that
may have advantages such as being local to your location (for old-time
managers who like to get their support face-to-face rather than
via the net:-).
Alex
Cliff Wells
> I honestly do not know where Python and Perl really will fit in this new
> world. .NET imposes certain requirements on programs, so that the
> benefits of .NET can be realized. However, these requirements can often
> work against languages such as Python. The dynamic and introspective
> nature of Python is unlikely to be able to be exploited, unless .NET
> itself grows these same capabilities - and when .NET grows them, we can
> expect C# to also grow them.
And if Python doesn't grow them, it will undoubtedly languish in the dust
heap of "other" languages. How popular Python would be today without a Win32
port? While many of us may not _like_ Windows, we ignore it at our own
peril. With the push Microsoft is giving .NET, it's definitely going to be
adapt or die time for many existing technologies.
> 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 :)
As they often choose other languages today. I don't think the question is
whether people writing in other languages can access Python, but whether
Python can access the services of other languages.
Regards,
--
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308
Oleg Broytmann
> And if Python doesn't grow them, it will undoubtedly languish in the dust
> heap of "other" languages. How popular Python would be today without a Win32
> port? While many of us may not _like_ Windows, we ignore it at our own
We do not "ignore" it - we actively create alternatives (there are OSes,
lnguages, services, programs and all that).
> peril. With the push Microsoft is giving .NET, it's definitely going to be
> adapt or die time for many existing technologies.
Any reasonable prediction when the very M$ will die? (All things ended
sooner or later, and for software it is often "sooner".)
Oleg.
----
Oleg Broytmann http://phd.pp.ru/ p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
James_...@i2.com
Alex Martelli wrote:
<snip>
>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 agree with Alex. As I've posted here before, we have written hundreds of
thousands of lines of deployed/production Jython code. We have converted
*a few* tiny display renderers (Swing-based) to Java to increase scrolling
performance. But isolated, performance areas aside we have not found *any*
(zero) Java functionality that is not fully (and easily) accessible from
Jython. (But being so much more of a pleasure to code in Jython, of course.
Throwing in an unsolicited plug: we especially love all the *dynamic* stuff
that Python brings to Java via Jython. :-)
Jim
David Bolen
> Despite the reservations of a genius, Mark will help secure such a
> place in .NET for Python, that this extension of Python will be one
> of the major reasons for the ultimate advancement of the language
> Python to a pre-eminent role in the further evolution of computer
> science.
Let's just say that I'm a bit less sanguine about this, particularly
after reading the white paper on the ActiveState site that came out of
the initial (MS-sponsored I believe) experimentation with the
integration of Python with the .NET framework.
While I certainly won't question that it will be possible to tie the
two together, it's unclear to me that doing so will be a big draw to
Python given some of the potential uncertainties and possible
restrictions (not the least of which may be performance).
But time will tell...
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
John Ochiltree
> Nobody will buy single highlevel language platform
> even from MS. (However, who could imagine several years ago that MS
> Windows will be 95% on the desktops?). No. This will not happen with
> developers!
>
They will if the bosses are sold it!
Delaney, Timothy
I have to disagree here a very little bit.
I've come across some poorly-written code which does identity comparisons
with instances of java.lang.Class. Of course, if you try to do
java.lang.Object.__class__ or java.lang.Object().getClass() jou get a Jython
jclass instance, which will not compare equal.
The solution of course is to not rely on this behaviour, or to make it a
totally internal thing.
Tim Delaney
Ron Stephens
of Visual Python for .Net on their web site. I can not use it because I do not
have access to a beta of Microsoft's Visual Studio. However, the ActiveState beta
of Visual Python must have at least basic functionality.
How basic is that functionality? How much is left out? Are there big differences
between the language supported as Visual Python and c-Python as we know it?
Mr. Mark Hammond said
"""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."""
Mr. Hammond, why is Python on .NET not currently viable? Also, do you think
ActiveState will stick with it until it is viable?
Look, I like many on this list would love to see you, Mr. Hammond, champion Python
on .NET to the n'th degree. I would say just about anything to try to persuade you
to do so ;-)) But, I know you are a very busy person and will certainly make up
your own mind on important matters. And I think it must be discouraging sometimes
to work so hard for so long and not see all the progress you would like to see.
This is a burden you must bear alone and most of us can't participate with you at
all nor understand it at all.
But we can continue to say thank you, regardless of any and all decisions and
outcomes.
Now, I hope Alex Martelli decides to volunteer to help Mark Hammond do a PythoNet.
I hope Alex volunteers to lead an open source effort himself, should Mr. Hammond
decide to not do so. I am sure it would help the Python community immensely of
they did so. But even if they don't, Python has a great future.
Why?
1. Microsoft rules. VB and C# will therefore rule. Most of all, Visual Studio .NET
will truly rule. Java will not go away and will be very important. Perl and even
JavaScript and other scripting and glue languages have roles for quite a while.
Other great but boutique languages will make some very happy, like Oberon,
Haskell, Eiffel, etc. etc. etc. Lisp will have its own very efficient and
productive advocates until they all die. ;-)))
But other than the greater C family of C, C++, C#, and Java, only Python exists
today as a claimant to more than a token stance as an important general purpose
language that is still growing, at least significantly. Perl could be considered,
but is it really a general purpose language? Ruby has aspirations, and is probably
a fine language, and could be as general purpose as Python, maybe, in time, but it
doesn't have the time, nor does it have enough critical mass. The window is
closing. Only a language that has at least as much presence, tool availability and
maturity as Python has time, to my way of thinking , to survive the onslaught of
.NET and Java both and have the opportunity to evolve and grow into a *major*
general purpose language.
So, on one side you have Visual Studio, C# and VB (and also managed code C++),
pushed by the most powerful corporation the earth has ever seen; and on the other
side you have Java, with at least a five year head start and supported by IBM, Sun
and other major corporations.
In the middle, you have one open source language named after a troupe of
comedians, saddled with a snake's name that has sensitive and negative
connotations to some ;-)), and a BDFL who believes in it and in its community.
2. Python occupies a middle ground. Neither fish nor foul, neither Sun nor
Microsoft, but friendly to both companies and to open source advocates, used by
Windows developers (thanks to Mark Hammond!!!) and by Linux developers and by Mac
and BSD and other UNIX developers, Python is no one's enemy and everyone's friend.
To both the Microsoft camp and to the Java camp, one who is not my enemy is maybe
my friend, and at least can be tolerated and allowed to live.
3. Python is as widely usable as any language, if not wider. If successfully
integrated into .NET in the early days, even if not with 100% perfection, Python
will be *the* most widely cross platform, cross development environment,
programming language on earth. Java will not be so early and well integrated into
.NET, and even if it is, the Java community will not support Java.NET
enthusiastically, for obvious reasons. Python will move ahead of even Java in
open, cross platform support. And when will VB and C# be running on JVM's?
4. The Python community nurtures what is arguably one of the five most important
concentrations of software development going on today:
A. Microsoft .NET
B. Java
C. Linux
D. Mono (and what about PythoNet for Mono?)
E. Python
i. The core Python language led by Guido
ii. Jython
iii. Python.Net
iiii. Web App Servers like Zope, Webware, Skunkworks etc. etc. etc.
iiii. Commercial IDE's PythonWare, Black Adder, and Komodo
iiii. Open source Python GUI RAD tools and application frameworks
like:
a. wxPython and similar for GTK, QT, Tkinter, etc.
b. Boa Constructor
c. anygui
d. PythonCard
5. By continuing to grow as a friendly flower in the midst of the two giants (Java
and Microsoft), Python garners good will; and offers a neutral alternative for the
future.
But most of all, there is another reason, more important than any of the above and
all of the above reasons combined.
When we ask ourselves, honestly, what will still be around in the year 2010, or
even in 2020, what comes to mind, and how do we predict such things? Well,
Microsoft and its preferred offerings, whatever they are, will certainly not only
be around but will be hugely important, for the foreseeable future, due to their
corporate might and will. Java will still be around, because it has so much
momentum. The C family in general will be around; C is too important to ever be
completely replaced in the foreseeable future. But surely there is a place for a
more productive, higher level language?
OS/2 was loved by many and will not be around in 2020 or even in 2010 to any
appreciable degree. So love of a technology alone is not enough to ensure
survival.
But I am quite sure that Python will be around, and important, in 2010; and I
believe it will also be so in 2020. Why? Because so many people truly love it, in
a meaningful way (they love to use it, they use it deeply, it is a tool that helps
them be significantly more productive and yes, fulfilled in their careers and in
their passions); and because so many people will continue to love it and use it in
2010, and enough people to make a difference; and because Python is an open source
community that can not be killed in the way IBM and Microsoft killed OS/2.
Python will survive because it is open source and loved. Python will matter
because loved tools that are free, if they are loved and used by enough people,
grow and thrive.
Think about it; do you believe that Python is loved enough, by enough people, in
a useful and not just sentimental way, so that it will be used by a significant
enough number of people in 2010 to be meaningful? And if still sufficiently used
and meaningful in 2010, would not Python be situated to possibly become important,
in the middle ground of computer languages?
I actually believe this; I hope you do too.
I humbly salute and honor Guido and Mark and Alex and all of the other heroes of
the Python community. I hope some of these heroes propel Python .Net forward.
But under any circumstances, I have a sober faith that Python will do well, and I
will continue to use Python and cherish its community lovingly..
Ron Stephens
Neil Hodgson
> Mr. Hammond, why is Python on .NET not currently viable? Also, do you
think
> ActiveState will stick with it until it is viable?
I can't speak for Mark, but my main problem with Python.NET is speed. The
.NET EULA does not allow posting benchmarks but Python.NET is seriously slow
unlike Jython which is comparable to CPython. Currently, if you want to use
Python in a .NET application you may be better off linking to the CPython
interpreter over COM interop.
Neil
David Bolen
> I have a question that I hope someone can partially
> answer. ActiveState has a beta of Visual Python for .Net on their
> web site. I can not use it because I do not have access to a beta of
> Microsoft's Visual Studio. However, the ActiveState beta of Visual
> Python must have at least basic functionality.
>
> How basic is that functionality? How much is left out? Are there big
> differences between the language supported as Visual Python and
> c-Python as we know it?
I'm not sure you're referring to exactly what you think you are, if I
read the rest of your post correctly - although it's understandable.
"Visual Python" is an integration of Python into the Visual Studio
development environment (it occurs with .NET since it's an integration
with Visual Studio 7, which is the .NET release). Thus, it's a
plug-in for the IDE.
But that's not the tie in of Python into the .NET framework as one of
its languages sharing the common back-ends. For that, there was a
Python.NET (or actually Python for NET to avoid possible trademark
infringement with MS use of .NET as a suffix to everything in the
world nowadays) project, which has (I believe) now concluded after
initial work on a prototype proof-of-concept (sponsored by MS), but
for which there is currently no active development.
In terms of why it was concluded, and/or some of the issues with
.NET's support for dynamic, scripting languages, you should probably
refer to the .NET research page at ActiveState:
http://www.activestate.com/Initiatives/NET/Research.html
and in particular, to the white paper describing the experience of
creating the Python for .NET compiler.
http://www.activestate.com/Initiatives/NET/Python_whitepaper.doc
The problems mentioned in the paper probably aren't insurmountable,
but they aren't trivial either.
Roman Suzi
No, IT workers will unite and strike ;-)
"Python! Python! Python! ..."
And then elect GvR the president of United Nations.
Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ r...@onego.ru _/
_/ Tuesday, September 11, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "I was the next door kid's imaginary friend." _/
Robin Becker
<r...@onego.ru> writes
...
>"Python! Python! Python! ..."
>
>And then elect GvR the president of United Nations.
>
>Sincerely yours, Roman Suzi
2.2 with qualified minority voting or some such.
--
Robin Becker
Roman Suzi
But we will have too:
from __future__ import hope
;-)
Sincerely yours, Roman A.Suzi
--
- Petrozavodsk - Karelia - Russia - mailto:r...@onego.ru -
Robin Becker
<db...@fitlinxx.com> writes
....
> http://www.activestate.com/Initiatives/NET/Python_whitepaper.doc
....
really strange, I just downloaded this and when attempting to run it I
get
the instruction at "0x300ab673b" reference memory at 0x0085a000, the
memory could not be read etc etc
I'm using Win2k SP1, Office 2000. I suppose this is an indication of why
we should all be using .NOT .NET :)
--
Robin Becker
David Bolen
> In article <uzo82f...@ctwd0143.fitlinxx.com>, David Bolen
> <db...@fitlinxx.com> writes
> ....
> > http://www.activestate.com/Initiatives/NET/Python_whitepaper.doc
> ....
> really strange, I just downloaded this and when attempting to run it I
> get
Hmm, worked fine directly from my browser (WinNT SP4, Office 2000).
> I'm using Win2k SP1, Office 2000. I suppose this is an indication of why
> we should all be using .NOT .NET :)
:-)
Markus Schaber
> On Tue, 11 Sep 2001, Robin Becker wrote:
>
>> In article <mailman.100018177...@python.org>, Roman
>> Suzi <r...@onego.ru> writes
>> ...
>> >"Python! Python! Python! ..."
>> >
>> >And then elect GvR the president of United Nations.
>> >
>> >Sincerely yours, Roman Suzi
>> hope not, else perhaps 10 years down the road we'll have United
>> Nations 2.2 with qualified minority voting or some such.
>
> But we will have too:
>
> from __future__ import hope
Bob Hope as python module? Bizarre :-)
markus
--
"The strength of the Constitution lies entirely in the determination of
each citizen to defend it. Only if every single citizen feels duty
bound to do his share in this defense are the constitutional rights
secure." -- Albert Einstein
Mats Wichmann
wrote:
:So maybe we need good marketeers more than we need technical improvements.
:Of course, good marketeers are just as rare in the open source world as
:they are in the world at large;-).
Sadly true.
I've run up against this problem. Some of you know I wrote a Python
course for one of the largest technical training houses. They've been
unable to market/sell it effectively: the audience they do know how to
reach does not appear to know what Python is, and it ends there:
frankly I don't think our organization has the skill/interest to
actually "market" it, if it's in the catlog and somebody asks for it
we'll take the order. So there's clearly a large part of the world
that knows nothing about Pythion. In other classes I teach
(UNIX/Linux) I often mention Python and it's rare if more than 10% of
the students have even heard of it.
Mats Wichmann