First, an effort to make compilation of the python wrapper feasible again. To do this, I propose we use python lists instead of compiling many different versions of classes which look more or less like python lists. eg, IMP.Particles() is equivalent to [], as is IMP.Vector3Ds(). I have experimented with this and found a few effects: - this makes compilation of the python wrappers of imp much, much faster (it is now quite pleasant to build IMP on my laptop, where as before it took hours) - overloaded functions where the only way to tell the functions apart is the type of the collection are not supported. There aren't too many such cases in IMP. This is, in most cases, simply a limitation of SWIG and so we can work around it in important cases if desired. SWIG produces a warning so we will know where it is happening. - passing value types (eg IMP.Particles()) by pointer or storing pointers to passed value types would not work on calls from python. I consider this a feature as such things are bad programming practices.
Second, there is a bit of a mess with the containers in terms of informing them about the model (since in increasing number of them need to register score states with the model). I propose that all containers need to get the model as part of their constructor. The main effect would be that the default constructors of List*Containers take a model (instead of being the default constructor). This would simplify a lot of things and make caching much easier in the containers which do not currently do it.
Comments? Objections?
On Mar 21, 2010, at 12:56 PM, Daniel Russel wrote:
> First, an effort to make compilation of the python wrapper feasible > again. To do this, I propose we use python lists instead of > compiling many different versions of classes which look more or less > like python lists. eg, IMP.Particles() is equivalent to [], as is > IMP.Vector3Ds(). I have experimented with this and found a few > effects: > - this makes compilation of the python wrappers of imp much, much > faster (it is now quite pleasant to build IMP on my laptop, where as > before it took hours) > - overloaded functions where the only way to tell the functions > apart is the type of the collection are not supported. There aren't > too many such cases in IMP. This is, in most cases, simply a > limitation of SWIG and so we can work around it in important cases > if desired. SWIG produces a warning so we will know where it is > happening. > - passing value types (eg IMP.Particles()) by pointer or storing > pointers to passed value types would not work on calls from python. > I consider this a feature as such things are bad programming > practices.
Daniel - can you please elaborate what is the meaning of this change from the c++ side ?
> > > Second, there is a bit of a mess with the containers in terms of > informing them about the model (since in increasing number of them > need to register score states with the model). I propose that all > containers need to get the model as part of their constructor. The > main effect would be that the default constructors of > List*Containers take a model (instead of being the default > constructor). This would simplify a lot of things and make caching > much easier in the containers which do not currently do it. no problems here. > > Comments? Objections? > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
On Mar 21, 2010, at 1:03 PM, Keren Lasker wrote:
> > On Mar 21, 2010, at 12:56 PM, Daniel Russel wrote: > >> First, an effort to make compilation of the python wrapper feasible again. To do this, I propose we use python lists instead of compiling many different versions of classes which look more or less like python lists. eg, IMP.Particles() is equivalent to [], as is IMP.Vector3Ds(). I have experimented with this and found a few effects: >> - this makes compilation of the python wrappers of imp much, much faster (it is now quite pleasant to build IMP on my laptop, where as before it took hours) >> - overloaded functions where the only way to tell the functions apart is the type of the collection are not supported. There aren't too many such cases in IMP. This is, in most cases, simply a limitation of SWIG and so we can work around it in important cases if desired. SWIG produces a warning so we will know where it is happening. >> - passing value types (eg IMP.Particles()) by pointer or storing pointers to passed value types would not work on calls from python. I consider this a feature as such things are bad programming practices. > > Daniel - can you please elaborate what is the meaning of this change from the c++ side ? No necessary C++ changes. It might make sense to rename some functions to get around the overloading problem though. But any important methods we would work around it on the python side.
participants (2)
-
Daniel Russel -
Keren Lasker