In article <mailman.781.1381066683.18130.python-l...@python.org>, Chris Angelico <ros...@gmail.com> wrote:
> 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. It works fine. I've had this in production for a while: # Psycopg2 is only needed for a single hacky lookup which only happens # in the station details admin tool. Installing it has compicated # dependencies, so don't worry if it's not there. try: import psycopg2 except ImportError: psycopg2 = None [...] if psycopg2 is None: logger.warning("psycopg2 not installed") return None That being said, I agree that Postgres support does not belong in the core product. Nor does MySQL, or Oracle, or SqlServer, or MongoDB, or CouchDB, or Cassandra, or a zillion other databases. There's a few reasons. One (as several people have already mentioned), it bulks up, and complicates, the release process. The other is that once something is in the core distribution, it become the de-facto "right way" to do something, whether it's the best or not. >From my own experience, I resisted trying nose for quite a while because unittest was baked in and it was "good enough". Ditto for requests vs. urllib. And finally, with something like a database driver, you really don't want your release schedule to be tied to the language. If the postgres folks come out with a new database feature (or bug fix) which requires a change to the driver, they should be able to release the new driver on their own schedule. -- https://mail.python.org/mailman/listinfo/python-list