Table Oriented Programming

John Roth newsgroups at jhrothjr.com
Thu Feb 12 21:30:06 CET 2004


"Michael Hobbs" <michael at hobbshouse.org> wrote in message
news:mailman.2.1076613028.31398.python-list at python.org...
> Yeah, yeah, another X-Oriented paradigm, but please hear me out.
>
> I have recently been studying up on EJB's in order to extend my resume.
> I have looked at J2EE several times over the past years, but have never
> been impressed by it. Now that I've studied it in detail, I know why. A
> strongly typed language such as Java is poorly suited to model tables
> and relations.
>
> I got to thinking that a more dynamically typed language, such as
> Python, would be a more natural fit. I've always been fond of the
> table-oriented programming ideas described in
> http://www.geocities.com/tablizer/top.htm, so I'm thinking that if
> Python could be extended to handle table-oriented programming as
> seamlessly as it handles object-oriented programming, it could become a
> really valuable language for writing enterprise components, a la EJB.
>
> Does anyone know if anyone has already walked this path?
>
> I've given it a little thought myself, and here are some of my
> [incomplete] ideas:
>
> - Tables would be first-class values, just as classes are.
> - A table may be stored completely in memory, or it may represent a
> table stored in a database engine.
> - A table may represent the result of a query.
> - Queries are performed using a sequence of operators, rather than
> relying on SQL.
>
> Consider this example code:
>   departments = DepartmentTable
>   employees = EmployeeTable
>   johnsDepartment = (departments * employees) /
>     (employees.dept == departments.dept) /
>     (employees.name == 'John') %
>     departments.name
>   print johnsDepartment[0].name
>
> In the code above, the "*" operator performs a cartesian product, the
> "/" operator performs a selection, and the "%" operator performs a
> projection. If the DepartmentTable and the EmployeeTable are stored in a
> database engine, the expression above would generate a SQL query similar
> to "select department.name from (select * from department, employee
> where employee.dept = department.dept) where employee.name = 'John'". If
> the expression had been written "(departments * employees) /
> (employees.dept == departments.dept and employees.name == 'John') %
> departments.name", the resulting SQL would be similar to "select
> department.name from department, employee where employee.dept =
> department.dept and employee.name = 'John'", that is, without the nested
> SELECT.
>
> Of course, the entire code above could be reduced to a single line:
>   print ((DepartmentTable * EmployeeTable) / (EmployeeTable.dept ==
> DepartmentTable.dept and EmployeeTable.name == 'John') %
> DepartmentTable.name)[0].name
>
> Perhaps the list-comprehension syntax may be better suited than
> arithmetic operators. Like I said, my ideas are still a little
> incomplete.
>
> Please forgive me if this has already been discussed to death,
> - Michael Hobbs

It's an intriguing idea; I've had the occasional thought of
wanting an in-memory relational algebra implementation (which
is what he's actually specifying once you get him down off of
the hobby-horse he's riding.)

Put together a package and see whether it flies for real world
problems. That's the usual path for inclusion into Python - put a
pure Python package together, see if you can get people excited
about actually using it, and then propose it for inclusion into the
standard library.

John Roth





More information about the Python-list mailing list