add a numpy recarray example to /examples.

[Former user]

I think it would be cool to have an option to obtain the results of a sqlalchemy query as a numpy's recarray, instead of a list of tuples as it is now.

Examples:

>>> data = session.query(People.name, People.surname, People.apples, People.pears).as_recarray()

# data is now a 'table-like' object, to which you can access columns by their name, as in a dictionary, and that can be used a s input for many scipy's functions.
>>> data['name']('name')
Albert
Mario
Luigi
Giuseppe

>>> print data['name']('name'), data['apples']('apples')
Albert 10
Mario 20
Luigi 13
Giuseppe 15

>>> pylab.plot(data['name']('name'), data['apples']('apples')

I don't know if it is already possible to obtain something like this, but I couldn't find anything related with google. It would greatly simplify plotting and statistics calculations with sqlalchemy, and it won't be too difficult to implement (however I admit that I don't know much of sqlalchemy's code) The R's RMySQL library (R is a programming language for data analysis and plotting - http://www.r-project.org/) already works like this, and it is very useful; however it is not an ORM library and not python.

You can find some documentations on numpy's recarray here: - http://www.scipy.org/Numpy_Example_List#head-bf12166d60e12d84eebf19e80b5233e346e9d7f4 - http://www.scipy.org/Tentative_NumPy_Tutorial

but it seems that better documentation will be published soon.

[Mike Bayer]

we certainly can't add any "numpy" imports to SQLAlchemy , if that's what's implied here.

The use case here would be most easily addressed by subclassing Query, which is easy to do. Add the as_recarray() methods to your subclass that does whatever it needs to do, and then install that subclass in your Session using the query_cls flag.

An example of using custom Query subclasses is at UsageRecipes/PreFilteredQuery.

[Former user]

It won't be strictly necessary to introduce a new dependency: a try/import would be sufficent to check whether numpy is installed and to disable the method in case it is not.

It would be a simple hack that will open the collaboration between two big libraries, numpy and sqlalchemy, and will probably will useful also to the people who are not using numpy's array now.

I'll see if I can submit a new recipe.

[Mike Bayer]

Replying to guest:

It won't be strictly necessary to introduce a new dependency: a try/import would be sufficent to check whether numpy is installed and to disable the method in case it is not.

the issue is not that it adds a dependency, its that SQLAlchemy is a library itself, not a framework.

It would be a simple hack that will open the collaboration between two big libraries, numpy and sqlalchemy, and will probably will useful also to the people who are not using numpy's array now.

right but, there are integrations with PostGIS and ElementTree for example which are present in /examples. There's other packages out there which integrate with all sorts of things like Plone, PyGTK, etc. So it is standard for such things to be outside of SQLAlchemy core and to instead be in /examples, usagerecipes, or elsewhere.

[Mike Bayer]

this is a very useful idea but its specific to a certain library and is outside of the scope of core SQLAlchemy - the best we can do is to illustrate it in examples/. The recarray concept here looks very simple and can likely be constructed in a few lines of code, possibly implemented into a Query subclass that supports an as_recarray() method.

[Mike Bayer]

seems like no activity.