In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote:
>"Ben Sizer" <[EMAIL PROTECTED]> writes: >> I see what you mean, but unfortunately I think there is a lot more >> fuzziness than that. If the separate parts were clearly delineated >> things would be a lot better. I look to the Database API Specification >> as a great example of how this could (should?) be done, allowing for >> easy interchangeability while still providing a well-documented >> standard > >Constant queries on c.l.python for "Which DB module should I use" >would indicate that having a standard and to many choices isn't really >better than having no standard and to many choices. I disagree. Once you've picked a database (not trivial in itself, of course), you typically only have a few options for talking to in in Python. Also, typically either: - One stands out (because others have been abandoned or whatever), so there's an easy answer, or - They all work about the same, so even if you decide to switch for some reason it makes little difference. SQLObject breaks that mold, but for excellent reasons. It's nice to start from a standard and then maybe somebody figures out a really nifty way to do things. (I haven't used SQLObject yet, but I plan to try it out when things calm down a bit). If we had a standard basic web framework or a standard template language it would really help (more folks using it, more folks who can help folks learning it, better documentation, more focused development). Something better might come along, and then it'd be easier to evaluate and more appreciated. -- Russell -- http://mail.python.org/mailman/listinfo/python-list
