[Tutor] Why NOT to Use Python?

dman dman@dman.ddts.net
Thu, 30 May 2002 11:19:50 -0500


--8P1HSweYDcXXzwPJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 29, 2002 at 09:36:54PM -0500, Rob Andrews wrote:
| Java Server Pages (JSP) are a good argument for Java in the enterprise.=
=20

Mixing presentation and logic is just asking for a maintenance
nightmare later on.

| Python doesn't really seem to have a single obvious *killer* approach to=
=20
| production of Python Server Pages that quite compares with JSP.

Zope.  Have you actually used J2EE (servlets, JSP, EJBs)?  I had to
for a school project.  By comparison zope is trivial! =20

| In fact, Java seems to have a rather healthy set of enterprise tools=20
| that a team of team of developers can use in consistent and predictable=
=20
| ways. And when you are dealing with "lots of simultaneous users" you=20
| often find yourself dealing with a large development staff.

Is this article targeted at personal / free projects or commercial
projects?  Sun provides a J2EE implementation for "free", but the
license says you can't use it in production (because they only intend
it as a reference implementation and want you to buy a
production-quality j2ee environment from a commercial vendor).

For me the cost of the tools is a real drag (I tend to work in
very-low-budget situations).
=20
| Java can also present certain performance/speed advantages under many=20
| realistic circumstances.

Can you give any examples?  I've found python to usually be faster and
certainly more conservative in memory usage (unless you write
pathological code).

| Of course, it's not always an either/or situation. Python/Jython may be=
=20
| used for rapid prototyping and to get the product to production status=20
| before the competition does.

| Jython also presents the option of creating=20
| 100% pure Java .class files, which addresses performance and other=20
| issues out-of-hand.

That doesn't really help performance.  Take a look at the java source
for that sometime.  Basically jythonc just generates some valid java
code that feeds python source to the jython interpreter.  I think it
cuts out a little overhead, but not much, since you still need the
whole jython interpreter to run your app.

Some preliminary pystone comparisions showed jython, on jdk 1.4, to be
faster than cpython.  Supposedly that's due to Sun fixing the
performance of reflection.

| It makes a good deal of sense to consider=20
| Python/Jython development in tandem with Java development in the=20
| enterprise because of the rapid development time and maintainability.=20

Agreed.

| These aren't the only good reasons to do so, of course. Jython, after=20
| all, makes available the libraries of both Java AND Python! This is=20
| nothing to be sniffed at.

Jython doesn't provide all the python libs.  The most notable
exceptions are libs that depend on a C extension, or ones that need
the 'os' module (java is rather sparse on providing the facilities
need to finish implementing the os module).


(I've done quite a bit of work with jython too, and even used it for
some protoype and testing work in a java project)

| Dan Shafer wrote:
|=20
| >I'm working on a Python article for CNET. They want me to provide pros=
=20
| >and cons for choosing Python in creating a Web-based enterprise-type=20
| >application where enterprise is defined as meaning lots of simultaneous=
=20
| >users.
| >
| >Pros I got. Cons I don't got.

o Global Interpreter Lock
    Threads in python need to acquire the GIL in quite a few ways.
    That limits the effectivness of multithreading your python app.
    In particular it can result in degraded performarnce on a
    multi-processor system.

    ex:
    Consider one thread on one CPU and one on another.  Due to the
    GIL, one CPU is blocked waiting for the other to release it.

    ex:
    Multiple threads on a uniprocessor system.  If the system (kernel
    or python) tries to context-switch too frequently you'll waste
    time switching contex just to be denied the GIL.

    These are things often discussed by the zope community when new
    people ask about performance in a heavily loaded environment.

    Note that this con can be avoided if the traditional model of
    using multiple single-threaded processes and IPC is used in place of
    threading (each process has a separate GIL).  With zope this can
    (at least partly) be achieved using ZEO.


o "Slow"
    Python is interpreted.  As such it has overhead and is "slow".  So
    is Java and .NET.  If you need really high performance you'll need
    something lighterweight in C or C++ and that can really take
    advantage of multiprocessor systems.  (note: all the usual caveats
    regarding quality of the code and development effort apply)

    In particular, zope is kinda slow.  Typical solutions include
    caching with apache or squid in front of the zope server and
    storing static stuff (like images) on disk and served by apache.

o Marketing Hype
    There isn't any.  This is a con if you are trying to sell your
    idea to management or other non-techie type people.  The words
    "java", ".NET", "xml", "web", and "enterprise" all sound good to
    non-techs.  They can help you sell an idea even if the idea isn't
    all that great.

    Also consider Venture Capital (if you're a commercial entity).

o Commercial Support
    This may or may not be relevant.  There isn't nearly as many
    companies (dot-coms and otherwise) supporting python as there are
    those jumping on the java/xml/web/enterprise bandwagon.  This
    means it is often easier to find some sort of commercial product
    with "java" or "enterprise" in it somewhere, but much harder to
    find python ones.

    Again, venture capital may be a factor.

| >Any thoughts either way?

There really aren't a whole lot of substantive cons to python, IMO,
apart from the in-process concurrency limits. =20

| >Comparing to Java and C# and .NET strategies is probably the order of=20
| >the day, although I'm open to ideas that don't fit that box.

C# :
    MS-only.  Ximian is working on that, though.

=2ENET :
    MS-only.  Also python plugs into the .NET framework (or so I've
    heard), which means if you want to stick with MS platforms you can
    use python and .NET.

(who runs a high-availability or high-reliability site on Windows
anyways?)

Java :
    More hype than substance.  To close to C (low-level) in treatment
    of I/O and other constructs and common operations for my liking.

    Actually works better on windows than unix.  (eg Try generating
    images on-the-fly using java on a headless unix system.  You
    can't.  Sun's AWT implementation requires an X server to connect
    to.)


Based on my experiences with a variety of systems and environments, I
would choose python over the other alternatives mentioned here.

HTH,
-D

--=20

Pride goes before destruction,
a haughty spirit before a fall.
        Proverbs 16:18
=20
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg


--8P1HSweYDcXXzwPJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjz2USYACgkQO8l8XBKTpRTJfQCeI0O526YLD5fHnrNZXdfIf/ga
7BIAn06xpv/Va78W4TaVtd09b/GAoSn8
=s/Fh
-----END PGP SIGNATURE-----

--8P1HSweYDcXXzwPJ--