[sqlalchemy] Re: Should RowProxy behave as a standard Python sequence?

Mike Bayer writes: > reinstate the whole thing in 516a442f233d90eb7b8bb844e2dea7865bb21f66... Ok, see https://github.com/zzzeek/sqlalchemy/pull/231 thank you, ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas |

[sqlalchemy] Re: Should RowProxy behave as a standard Python sequence?

Mike Bayer writes: > On 01/27/2016 05:32 AM, Lele Gaifax wrote: >> Here is the diff implementing the third option: it still need to touch also >> the C implementation, because that does not use the metadata keymap when the >> key is an integer. > > awesome, you're

Re: [sqlalchemy] Re: Should RowProxy behave as a standard Python sequence?

On 01/27/2016 11:37 AM, Mike Bayer wrote: > > > On 01/27/2016 05:32 AM, Lele Gaifax wrote: >> Mike Bayer writes: >> >>> Let's consider going with the third option I mentioned, I dont think >>> this will add too much expense if you could test this out please >> >>

[sqlalchemy] Re: Should RowProxy behave as a standard Python sequence?

Lele Gaifax writes: > Let me know how you prefer me going forward: I can easily try out your (now > reverted) change, but it's up to you. The following patch: -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe

Re: [sqlalchemy] Re: Should RowProxy behave as a standard Python sequence?

On 01/27/2016 12:57 PM, Lele Gaifax wrote: > Mike Bayer writes: > >> OK my change has revealed a bug in my test suite that wasn't catching >> that my change fails. The C implementation uses the keymap for >> integers. Where are you looking that it doesn't ? > >

[sqlalchemy] Re: Should RowProxy behave as a standard Python sequence?

Mike Bayer writes: > Let's consider going with the third option I mentioned, I dont think > this will add too much expense if you could test this out please Here is the diff implementing the third option: it still need to touch also the C implementation, because that

Re: [sqlalchemy] Re: Should RowProxy behave as a standard Python sequence?

this is great. but you know throwing an isinstance() right into the otherwise no-latency __getitem__ (the pure python version) there is making me think this may be better as a key fallback, so the expense is limited just to the negative integer case (or another idea, the negative int keys could

[sqlalchemy] Re: Should RowProxy behave as a standard Python sequence?

Mike Bayer writes: > throwing an isinstance() right into the otherwise no-latency __getitem__ > (the pure python version) there is making me think this may be better as a > key fallback, so the expense is limited just to the negative integer case > (or another idea, the

Re: [sqlalchemy] Re: Should RowProxy behave as a standard Python sequence?

On 01/25/2016 01:41 PM, Lele Gaifax wrote: > Mike Bayer writes: > >> throwing an isinstance() right into the otherwise no-latency __getitem__ >> (the pure python version) there is making me think this may be better as a >> key fallback, so the expense is limited just

[sqlalchemy] Re: Should RowProxy behave as a standard Python sequence?

Here is my initial diff: diff --git a/lib/sqlalchemy/cextension/resultproxy.c b/lib/sqlalchemy/cextension/resultproxy.c index 9c4d0c7..3e40ec1 100644 --- a/lib/sqlalchemy/cextension/resultproxy.c +++ b/lib/sqlalchemy/cextension/resultproxy.c @@ -271,6 +271,8 @@

[sqlalchemy] Re: Should RowProxy behave as a standard Python sequence?

Mike Bayer writes: > On 01/24/2016 11:11 AM, Lele Gaifax wrote: >> I wonder whether there is an underlying reason or if it's just an oversight. > > both? the rowproxy is addressable by lots of things like strings, > Column objects. if we want to add negative index