Phillip J. Eby wrote:
Ty Sarna and I have come up with a concept for this, which we have not yet implemented, as we are still finalizing design details. We believe that it could be made quite general. The basic idea is that you have a "Predicate" interface, for objects which can be combined with "and", "or", and "not" to result in more complex predicates. The Predicate interface would also include functions to return a Generator or a Filter. A Generator is an object which can return a list of objects matching the Predicate, while the Filter is a callable object which may be passed an object and returns true if the object matches the Predicate. Generators and Filters have to also provide a small amount of metadata indicating their cost to filter or generate information.
Phillip... Putting relational operations directly into Python will have substantial repurcussions. The Python community may not appreciate having Guido run over by the Distributed Database Bus, not to mention the 'interesting' vision of relational db people converting to Zen. Pandora, in her wildest dreams... However, since you have opened the box, let us proceed... I have a few problems with the SubMine datamining concept, however I think the basic concept is very encouraging. In our situation, the existing databases are 'alive' (including the schemas). The schemas are defined in each query using a few relatively simple rules. One of the reasons they still use a file-systemed database is that in this environment (population genetics research), simply not enough is known to structure a traditional relational database and almost everything is volatile. The problem is that you have to browse the database in order to formulate a query. Submines allow our scientists and data analysts to browse the databases and determine the relationships they need to impose interactively. They love it because it acts somewhat like a statistical analysis package but acts directly on the database tables (not to mention via the web). The big problem with current SubMines is that the filters are inseparable from their data objects. They are not pythonic and can only exist in the context of a __bobo_traverse__. I've been trying to determine a way to reference them from another object in order to perform joins etc., and I had pretty much decided that their non-pythonic nature is a show-stopper here. What you propose might pythonize Submine filters if there is a way to traverse them without using __bobo_traverse__. Even if they can't be traversed, I think the predicate concept stands to transform how we do things. Me.sitting.bus_stop.waiting.impatiently.beside.self.for(Phillip.explain)