Guy Streeter, le Thu 20 Jan 2011 19:02:52 +0100, a écrit :
> On 01/20/2011 11:32 AM, Samuel Thibault wrote:
> >>topo = hwloc.hwloc_topology()
> >>assert obj.type == hwloc.HWLOC_OBJ_PU
> >>orig = hwloc.hwloc_bitmap.alloc()
> >Mmm, why repeating "hwloc"?
> I think removing the "hwloc_" prefix from the class names is a good idea.
> I'll do that.
> Do you think I should also do it for those constants? I thought matching
> the C constant name was better, but hwloc.OBJ_PU is less typing :)
Yes, the reasoning about function names is the same.
> Also, since they are class names, do you think I should capitalize them as
> is common for python classes? "topo = hwloc.Topology()" ?
Yes, it'll make clear these are not just functions.
> >It's nice to have rewritten the whole testsuite :) It's really useful to
> >have a very good grasp on how it looks like.
> >>hwlocset = topo.complete_cpuset.dup()
> >Mmm, so if the user forgets to use dup(), he might still be able to
> >write in a const cpuset?
> I haven't figured out a way to mark things as non-modifiable. I'm still
> researching it. Right now nothing stops you changing any bitmap.
I was wondering whether we should consider making a copy when given
a const pointer, so the user can not make mistakes. Another option
is to test for constness in all modification operations, but I guess
it'd be tedious. In any case, I guess we can't really make something
non-modifiable in the C sense (i.e. get a segfault if one writes to it),
because I guess the python interpreter is not supposed to crash :) (or
maybe you can catch that and return an exception).
> >Also, could you clearly separate functions which are not defined
> >in hwloc.h itself? In the C interface, they are in a separate e.g.
> >helpers.h file in order to express that these are really helpers only,
> >and that the user doesn't need to know them all, everything can be done
> >with the core functions from hwloc.h.
> Do you mean physically separate in the source code, or are you talking
> about providing a different way to access them? I know the source code
> could use some cleanup and more comments.
At the very least, the source code. Separating it in the pydoc
documentation would be very useful too. The way of access is not
necessarily a concern, as long as people understand the relation.
> >>alloc_membind doesn't make a lot of sense in python, since you really
> >>can't tell the python interpreter to use the space.
> >>I can't think of a way to use hwloc_set_area_membind* in python
> >They should probably take a python object itself, but since I guess the
> >python GC does what it wants with moving data... That might however
> >be useful when e.g. somebody drives C computation code from a python
> >fast-prototyping main loop.
> >>_libhwloc = ctypes.CDLL(ctypes.util.find_library('hwloc'),
> >Mmm, shouldn't this include the soname of the library? Else built
> >bindings will break on ABI changes.
> I planned to check the library version at run-time. That way I can provide
> backward compatibility.
Mmm, ok, but how will you manage ABI changes? You will need to build
your bindings several times, against the varying hwloc interfaces.