Python: Database to Web Part II (and "teaching language")

Paul Boddie paul at boddie.net
Mon Jul 9 12:15:43 EDT 2001


Ville Vainio <vvainio at karhu.tp.spt.fi> wrote in message news:<yox66d25zkd.fsf at karhu.tp.spt.fi>...
> web2ed at yahoo.com (Edward Wilson) writes:
> 
> > I have been hoping that someone else would write Oracle, DB2, and SQL
> > Server drivers/modules for Python, so I wouldn't have to.  Mostly
> > because I haven't had time, and also because such an undertaking is
> > better suited for a group with a formal review board rather than an
> > individual code Maverick.

There are some drivers/modules which have indeed written by commercial
groups for commercial purposes: cx_oracle and DCOracle are two
examples, as far as I am aware. It's certainly unkind to bundle all
one-man efforts into the "Maverick" category, anyway, as I'm convinced
that some of these efforts do actually need to underpin "serious
business". The source code is typically available for your review, of
course. ;-)

That's not to say that one doesn't have a certain feeling of unease
when evaluating Python modules for serious database use, however. It
does seem like a reflection of the open source community at large when
there are lots of seemingly incomplete modules covering certain
narrow, fashionable areas, and few modules covering other areas.

I mean no offence to any database module author when I use the term
"incomplete"; my definition of "completeness" may differ from that of
any given developer in this case, and presumably most database authors
are satisfied with what they have written. Moreover, I wouldn't like
to make any criticism of the reliablity of any module without having
seen it first. I sometimes get concerned that serious commercial users
are likely to have views on issues of functionality and reliability
even more extreme than my own, however.

Nevertheless, I do wonder why there are shedloads of PostgreSQL
modules - is it licensing, implementation style or something else
which causes everyone to have a go?

> I have to agree with this. There should be one, obvious choice for a
> database package. This would do wonders to popularity of Python and
> would beef up all attempts to convince management (and fellow
> programmers) that Python is a superior solution. It should also be
> non-restricted open source (not GPL, not "free for non-commercial
> use").

Well, there may be one "obvious choice" to you, but I would hope that
in Edward's "real world" there would be a need to address several
choices of implementation (or rather deployment). It's bad news for a
number of developers if the Python community suddenly settles on a
JDBC- or ODBC- oriented framework around which all future effort is to
take place, when some organisations may not wish to invest in optional
or third-party connectivity layers. For some people, it's the native
libraries' interface or nothing.

However, if you are referring to a standard API for databases, then
one already exists. Unfortunately, most modules aren't compliant with
the most recent version of that API as far as I can tell.

I accept your point about licensing. Writing a database module and
licensing it under the GPL is madness. It's like applying a label to
it which reads "don't use me, write your own!"

> > I dare say, that Python would smash Java, Perl, Visual Basic, and any
> > other new age tool (C/C++ dodgers) if it only had certifiable database
> > support on par with that of JDBC.  This is not to say that JPython, or
> 
> We will see what Micro$soft's .NET will bring along as far as DB
> support goes... if it would make all languages "equal" in DB access
> (and Python gets a good .NET support), the stage is ours on the Win32
> arena :-).

I wouldn't mind seeing some more concrete freely-available
documentation for Win32 Python. Without the O'Reilly book (which I
don't have and can't justify buying) it really does seem to be
guesswork at times. Of course, some people would wonder about
concentrating solely on Win32 for serious business too.

> > I pray to the Python Gods "please bless us with a Python JDBC
> > counterpart" and all in the world will be in balance.
> 
> Amen.

If you want JDBC for Python, there's an implementation already, albeit
for Jython:

  http://www.ziclix.com/zxjdbc/

If you want people to implement yet another connectivity standard then
you'd better get talking to the database system vendors. ;-) JDBC for
CPython would be useful, though.

> BTW, another thing to do for the "image" of python - stop emphasizing
> the newbie-friendlines, it traditionally repels the more advanced
> programmers who often think there is a trade-off between that and
> power. "Teaching language" is a somewhat uninteresting concept,
> learning to program isn't hard enough to warrant having languages
> specific to that. Besides, only l4m3rs need to be taught programming
> anyway ;-).

I haven't seen any particularly notable bias towards "newbies" in this
group. Anyway, if people want to go and develop their applications
entirely in C (as seems to be fashionable in certain open source
circles), because they believe that Python isn't for real programmers
or is too slow or "wasteful", then they can feel free to do so and
waste their own time in the process.

Edward's right in one respect: stop concentrating on language issues
and start concentrating on library issues. It's shocking but
illustrative that many people claim to choose Perl for work purely on
the basis of library availability for that language.

Paul



More information about the Python-list mailing list