Am 09.02.2016 um 23:15 schrieb Ross Reedstrom:
Have more than one choice at any point in an software ecosystem usually leads to both choices getting better.
Yes, that's also my experience. When everybody relies on a certain software, there is little room for experimentation, you start to believe that things always need to be done a certain way, and you don't dare to change anything. The fact that there are several drivers for Postgres available is also good for the Postgres ecosystem in general.
/me wonders just how deep a refactor Django would need to support PyGreSQL
The problem here is that Django has only one layer "Postgres" with the driver already baked in, and does not separate between database dialect and driver as SQLAlchemy does. It would not be a big problem to factor the driver out and provide more abstract database classes for Postgres that could be inherited by concrete driver implementations. But it would need to happen inside the Django project. Not sure if they really want that, since the whole philosophy of Django is to be one monolithic block with everything baked in, but with little room for choice. That's not something negative - in fact it's a big advantage for developers, particularly starters, in view of the paradox of choice and "analysis paralysis" that can hit you when starting a web project. On the other hand, for experienced programmers it's a disadvantage that you can't easily replace components. For instance, I'd love to use Django, if it only would support SQLAlchemy instead of its own ORM. (I guess you *can* somehow use SQLAlchemy with Django, just as you can use other drivers, but it is certainly not seamless, as it was not made with that kind of pluggability in mind.) That's why I prefer web frameworks like TurboGears and Pyramid.
-- Chris _______________________________________________ PyGreSQL mailing list [email protected] https://mail.vex.net/mailman/listinfo.cgi/pygresql
