Python / Apache / MySQL

[vpr]

Hi All

I want to build an Website using Apache / Python and MySQL.
I dont want to spend to much time hacking html. I'm looking for some
recommendations
e.g. should I be using mod_python ?
whats the best module for mysql ?

any suggestings so I could get my site up in a day ?

mv*********@gmail.com

[bruno at modulix]

vpr wrote:

Hi All

I want to build an Website using Apache / Python and MySQL.
Good choice, good choice, bad choice...
Why not using PostgresSQL (if you need a *real* RDBMS) or SQLite (if you
don't...)
I dont want to spend to much time hacking html. I'm looking for some
recommendations
e.g. should I be using mod_python ?
mod_python is mostly a 'low-level' Apache API binding. Better use a
higher-level tool on top of it. AFAICT, Myghty might be of some help here.
whats the best module for mysql ?
Psycopg ?-)

oops, sorry....
any suggestings so I could get my site up in a day ?

Look for Myghty, Pylons (built on Mygthy), or Django. There's also
Turbogears, but it's based on CherryPy, so you won't really take
advantage of mod_python's Apache integration.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Sybren Stuvel]

vpr enlightened us with:

I want to build an Website using Apache / Python and MySQL.
I second Bruno: swap MySQL in favour of PostgreSQL.
e.g. should I be using mod_python ?
You could use my framework based on mod_python and Cheetah. I find it
really easy to use. Check out http://www.unrealtower.org/webengine
whats the best module for mysql ?

I'd use SQLObject. It can handle MySQL (if you really want to stick to
it), SQLite and PostgreSQL.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[Kalle Anke]

On Tue, 14 Feb 2006 10:32:34 +0100, Sybren Stuvel wrote
(in article <sl**********************@schuimige.unrealtower.or g>):

I second Bruno: swap MySQL in favour of PostgreSQL.

And the reason is ?? (apart from PostgreSQL being larger and more complete,
what are the differences for "simple" usage?)

jem

[bruno at modulix]

Kalle Anke wrote:

On Tue, 14 Feb 2006 10:32:34 +0100, Sybren Stuvel wrote
(in article <sl**********************@schuimige.unrealtower.or g>):

I second Bruno: swap MySQL in favour of PostgreSQL.

And the reason is ?? (apart from PostgreSQL being larger and more complete,
what are the differences for "simple" usage?)

The reason is mostly that either you need a real, full-blown, rock-solid
RDBMS - which MySQL is definitively not - or you dont - in which case
SQLite is probably a much more lightweight and agile solution.

My 2 cents
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Kalle Anke]

On Tue, 14 Feb 2006 11:19:11 +0100, bruno at modulix wrote
(in article <43**********************@news.free.fr>):

The reason is mostly that either you need a real, full-blown, rock-solid
RDBMS - which MySQL is definitively not - or you dont - in which case
SQLite is probably a much more lightweight and agile solution.

Stupid questions (I know very little about databases):

I always thought that a SQLlite database "belonged" to a single process, can
a database be used by several processes?

Let's say I would build a small web application that would be used by a small
number of people/processes and it wouldn't be anything fancy just basic
"selects". What would be the choice for this?

What about speed? I've always had the impression that while PostgreSQL is
more complete than MySQL it's also slower.

Sorry, if these are really stupid questions but ...

jem

[Peter Hansen]

Kalle Anke wrote:

I always thought that a SQLlite database "belonged" to a single process, can
a database be used by several processes?
Depending on what you mean by "belong", that's either true or false.
Certainly multiple processes can access a SQLite database, although as
the documentation clearly describes if those processes are making
_frequent updates_ it's not the best solution and another database might
be more suitable.
Let's say I would build a small web application that would be used by a small
number of people/processes and it wouldn't be anything fancy just basic
"selects". What would be the choice for this?
SQLite. (As but one option, but "just basic selects" is certainly
included in the set of suitable conditions for SQLite use.)
What about speed? I've always had the impression that while PostgreSQL is
more complete than MySQL it's also slower.
Don't optimize prematurely? If you use something like SQLObject, or any
other means of abstracting yourself away from the details of a specific
datbase, you won't be particularly tied to it if you decide you need
improved performance, or sophistication, or whatever.
Sorry, if these are really stupid questions but ...

They're not.

[Sybren Stuvel]

Kalle Anke enlightened us with:

What about speed? I've always had the impression that while
PostgreSQL is more complete than MySQL it's also slower.

For simple queries, I believe (no real knowledge here) MySQL is indeed
faster. One of the problems I have with MySQL is that it doesn't
support foreign keys nor transactions on the default table format.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[Kalle Anke]

