[sqlalchemy] Re: ordering_list performance

2008-09-23 Thread jean-philippe dutreve
My use case is a bit different : new_entries can be placed everywhere into the existing SA list, not only at the end (actually it depends on the entry date). On 22 sep, 21:20, jason kirtland [EMAIL PROTECTED] wrote: Ah, looking more closely i see you're replacing self.entries with a list, not

[sqlalchemy] Re: ordering_list performance

2008-09-22 Thread jason kirtland
I'm sure there is potential for improvement on the current orderinglist code- please feel free to send a patch with optimizations you've found to the SA trac. The orderinglist hasn't changed much since 0.3, but with 0.5 there may be entirely new implementations possible. For example, I could

[sqlalchemy] Re: ordering_list performance

2008-09-22 Thread jean-philippe dutreve
What I've done is something like this: account_entries = self.entries[:] for entry in new_entries: insort_right(account_entries, entry) for i, entry in enumerate(account_entries): entry.position = i self.entries = account_entries Don't

[sqlalchemy] Re: ordering_list performance

2008-09-22 Thread jason kirtland
A warning: that depends on a bug in the C version of bisect. When given a list subclass, it mistakenly ignores the subclass method implementations. The below will break, if and when that's fixed to match the pure Python implementation in the standard lib. Calling

[sqlalchemy] Re: ordering_list performance

2008-09-22 Thread jason kirtland
Ah, looking more closely i see you're replacing self.entries with a list, not insorting into a SA list collection- that's totally ok. It might squeeze a little more speed out to do: updated_entries = list(self.entries) + new_entries base = len(self.entries) for idx, entry in