On Sun, Oct 6, 2013 at 8:10 PM, Chris “Kwpolska” Warrick <kwpol...@gmail.com> wrote: > It would require Postgres around people’s (or at least packagers’) > systems, and it often gets messy when we have such requirements.
I would hope that an absence of libpq could simply result in a courteous exception when the module's imported, but maybe that'd be hard to implement. > Also, Postgres is much harder to configure than MySQL, > especially if you have no experience or an asshole OS. You can get a ready-to-go Postgres under Debian by simply apt-getting it. The default config might not give you optimum performance, but it'll work just fine. Most people shouldn't need to dig into the configs of _any_ database before getting the app going - out-of-the-box settings should be fine for early development, even deployment if you're not doing a lot of traffic. > Moreover, the stdlib is where packages come to die. Fair point. That is an issue. > We should also educate people on how PostgreSQL works with a nice, > human-friendly tutorial. Especially in some non-standard things and > things that differ between PostgreSQL and MySQL — like how to make an > auto-incrementing ID field (use sequences), or how PostgreSQL arrays > work, among others. The wiki (that nobody reads anyways) could also > use some marketing fixes. Maybe! Possibly go a bit further and say "How-to: Python and Databasing", which could mention SQLite (great for something tiny), PostgreSQL (great for concurrency / multi-user), and "Other databases can also be used, with similar or identical APIs - check out PyPI for a module for your favorite database engine". I guess the above paragraph is sentencing [1] me to write the article, now... ChrisA [1] if you'll pardon a terrible pun -- https://mail.python.org/mailman/listinfo/python-list
