Is Python worth learning?

[Alex Martelli]

"Crow and Servo" <you at somehost.somedomain> wrote in message
news:1YCs5.31979$K5.513760 at typhoon.austin.rr.com...
> I am fairly new to Python.  I have been using VB, C++, and Java most of my
> life.  I am debating whether it is worth learning Python over just
sticking
> with Java.  It seems Python does not have any real good DB support for MS
SQL
> server (at least not that I can find online and free).

Appearances may be deceiving you: Python has *GREAT* support for MS
SQL Server.  It's freely downloadable from the Microsoft site, and
it's called MSDAC 2.5 (MS Data Access Components) -- a package which
includes Microsoft's various preferred ways to access their DB's.
(You probably already have it around, as it comes with so many MS
products, but do check it's the latest version, for all of the usual
reasons).

My personal favourite, out of these 'preferred ways', is the pair of
COM object models called ADO and ADOX -- which is also what MS is
pushing hardest (and has been for years), and also what is most often
used for DB access from Visual Basic, ASP's (and other uses of MS
scripting languages), etc.  ADO gives very handy access to data
through a rather abstract model, which matches well with a relational
DB but also allows access to differently structured data (e.g.,
MS SQL's OLAP functionalities); ADOX gives access to DDL and security
issues in a more portable, higher-level way than just querying system
tables or issuing DDL/security statements via SQL.

Anyway, ADO/ADOX are set up for optimal access via COM/Automation,
and Python is really very good at that thanks to Hammond's 'win32all'
package (specifically, the 'win32com' part of it).  Whenever there's
good COM/Automation level access (basically everywhere, today, on
Windows platforms), Python can hold its own.  After Python-wrapping
a COM typelibrary with the makepy tool (from Pythonwin, under the
Tools menu, for example), you'll also get (in Pythonwin) a helpful
simulation of VB's "intellisense" (not quite as good as in VB, but
then, VC++'s intellisense is also not quite as good as VB's); the
wrapping is not needed (much like, in VB, you *can* avoid adding
a typelib to project/references, and work with "dim x as object"
and "set x = CreateObject" stuff), but it's advisable (for similar
reasons to those that make it advisable in VB).

Via COM/Automation, you can also use Python to access different
wrappings of SQL Server functionality, but I strongly suggest you
try ADO+ADOX first/instead.


The main alternative to COM/Automation level interfacing is good
old ODBC.  Personally, I'm no fan of it (I prefer the richer and
more OO wrapping in ADO/ADOX), but it does have its strong points.
With Python, the best ODBC access is probably what you get from
Lemburg's mxODBC.  I've only cursorily tried it with SQL Server
(specifically, with the MSDE package -- the freely redistributable
small-scale SQL Server engine that MS gives out), but it seemed
to work just fine (_Jet_, aka 'MS Access DB engine', is the one
that has limitations, in version 4, re what's accessible by ODBC
vs what's exposed via UDA [the Universal Data Architecture, which
is embodied in MSDAC, and composed of ADO, ADOX, OLE/Db, ...];
SQL Server seems to suffer from no such handicap, at least up to
version 7 -- haven't played with SQL Server 2000 *yet*).


> Is Python going to give Java a run for its money someday, or does Java
have too
> much of a lead?

Python is not going to "displace" Java, any more than it's going
to "displace" C, C++, Eiffel, ML, Haskell, or C#.  Different
languages are suitable to solve different problems, and, often,
different *parts* of the same problem.  One of Python's special
strengths is that it plays SO well with other environments, fully
including other languages.  For example, if deploying through a
JVM is your eventual goal, you should be prototyping in JPython,
the Python version that compiles to JVM bytecode; once your
solution is fully developed in JPython, if its performance is
not quite what you want it to be, you carefully measure/profile
things, and selectively recode/optimize those components which
are proving to be a performance bottleneck (but stay at the
highest abstraction-level you can: often, the best optimizations
available will be "MACROSCOPIC" ones, changes in algorithms,
data structures, architecture, which Python will make easiest to
play/experiment/exploree with; recoding in a lower-level language,
such as Java if a JVM is your deployment target, is a last-ditch
measure, for when you've exhausted your macro-level options).

If your deployment target is not a JVM, but a 'normal' kind of
application, you will similarly prototype with Python (the
'mainstream' one, aka CPython) and your later selective recoding
of some components will be, say, in C or C++.  If, in the near
future, you plan to deploy on Microsoft's ".NET", you will soon
be able to prototype with Python.NET (see the ActiveState site)
and your later selective recoding will probably be in C#.

Note a common thread...?  You can and should prototype in Python
whether your deployment target is JVM, 'classic', or .NET.  You
may then, *IF* it proves necessary, recode some parts in the
lower-level, 'system' language most suited to your intended
deployment platform, be it Java, C++, or C#.  Pretty often,
depending on what your applications do, no such 'recoding' will
be necessary, and the rapidly-developed Python 'prototype' may
be prettied up, 'consolidated', and delivered/deployed as the
resulting product (particularly because your Python code can
access such a huge array of already-existing components and
libraries -- anything in the Java library, for JPython; anything
that exposes CRL, for Python .NET; anything that exposes COM
Automation, for 'classic' Python on Windows; ... plus, Python
specific very nice pieces, such as the Numeric extensions if you
do lots of computation, the PIL if you do image processing,
PIDDLE if you do graphics, ... ).


Python is a peculiar mix, with the hardiness of a weed and the
delicacy of a prize rose.  I predict a long and happy survival
for it -- it will keep flourishing in very diverse environments,
and deliver satisfaction, productivity, and good integration
with the rest of each specific environment, to its wise users...!


Alex