The Microsoft Platform Ahead by David Platt; thoughts about Python and Zope

[John Benson]

Hi, I've been reading the above-titled book and it looks like some major
Python and Zope features have been cherry-picked for pushing down into .NET,
like application memory management (Python interpreter), and prefabricated
website user management (Zope).

I know that these didn't originate with Python and Zope, and also that .NET
adds extra Microsoft-specific goodies. However, the real possibility is that
the Microsoft-centricity of .NET may diminish in time when VB.NET/C#
/ASP.NET provide an attractive multiplatform alternative to Python and Zope
or other content-management/portal/web service frameworks.

The question I'd like to pose is:

Will the open-source web service frameworks suffer the same fate as the
Netscape browser?

The most likely scenario I see is that Python will remain important as a
standalone language and one of the Microsoft CLR (Common Language Runtime)
language alternatives (like VB.NET and C#) but that great frameworks (like
Zope and Twisted) will be crowded out as Microsoft appropriates and
repackages their functionality. Comments?

The one opportunity for Python and the open-source frameworks to survive and
thrive is that Microsoft has targeted XML Web Services and authentication as
basic functionality in .NET. That is, as it currently understands them. The
admission in the book that Web Services are in their infancy leaves open the
possibility that Microsoft may be playing catch-up with smaller and more
agile frameworks in this area until the technology matures. Please forgive
the oxymoron. It is probable that no computer technology matures: it either
evolves or dies, or hangs on in the living death of legacy maintenance.)

 

[Peter Hansen]

Will the open-source web service frameworks suffer the same fate as the
Netscape browser?

You mean, the one most recently making headlines under the title
"Firefox"? ;-)

-Peter

 

[Diez B. Roggisch]

I know that these didn't originate with Python and Zope, and also that

.NET adds extra Microsoft-specific goodies. However, the real possibility
is that the Microsoft-centricity of .NET may diminish in time when
VB.NET/C# /ASP.NET provide an attractive multiplatform alternative to
Python and Zope or other content-management/portal/web service frameworks.

They still won't run on unix - which is for many people a reason not to use
them.

Will the open-source web service frameworks suffer the same fate as the
Netscape browser?

Netscape was a product selled - zope and twisted aren't.

 

[Carlos Ribeiro]

Hi, I've been reading the above-titled book and it looks like some major
Python and Zope features have been cherry-picked for pushing down into .NET,
like application memory management (Python interpreter), and prefabricated
website user management (Zope).

<irony>
I would be concerned if Microsoft was pushing for patents on things
previously implemented by Python or Zope.

Will the open-source web service frameworks suffer the same fate as the
Netscape browser?

Microsoft has show with the IE 6 fiasco that they have no long-term
commitment. As soon as they think that they have obliterated
competition they stop developing. And their customers are learning it
too. For many companies older versions, such as NT4 and Win98 are
still quite usable... but as MS discontinues support, it *forces* them
to upgrade. Worse: there are applications written for older frameworks
that simply will not be supported in the long term. It's why so many
people are concerned about XForms, Avalon and stuff -- they have
bought MS technology previously, and they will have to buy it again,
with all the upgrade cost, just to keep working. Not a good way to run
a business.

The most likely scenario I see is that Python will remain important as a
standalone language and one of the Microsoft CLR (Common Language Runtime)
language alternatives (like VB.NET and C#) but that great frameworks (like
Zope and Twisted) will be crowded out as Microsoft appropriates and
repackages their functionality. Comments?

Perhaps I'm a little paranoid, but I am afraid that the CLR version of
Python may lead to a split of sorts in the long term. Jython is always
a little behind, but as far as I know, it still follows C Python
steps. The CLR is a *big* library, and it's backed by Microsoft, which
makes it quite attractive for a number of developers. I'm afraid that
its direct use may lead to a distinct 'dialect' of sorts (due to the
use of the CLR) than C Python with the standard Python library. The
language is the same, but the programs would hardly be portable (I
don't place my bets on Mono either). But again, I may be just paranoid


--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Steve Holden]

<irony>
I would be concerned if Microsoft was pushing for patents on things
previously implemented by Python or Zope.



Microsoft has show with the IE 6 fiasco that they have no long-term
commitment. As soon as they think that they have obliterated
competition they stop developing. And their customers are learning it
too. For many companies older versions, such as NT4 and Win98 are
still quite usable... but as MS discontinues support, it *forces* them
to upgrade. Worse: there are applications written for older frameworks
that simply will not be supported in the long term. It's why so many
people are concerned about XForms, Avalon and stuff -- they have
bought MS technology previously, and they will have to buy it again,
with all the upgrade cost, just to keep working. Not a good way to run
a business.

Microsoft's financial results prove that it's actually an excellent way
to do business, as long as all you are interested in is financial
results. When you start to consider the suboptimal economic nature of
such a methodology, however, the capitalists start hurling around words
like "socialism" which they use in a perjorative sense without real
understanding ;-).

The point is that Microsoft appear to feel threatened by open source
because to work in that arena would remove the vital element of control.
They aren't interested in the greatest good for the greatest number,
they are interested in the greatest good for Microsoft stockholders.

Perhaps I'm a little paranoid, but I am afraid that the CLR version of
Python may lead to a split of sorts in the long term. Jython is always
a little behind, but as far as I know, it still follows C Python
steps. The CLR is a *big* library, and it's backed by Microsoft, which
makes it quite attractive for a number of developers. I'm afraid that
its direct use may lead to a distinct 'dialect' of sorts (due to the
use of the CLR) than C Python with the standard Python library. The
language is the same, but the programs would hardly be portable (I
don't place my bets on Mono either). But again, I may be just paranoid

I think you probably are being a little paranoid (though even the
paranoid can have enemies). As long as the CLR remains an API rather
than getting built into the language Python will be just fine. Take Mark
Hammond's win32all extensions as an example of what might happen.

I've written Windows services, and used Windows-specific functionality,
to deliver what customers asked me for. The solutions are still Python,
despite the fact that they aren't portable to any other platforms than
Windows.

The day *I'll* start complaining is the day Python-from-Microsoft starts
to sprout new keywords and syntax features that don't exist in other
implementations. Personally I have enough faith in Jim Hugunin's
integrity to be pretty sure he'd resist such trends, though perhaps not
enough faith in Microsoft as a whole to be sure such changes wouldn't be
railroaded through if there were some perceived corporate advantage.

Frankly, though, it will be a long time before Python is anything but a
minority platform for Microsoft users, given the huge number of VB and
C# programmers, not to mention the Java camp.

In the long term the only way to change Microsoft's behavior is to
engage with them and have them perceive that their current technological
isolationism is against the long-term interests of their shareholders.
This will not be an easy dialog.

As far as using CLR functionality from Python goes, I'd hope that mono
will allow us to do the same (sort of) things in other environments.

regards
Steve