[DB-SIG] Re: [Python-Dev] database APIs

[Ian Bicking]

On Tue, 2003-02-04 at 04:20, Luke Kenneth Casson Leighton wrote:
> > I'm sure you are right about constructing something along what you
> > are talking about, or using one of these available tools, but I still
> > think Python scripts, using these more abstract tools, is the optimal
> > tool do describe each form or report in.
> > 
> > What is it you can do in XML that you can't to in a structure of
> > nested lists etc in Python? 
> 
>  you can't get python accepted by perl or php programmers or
>  non-technical administrators.
> 
>  you _can_ get the pyxml libraries to read XML documents into
>  structures of nested lists etc.
> 
>  you _can_ get XML accepted by other editing systems.
> 
>  win-win.
> 
>  [you can also get flat-file and SQL databases accepted by
>   non-programmers]

I would emphasize SQL as the cross-language layer.  What you are
creating in XML is either a crippled language, or a crippled description
-- the description simply can't be general enough without a full
programming language, and you can't achieve that a full language.  And
certainly not a pleasant language, because XML is not a particularly
pleasant syntax.

A *big* reason I created SQLObject was because I didn't like XML (or
CSV) descriptions.  Besides poor tool support and an awkward syntax, XML
just isn't a powerful enough medium.  Sure, you can *create* a
programming language in XML, but I like my programming language.

If I was going to attempt language portability, I would simply create a
ORM in the other languages.  It would be easier, and the interface for
the other languages could be comfortable for those languages.  That was
another goal for SQLObject -- the schema shouldn't have any funny
requirements, because if the database is an abstraction layer and
communication tool then it shouldn't be biased towards one interface.

  Ian