In article <14e44c9c-04d9-452d-b544-498adfaf7...@d8g2000yqf.googlegroups.com>, Carl Banks <pavlovevide...@gmail.com> wrote:
> Seriously, almost every other kind of library uses a binary API. What > makes databases so special that they need a string-command based API? > How about this instead (where this a direct binary interface to the > library): > > results = rdb_query(table = model, > columns = [model.name, model.number]) > > results = rdb_inner_join(tables = [records,tags], > joins = [(records.id,tags.record_id)]), > columns = [record.name, tag.name]) > > Well, we know the real reason is that C, Java, and friends lack > expressiveness and so constructing a binary query is an ASCII > nightmare. Still, it hasn't stopped binary APIs in other kinds of > libraries. Well, the answer to that one is simple. SQL, in the hands of somebody like me, can be used to express a few pathetic joins and what I do with it could probably be handled with the kind of API you're describing. But, the language has far more expressivity than that, and a domain-specific language is really a good fit for what it can do. The problem is not so much that SQL queries are described as text strings, but that the distinction between program and data gets lost if you build the query as one big string. What you need (and which the Python API supplies) is the ability to clearly distinguish between "this text is my program" and "this text is a value which my program uses". Python has the same problem. If I had a text string, s, which I read from some external source, and wanted to interpret that string as an integer, I could do (at least) two different things. # Thing 1 myInteger = int(s) # Thing 2 myInteger = eval(s) for properly formed input, either one works, but thing 2 loses the distinction between program and data and is thus dangerous. Exactly like building a SQL query by smashing a bunch of strings together. -- http://mail.python.org/mailman/listinfo/python-list