On Tue, 14 Feb 2006 12:04:45 +0100, Peter Hansen wrote
(in article <ma***************************************@python. org>):

SQLite. (As but one option, but "just basic selects" is certainly
included in the set of suitable conditions for SQLite use.)
I've considered to use SQLite for an application but for completely different
reasons ... hmm, I should perhaps consider SQLite for some other ideas I have
also ...
Don't optimize prematurely? If you use something like SQLObject, or any
other means of abstracting yourself away from the details of a specific
datbase, you won't be particularly tied to it if you decide you need
improved performance, or sophistication, or whatever.

That's true ... I was thinking in general terms here (a couple of people I
know handles huge data sets, genome data type of things, and in their case
speed is very important)

[Luis M. González]

Just a few comments...

Database:
As with anything else, try to keep it simple until you need to make it
complex.
Sqlite is the simplier alternative, and it's also the fastest for the
intended use (small number of users, simple selects, etc). MySQL is
also a very good alternative and much more powerful.

Mod_python:
Mod_python is the best choice (AFAIK, please correct me if I'm wrong)
if you want speed, performance and scalability. Many frameworks are
based on mod_python (Django, for example), so you can't go wrong with
it.
But let me tell you that if you just want to use bare-bones mod_python,
without any framework on top of it, you can do it, and it's not
difficult at all.
Mod_python comes with its own implementation of PSP (python server
pages), which lets you program a la PHP (intermingling python and
html).
If you want, you can also separate logic and presentation by using its
"publisher handle" along with PSP templates. If you prefer other kinds
of templetaing system, you can use them too (for example Cheetah).

For a long time I steered away of mod_python because I had the
impression it was too difficult and not user friendly enough, what once
I tried and followed the examples in the documentation, I found it to
be a very good alternative.
And the community on its mailing list is very kind and supportive. They
reply any question in a matter of minutes.

[Peter Hansen]

Kalle Anke wrote:

On Tue, 14 Feb 2006 12:04:45 +0100, Peter Hansen wrote:

Don't optimize prematurely? If you use something like SQLObject, or any
other means of abstracting yourself away from the details of a specific
datbase, you won't be particularly tied to it if you decide you need
improved performance, or sophistication, or whatever.

That's true ... I was thinking in general terms here (a couple of people I
know handles huge data sets, genome data type of things, and in their case
speed is very important)

There is information about SQLite speed starting here
http://www.sqlite.org/speed.html (where it notes that that particular
page is obsolete, but also points to the wiki for more).

The summary would appear to be that SQLite is definitely faster in some
cases, definitely slower in others, and that as usual a measurement of
inadequate speed followed by profiling is essential to knowing what to
do about any of that. :-)

-Peter

[Sybren Stuvel]

Dennis Lee Bieber enlightened us with:

I believe that since 4.1, the "default table format" is InnoDB, and
that DOES have some support foreign keys and transactions.

Finally they are starting to make more sense. I'd still rather use a
database that has had those features for a longer time, though.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[Paul Boddie]

Sybren Stuvel wrote:

Dennis Lee Bieber enlightened us with:

I believe that since 4.1, the "default table format" is InnoDB, and
that DOES have some support foreign keys and transactions.

Finally they are starting to make more sense. I'd still rather use a
database that has had those features for a longer time, though.

My experience with MySQL on the abomination that is Fedora Core (so I
imagine it was 4.x as opposed to 5.x), was that the default table type
appeared to be the ridiculously incapable MyISAM, and that by choosing
InnoDB you got transactions along with a bunch of limitations and a
serving of odd behaviour, where "odd" means "would raise a laugh
amongst users of other database systems".

I think you only really need to compare the manuals for MySQL [1] and
PostgreSQL [2] to see that PostgreSQL offers straightforward but
seemingly well-tested functionality for populating databases and then
having them just work properly, whereas MySQL offloads an array of
"features" and a mangled SQL syntax onto the developer/administrator in
a way that would suggest, if one were to be uncharitable in this
matter, that the developers of MySQL aren't confident that everything
works and would rather "empower" users to make their own choices and
then to apologise for themselves when something they thought might work
(and probably would on some other system) actually doesn't.

Anyway, various comparisons have been made, and here are a few
good/recent ones:

http://www.wlug.org.nz/PostgresVsMysql
http://sql-info.de/mysql/gotchas.html
http://sql-info.de/postgresql/postgres-gotchas.html

And here's one with a Pythonic slant:

http://bob.pythonmac.org/archives/20...12/mysql-hate/

Paul

[1] http://dev.mysql.com/doc/refman/5.0/en/
[2] http://www.postgresql.org/docs/7.4/static/