Re: Include pysqlite2 into Python 2.5?

Discussion in 'Python' started by Simon Brunning, Oct 21, 2004.

  1. On Thu, 21 Oct 2004 10:13:56 +0200, Gerhard Haering <> wrote:

    (snip)

    > I think that a simple embedded relational database would be a good
    > thing to have in Python by default. And as Python 2.5 won't happen
    > anytime soon, there's plenty of time for developing it, getting it
    > stable, and integrating it.


    I think it's a great idea.

    > One problem I see is that even the new PySQLite will grow and try to
    > wrap much of the SQLite API that are not directly related to the
    > DB-API. If such a thing is too complicated/big for the standard
    > library, then maybe it would be better to produce a much simpler
    > PySQLite, especially for the Python standard library that leaves all
    > the fancy stuff out. My codename would be "embsql".


    I think it's important that we realise that if Python ships with a
    default database engine, its API will rapidly become the de-facto
    standard, eclipsing the DB-API if it is different in any way.

    Which is not to say that the current DB-API should be used. There have
    been discussions elsewhere about improving and simplifying the DB-API
    - providing iterators, getting rid of all but one of the parameter
    styles, that kind of thing. Perhaps the best thing would be to agree a
    DB-API version 3.0 over on the DB SIG, then make sure that the built
    in module supports that.

    > So, what would you like to see? "import sqlite", "import embsql", or
    > "pypi.install('pysqlite')" ?


    I'd like to see a package into which you could plug different SQL
    database engines, with SQLLite as the default. So, you might do:

    from sql import sql
    sqllite = sql.Engine()
    my_database = sqllite.Database('c:/mydatabese.db', 'user_id', 'password')

    But you if you were using another engine, you'd only need to change this to:

    from sql import sql
    from other_engine import other_engine
    other_database = sql.Engine(other_engine)
    my_database = other_database.Database('c:/myotherdatabese.db',
    'user_id', 'password')

    >From there on in, ideally you wouldn't have to change *anything*.


    --
    Cheers,
    Simon B,
    ,
    http://www.brunningonline.net/simon/blog/
     
    Simon Brunning, Oct 21, 2004
    #1
    1. Advertising

  2. Simon Brunning <> wrote:

    > On Thu, 21 Oct 2004 10:13:56 +0200, Gerhard Haering <> wrote:
    >
    > (snip)
    >
    > > I think that a simple embedded relational database would be a good
    > > thing to have in Python by default. And as Python 2.5 won't happen
    > > anytime soon, there's plenty of time for developing it, getting it
    > > stable, and integrating it.

    >
    > I think it's a great idea.


    Seconded.


    > > One problem I see is that even the new PySQLite will grow and try to
    > > wrap much of the SQLite API that are not directly related to the
    > > DB-API. If such a thing is too complicated/big for the standard
    > > library, then maybe it would be better to produce a much simpler
    > > PySQLite, especially for the Python standard library that leaves all
    > > the fancy stuff out. My codename would be "embsql".

    >
    > I think it's important that we realise that if Python ships with a
    > default database engine, its API will rapidly become the de-facto
    > standard, eclipsing the DB-API if it is different in any way.


    Good point.


    > Which is not to say that the current DB-API should be used. There have
    > been discussions elsewhere about improving and simplifying the DB-API
    > - providing iterators, getting rid of all but one of the parameter
    > styles, that kind of thing. Perhaps the best thing would be to agree a
    > DB-API version 3.0 over on the DB SIG, then make sure that the built
    > in module supports that.


    Amen, hallelujah.


    > > So, what would you like to see? "import sqlite", "import embsql", or
    > > "pypi.install('pysqlite')" ?

    >
    > I'd like to see a package into which you could plug different SQL
    > database engines, with SQLLite as the default. So, you might do:
    >
    > from sql import sql
    > sqllite = sql.Engine()
    > my_database = sqllite.Database('c:/mydatabese.db', 'user_id', 'password')
    >
    > But you if you were using another engine, you'd only need to change this to:
    >
    > from sql import sql
    > from other_engine import other_engine
    > other_database = sql.Engine(other_engine)
    > my_database = other_database.Database('c:/myotherdatabese.db',
    > 'user_id', 'password')
    >
    > >From there on in, ideally you wouldn't have to change *anything*.


    Young and idealistic, I assume. Care to name two more SQL engines
    accepting exactly the same dialect as sqlite...?-)


    Alex
     
    Alex Martelli, Oct 21, 2004
    #2
    1. Advertising

  3. On Fri, 22 Oct 2004 00:33:34 +0200, Alex Martelli <> wrote:
    > Young and idealistic, I assume. Care to name two more SQL engines
    > accepting exactly the same dialect as sqlite...?-)


    Err, well, idealistic, perhaps. ;-)

    In practice, as you say, you often have to tweak your SQL for
    different engines. But you really can minimise this by sticking to the
    basics. Joe Celko's "I Will Never Have To Port This Code: Debunking
    shortcuts and SQL myths"[1] is worth a look, but I can speak from
    experience here. I'm working on a system where we mirror parts of an
    iSeries DB2 database down to SQL Server. I can and do write even
    fairly complex queries that work on both.

    Eventually.

    --
    Cheers,
    Simon B,
    ,
    http://www.brunningonline.net/simon/blog/

    [1] http://www.intelligententerprise.com/030422/607celko1_1.jhtml
     
    Simon Brunning, Oct 22, 2004
    #3
  4. On Fri, Oct 22, 2004 at 12:33:34AM +0200, Alex Martelli wrote:
    > Simon Brunning <> wrote:
    > > Which is not to say that the current DB-API should be used. There have
    > > been discussions elsewhere about improving and simplifying the DB-API
    > > - providing iterators, getting rid of all but one of the parameter
    > > styles, that kind of thing. Perhaps the best thing would be to agree a
    > > DB-API version 3.0 over on the DB SIG, then make sure that the built
    > > in module supports that.

    >
    > Amen, hallelujah.


    I'm all for it, but it's depressing that talks about it have been on
    the DB-SIG mailing list since years. The question is, if the DB-API
    3.0 should be a usable interface for application programming itself,
    or if it should still only be a driver API where higher-level modules
    need to be built on top to make it actually useful and enjoyable.
    Currently, people either do that, swear and use stuff like the crappy
    index-based access for columns, or use nonstandard extensions to the
    DB-API like dictfetch() methods or PgResultSet in PySQLite/pyPgSQL.

    If we really want this solved, we can try further discussion on the
    DB-SIG list, or maybe we could get a DB-API 3.0 sprint organized? I
    don't know if an IRC meeting would get us further faster, but it's
    worth a try.

    If all else fails, and consensus cannot be reached, then IMO it's time
    to fork and see if the courageous or the (extremely) conservative
    approach is accepted better by the community.

    > > [...] But you if you were using another engine, you'd only need to
    > > change this to:
    > >
    > > from sql import sql
    > > from other_engine import other_engine
    > > other_database = sql.Engine(other_engine)
    > > my_database = other_database.Database('c:/myotherdatabese.db',
    > > 'user_id', 'password')
    > >
    > > >From there on in, ideally you wouldn't have to change *anything*.

    >
    > Young and idealistic, I assume. Care to name two more SQL engines
    > accepting exactly the same dialect as sqlite...?-)


    I was almost making a similar comment :)

    -- Gerhard

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.4 (GNU/Linux)

    iD8DBQFBeM0YdIO4ozGCH14RAiRdAJ0WkwWwwbSfLq0EIfvGtaqfc4IlDQCeJrh9
    B/dOwV5hPHmlIey5TbYS0qE=
    =DEFD
    -----END PGP SIGNATURE-----
     
    Gerhard Haering, Oct 22, 2004
    #4
  5. Simon Brunning <> wrote:

    > On Fri, 22 Oct 2004 00:33:34 +0200, Alex Martelli <> wrote:
    > > Young and idealistic, I assume. Care to name two more SQL engines
    > > accepting exactly the same dialect as sqlite...?-)

    >
    > Err, well, idealistic, perhaps. ;-)
    >
    > In practice, as you say, you often have to tweak your SQL for
    > different engines. But you really can minimise this by sticking to the
    > basics. Joe Celko's "I Will Never Have To Port This Code: Debunking
    > shortcuts and SQL myths"[1] is worth a look, but I can speak from


    Tx, I love Celko's writing (and speaking) and I'll be sure to read it.

    > experience here. I'm working on a system where we mirror parts of an
    > iSeries DB2 database down to SQL Server. I can and do write even
    > fairly complex queries that work on both.
    >
    > Eventually.


    My hat's off to you. In my experience the only decent solution is
    always, in the end, to write a "RDBMS engine portability layer" with
    "higher level" operations mapping down to subtly different (or sometimes
    not so subtly) SQL code. But maybe this just means I'm not as good as I
    thought at writing good, portable, efficient SQL...


    Alex
     
    Alex Martelli, Oct 22, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gerhard Haering

    Include pysqlite2 into Python 2.5?

    Gerhard Haering, Oct 21, 2004, in forum: Python
    Replies:
    11
    Views:
    688
    ralobao
    Oct 24, 2004
  2. F. GEIGER
    Replies:
    3
    Views:
    1,686
    F. GEIGER
    May 18, 2005
  3. F. GEIGER
    Replies:
    1
    Views:
    652
    Gerhard Haering
    May 19, 2005
  4. Michele Simionato

    Setting the encoding in pysqlite2

    Michele Simionato, Aug 25, 2005, in forum: Python
    Replies:
    5
    Views:
    502
    Gerhard Haering
    Aug 26, 2005
  5. qvx
    Replies:
    1
    Views:
    361
    =?windows-1252?Q?Gerhard_H=E4ring?=
    Sep 28, 2005
Loading...

Share This Page