New IOBTrees have no 'map' method
Hi, I was going to have the next version of Squishdot use the new BTrees, but it appears that the new objects don't have the same methods as the old ones. In particular, the following line from Squishdot: return map(lambda x, p=self: x.__of__(p), self.data.map(self.site_id_list(currtime))) ...fails with an attribute error on map. self.data is an IOBTree. Any ideas? cheers, Chris
Have you read the Interfaces.py file in the BTrees directory? ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: <zope-dev@zope.org> Sent: Monday, May 07, 2001 10:45 AM Subject: [Zope-dev] New IOBTrees have no 'map' method
Hi,
I was going to have the next version of Squishdot use the new BTrees, but it appears that the new objects don't have the same methods as the old ones.
In particular, the following line from Squishdot:
return map(lambda x, p=self: x.__of__(p), self.data.map(self.site_id_list(currtime)))
...fails with an attribute error on map.
self.data is an IOBTree.
Any ideas?
cheers,
Chris
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Tue, 8 May 2001, Chris Withers wrote:
Chris McDonough wrote:
Have you read the Interfaces.py file in the BTrees directory?
I have now, and to be honest, it didn't mean a lot to me :-(
Sorry, it's late here, what am I missing?
My guess, after searching for the keyword 'map' and finding an interface that calls for the implementation of __getitem__ and says this allows 'for' loops and 'map' iterations, is that you can just drop the call to the .map method and use the IOBtree directly as the argument to the map function. But in the absence of real knowledge about what the .map method of the old IOBTree does, that is just a guess. --RDM
"R. David Murray" wrote:
My guess, after searching for the keyword 'map' and finding an interface that calls for the implementation of __getitem__ and says this allows 'for' loops and 'map' iterations, is that you can just drop the call to the .map method and use the IOBtree directly as the argument to the map function. But in the absence of real knowledge about what the .map method of the old IOBTree does, that is just a guess.
Well, to give you an idea of what it did, here's the method I had to write toreplace the functionality: def data_map(self,ids): result=[] for id in ids: result.append(self.data[id].__of__(self)) return result self.data is an IOBTree. If this can be replaced wiith a simple return map(...,self.data), please let me know :-) cheers, Chris
Chris Withers wrote:
"R. David Murray" wrote:
My guess, after searching for the keyword 'map' and finding an interface that calls for the implementation of __getitem__ and says this allows 'for' loops and 'map' iterations, is that you can just drop the call to the .map method and use the IOBtree directly as the argument to the map function. But in the absence of real knowledge about what the .map method of the old IOBTree does, that is just a guess.
Well, to give you an idea of what it did, here's the method I had to write toreplace the functionality:
def data_map(self,ids): result=[] for id in ids: result.append(self.data[id].__of__(self)) return result
self.data is an IOBTree.
If this can be replaced wiith a simple return map(...,self.data), please let me know :-)
Untested... return map(lambda x, data=self.data, self=self: data[x].__of__(self), ids)
Chris Withers wrote:
Chris McDonough wrote:
Untested...
return map(lambda x, data=self.data, self=self: data[x].__of__(self), ids)
ah, I see :-)
Would that be faster than my little function?
Probably not appreciably... unless it is, of course. ;-) It depends how many things you're iterating over. Might even be slower... it'd require testing and its probably not worth it. - C
Chris McDonough wrote:
Probably not appreciably... unless it is, of course. ;-) It depends how many things you're iterating over.
self.data can often contain several thousand objects.
Might even be slower... it'd require testing and its probably not worth it.
Hehe, I'll leave it then, unless someone complains abotu Squishdot being dog slow... cheers, Chris
On Fri, 11 May 2001, Chris Withers wrote:
Probably not appreciably... unless it is, of course. ;-) It depends how many things you're iterating over.
Hehe, I'll leave it then, unless someone complains abotu Squishdot being dog slow...
If you haven't already read it, you might be interested in this article: http://www.python.org/doc/essays/list2str.html --RDM
"R. David Murray" wrote:
On Fri, 11 May 2001, Chris Withers wrote:
Probably not appreciably... unless it is, of course. ;-) It depends how many things you're iterating over.
Hehe, I'll leave it then, unless someone complains abotu Squishdot being dog slow...
If you haven't already read it, you might be interested in this article:
I stopped at poitn one of the conclusion ;-) cheers, Chris
participants (3)
-
Chris McDonough -
Chris Withers -
R. David Murray