Steve Howell wrote:
You're wanting to solve a slightly different problem than I was, but can you elaborate on this a bit?
I know, it's more or less the complementary problem to what you're talking about. My point is that I don't like embedding SQL in my Python even when I'm dealing with a relational database, so I'm even less inclined to do so when dealing with Python data structures. I find that the existing features of the Python language do that well enough already.
Are you objecting to some ugliness of SQL itself, or do you want a more powerful abstraction?
Some of both. There's the general awkwardness involved whenever one language is embedded in another, plus the fact that I don't particularly like some aspects of SQL in particular. But often I also want a more powerful abstraction. The SQL that I need at a given point in the program isn't always fixed, and I need to generate it dynamically. As an example, in a recent project I needed to extract data from a number of tables to produce a report. The user has a variety of choices as to which fields are included in the report, and can optionally specify selection criteria for various fields, either a single value or a range of values. To accommodate this efficiently, I have to dynamically generate an SQL statement which includes or excludes 'where' clause terms of various sorts, and joins as necessary to pull in requested data from auxiliary tables. In this kind of application, there are few or no complete SQL statements written into the source, only fragments that get combined by an SQL-generation framework of some kind. So a facility like the one you suggest wouldn't help with this kind of problem. -- Greg