Re: [Zope-dev] [Checkins] SVN: zc.dict/branches/tlotze-blist/src/zc/dict/ordered.txt added a test to ensure the order is stored in a BList
Hi Thomas. Very cool that you are working on zc.dict + zc.blist. The updateOrder API is a sucky API for blists, as I'm sure you've realized. :-) FWIW, I seem to recall that Plone has a reasonable-to-nice API for changing order in containers, and the API would be able to take much better advantage of using blists for the ordering. I was intending to study that when I designed the new API (even if the Plone API were perfect, I would be wary of copying it because of GPL vs. ZPL, but maybe you could get them to relicense if you wanted it). You'd probably still want to keep updateOrder around, I guess, since that's the Zope 3 interface, but I would have documentation discouraging it. Gary
Gary Poster <gary.poster@gmail.com> schrieb:
Hi Thomas. Very cool that you are working on zc.dict + zc.blist.
Better than letting that branch get old ;o)
The updateOrder API is a sucky API for blists, as I'm sure you've realized. :-)
It is sucky even when used with a PersistentList; it's just that the disadvantages of its implementation are more obvious in the context of BLists.
FWIW, I seem to recall that Plone has a reasonable-to-nice API for changing order in containers, and the API would be able to take much better advantage of using blists for the ordering. I was intending to study that when I designed the new API (even if the Plone API were perfect, I would be wary of copying it because of GPL vs. ZPL, but maybe you could get them to relicense if you wanted it).
I'll take a look at that, thanks for the pointer.
You'd probably still want to keep updateOrder around, I guess, since that's the Zope 3 interface, but I would have documentation discouraging it.
Yes, and I think that we're talking about two steps here anyway. I'd like to finish and release a version that uses BLists ASAP; an additional API can always be added in a subsequent release. Viele Grüße, Thomas -- Thomas Lotze · tl@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Thomas Lotze <tl@gocept.com> schrieb:
Yes, and I think that we're talking about two steps here anyway. I'd like to finish and release a version that uses BLists ASAP;
Well, I think the switch to BLists is finished, so I'd be ready to merge it to the trunk after someone reviewed the changes. In particular, I'm not sure that wiring up and testing the database generation follows best practices. Viele Grüße, Thomas -- Thomas Lotze · tl@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Dec 23, 2008, at 2:11 PM, Thomas Lotze wrote:
Thomas Lotze <tl@gocept.com> schrieb:
Yes, and I think that we're talking about two steps here anyway. I'd like to finish and release a version that uses BLists ASAP;
Well, I think the switch to BLists is finished, so I'd be ready to merge it to the trunk after someone reviewed the changes. In particular, I'm not sure that wiring up and testing the database generation follows best practices.
OK. I'll give it a whirl sometime over the next couple of weeks, if that's soon enough for you. FWIW, I'd be strongly tempted to release *without* the generation code, and leave it up to users to switch as they desire. 1) That's particularly pertinent for library bits like this because a tree walker would have to walk over *all* attributes and __getitem__s in order to find instances of things like a blist, which will generally be hidden deep in application objects; or would have to use an iteration protocol like the one that FileStorage provides. 2) Old instances (with lists, not blists) will still work fine with the new code, and in fact should continue to work even with new apis as long as the ordered dict apis use the list apis (like slices) to manipulate the order. 3) How many people are really using the blist right now anyway in production? Generation code is hard to test in the abstract.
Gary Poster <gary.poster@gmail.com> schrieb:
OK. I'll give it a whirl sometime over the next couple of weeks, if that's soon enough for you.
Sure.
FWIW, I'd be strongly tempted to release *without* the generation code, and leave it up to users to switch as they desire.
Fine with me. I'm pretty confident of the other changes I've made, BTW, and there's not exactly a lot of them either.
1) That's particularly pertinent for library bits like this because a tree walker would have to walk over *all* attributes and __getitem__s in order to find instances of things like a blist, which will generally be hidden deep in application objects; or would have to use an iteration protocol like the one that FileStorage provides.
Right. Looking closer at the utility function I've used so far for walking the objects, I think it doesn't nearly cover all the places a dict could hide.
2) Old instances (with lists, not blists) will still work fine with the new code, and in fact should continue to work even with new apis as long as the ordered dict apis use the list apis (like slices) to manipulate the order.
They do.
3) How many people are really using the blist right now anyway in production?
No idea...
Generation code is hard to test in the abstract.
Do we actually have any best practices for that? Viele Grüße, Thomas -- Thomas Lotze · tl@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
participants (2)
-
Gary Poster -
Thomas Lotze