Could a single web framework popularize Python?

[Alan Little]

I'm a beginner at python in my spare time. In my day job I'm an
experienced (16 years) corporate developer who has worked on a lot of
big database systems and a couple of java/XML web services projects.
I'm finding python much more pleasant and productive to work with than
java, but it's frustrating that there is no clear (de facto) standard
for developing web systems. I've been following this discussion with
interest. Here are my thoughts on the subject - which are a series of
semi-disconnected bullet points, not a coherent essay.

I see no real likelihood of python ever eating a significant chunk of
the  corporate big systems market - there's too much already invested
in J2EE (not to mention older architectures that are still heavily
used like CORBA and CICS). Java is more than good enough for the job
and the skills are readily available. Why would anybody risk their
company and their job on a completely unproven environment just
because it happens to use a nicer programming language? Coding
productivity as such is less important in this environment than proven
reliability and compatibility with existing environments.

Yes I know there are exceptions. "Google uses python" etc. etc. Google
started four years ago and did not have millions already invested in
Java, Cobol, SAP, Oracle business-critical systems. And Google uses
python for what? If they use it to drive their extremely high traffic
and usually admirably fast web front end, they're unlikely to tell
anyone how. And even if they did, their problem is very large numbers
of simple, read-only transactions none of which matter individually.
This is entirely different from, say, a typical financial system where
you have fairly large numbers of update transactions, some of them
complex, where the integrity of individual transactions matters a
great deal.

What do you mean by a "web framework"? In the Java world, JSP and
servlets are a subset of J2EE, the rest of which is aimed at
scaleability and transaction integrity for big corporate applications
that might just happen to have a web interface as one of their front
ends.  (A large proportion of corporate back office systems that are
*really* serious about scaleability and transaction integrity are
probably still running CICS on mainframes, but that's a whole 'nother
story). Full-blown J2EE is overkill for [practically anything?]
applications that just want read & update one database via a web front
end.

So are you talking about a python equivalent of Tomcat, a python
equivalent of jBoss, or a python equivalent of the J2EE standard (with
something like Tomcat as a reference implementation of part of it),
where different products could implement different subsets but there
would be at least some hope of interoperability and portability? I'm
not necessarily saying that an overblown formal standard like J2EE is
the best way to go. "Rough consensus and running code" is a better way
to arrive at de facto standards that actually work in the long run.
But in the python web world at the moment there seems to be a surfeit
of "running code" in varying states of maturity, and no discernible
"rough consensus" about how to hang it all together.

Learning J2EE for a Java programmer is easy. If you're being paid by
your employer to learn it, you use what they use. If you're doing it
with your own time & money, the only decision you have to make is
which servlet engine to use in front of jBoss. Either way, you spend
maybe half a day installing and messing about with deployment files,
and you're off. You may not be taking much advantage of all the
facilities the environment has to offer, but you're up and running and
can learn gradually from there - the mountain is high, but the
learning curve isn't steep. (Horrible mixed metaphor, sorry).

With python, you face a non-trivial research project even deciding
which environment you're going to use.

The thing you're going to hear most about is Zope, but you're also
going to hear that Zope has a high & steep learning curve before you
can  get anything working at all, and that even although Zope itself
is built using python, any existing python skills you may have aren't
going to be particularly relevant for building applications that use
it, for which you're going to have to learn some wierd template
language instead. I don't know if these things are necessarily
completely true or up to date, but they *are* what newcomers hear, and
in the case of this newcomer they were enough to put me off even
considering learning Zope.

If you decide not to use Zope, you have a choice of a wide variety of
wierd & wonderful offerings that address different but overlapping
subsets of the problem at varying levels of prototypishness. There is
no consensus as to what the emerging or de facto standards are, no
particular reason to believe that whatever you choose will be
supported or widely used in three years time - and if it isn't, the
skills you're invested your valuable time acquiring won't be directly
usable with whatever else is around. See the J2EE example above - if
BEA were to go out of business, the Weblogic folks wouldn't have much
difficulty switching their hard-earned skills over to jBoss.

My personal decision was that the advantages of python as a language
are so great that it's worth spending a bit of time finding something
that will run it nicely behind a web server for small personal
projects. I chose webware and I'm having fun playing with it. In its
current state I wouldn't feel at all confident about using or
recommending it for any kind of serious production system, even if it
was in a greenfield situation where the comments above about legacy &
compatibility didn't apply.

I don't understand all this talk about twisted as a transport
mechanism. The web runs on Apache (~70%) and IIS (~25%). Anything that
aspires to be at all widely adopted has to have speed and stability
running behind one or both of those as one of its primary goals. I
don't know much about twisted - perhaps somebody could explain where
it fits into that picture?

Alan Little
http://www.alanlittle.org/weblog