tag:blogger.com,1999:blog-7844526396210378482.post2477382146351130409..comments2024-01-31T09:23:26.925+00:00Comments on Noel O'Blog: Pybel as a generic API for cheminformatics libraries - proof of concept using CDKNoel O'Boylehttp://www.blogger.com/profile/03288289351940689018noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-7844526396210378482.post-57514075303358156942008-03-29T04:57:00.000+00:002008-03-29T04:57:00.000+00:00Here's some of my experiences with the basic API f...Here's some of my experiences with the basic API from PyDaylight, which as you know is similar to pybel's. Although it doesn't handle file I/O.<BR/><BR/>I wrote code for one of my clients using PyDaylight. Years later they ported everything over to OEChem. I in effect reimplemented enough of PyDaylight in OEChem to make everything work. The biggest problem SMARTS portability: OEChem doesn't support "vector bindings" and changes the semantics of a few terms.<BR/><BR/>I spent several days going through the regression failures to characterize all of these differences. It's something you'll have to worry about with a "cross-platform", pybel. Code isn't that portable if it does different things on each platform.<BR/><BR/>Another client had tools that worked with OEChem but wanted to be able to demo it on machines without an OEChem license. They didn't use much of OEChem and I was able to emulate that on top of FROWNS. It was a C++ library which turned around and called a Python library. Strange, but it worked well enough.<BR/><BR/>The biggest problem there was the performance. I don't recall but I think it was about 100 times slower than OEChem.<BR/><BR/>In both those cases the drive to switch was because of licensing problems. When pybel on top of free toolkits, that's not so important.Andrew Dalkehttps://www.blogger.com/profile/17091314849699854287noreply@blogger.com