On 7/22/05, Matt Wilson <msw@xxxxxxxxx> wrote: > Generally: > > 1) initpylibparted() should raise an exception if initialization > cannot be performed (due to /proc/ not being mounted or > otherwise). Currently you'll just get an error printed and types > that are not safe to use. Ok. > 2) there are very linux-specific things in plp_probeAllDevices(). > This might not be good if you want this to be used on other > platforms. In parted we tried to keep the OS-specific stuff > isolated. I can isolate OS-specific stuff in pylibparted as well. Do you see any problems with that? > The libparted API was fairly well documented. It should be easy to > use the API documentation and get started with pyparted quickly. It > seems that a lot of pylibparted and pyparted are much the same, but > pylibparted just adds methods to access data whereas pyparted uses > attributes. Hmm.. I don't think they are much the same. Right now I see the following differences between pyparted and pylibparted: - pylibparted has a cleaner way of creating objects - pylibparted uses methods to access objects' data - pylibparted has more of libparted's functions implemented - pylibparted has some functions in different objects than the libparted API says (why? because I thought it was better for actually doing OO programming with pylibparted) - pyparted doesn't have a way to probe all devices (you have to use a static method of PedDevice to actually create a PedDevice object for your device!) - with pylibparted you don't iterate through lists with a *_next_* method, because pylibparted returns a list where a list should be returned - pylibparted isn't as stable as pyparted and there are some objects (classes) that need to be implemented IMHO, although Andrew put a nice effort into making libparted as OO as possible, there are some points where the implementation of the python bindings have to be different than the C implementation. Best, -- Ulisses PS: I thought pylibparted was the second python binding for parted, but I guess I was wrong.. :-)
