part of the 2.0 plan is that Core and ORM results will look much more the same, e.g. Core will get all(), first(), one() via an intermediary invocation object.

let's see what it looks like for ORM to return the RowProxy instead of lightweight_named_tuple():

1. we need a new "parent" for RowProxy, so SimpleRowProxyParent() will do what ResultProxy does if you have a simple list of names. I considered changing "parent" to be "key_fallback" or something but this object has a bunch of features including has_key, keys, etc.

2. the "processors" aspect of RowProxy would not be used for ORM because our "processors" are full-row processors, not per-key, and they have to be done up front (though I keep wondering if I'm not seeing something here on this).

3. items() / keys() / iterkeys() / iteritems() -> at the very least the "iter*" methods should not be there in a py3k context and we might want to fully py3k this (turn keys / items into iterators), and perhaps if py2k for now (in 1.4) we do the list version. this should be py3k-ed a long time ago. let's py3k / py2k-ize these for 1.4.

4. performance -> i have no idea which will be faster, the RowProxy obviously relies on C code for all the speed and in pure python it would not perform as well as the lightweightnamed tuple. In C code, hopefully rowproxy is faster.

5. welp, maybe Core uses lightweightproxy for all() / first() / one() if it really is better, if we go through this and see that's the case, consider flipping the whole issue around

6. Still not known is how existing ResultProxy.fetchall() / fetchmany() style methods will fit into the core version of things, perhaps the invocation object will have a "proxy()" method or something if someone really wants that...all() really should return a plain list. the only functionality we need is fetchmany(). so maybe invocation object has chunks() ?

the immediate tasks are:

1. make rowproxy work in the ORM for the lightweight keyed tuple, see what breaks

2. test the performance