Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [hwloc-devel] python bindings
From: Samuel Thibault (samuel.thibault_at_[hidden])
Date: 2011-01-21 11:14:53


Guy Streeter, le Thu 20 Jan 2011 20:57:24 +0100, a écrit :
> I added some iterators:
> bitmap.all_set_bits
> obj.infos
> topology.objs_by_depth
> topology.objs_by_type
>
> I also made obj.children an iterator.
> I think I could do the same with siblings and cousins if that makes sense.

I think it makes sense.

> I implemented bitmap.bitmap_weight() as a method, but also bitmap.weight as
> a property.

Ah, I hadn't catched that: just like for the hwloc_ prefix, isn't
the bitmap_ prefix redundant?

I wouldn't set weight as a property, because people will tend to think
that it's a cheap operation, while it's not.

> Also bitmap.bitmap_first() and bitmap.first, etc.

ditto :)

> Instead of the bitmap isequal, or, and, xor, and not methods, I supported
> the operators ==, != |, |=, &, &=, ^. ^=, and ~.

That's just nice sugar, no problem with that :)

> A new topology instance gets init() automatically, and is destroyed
> when it goes away, so those methods are not exposed.

That's probably what we want, yes. Bernd, I believe perl should do the
same.

I'm wondering whether we should perhaps put an equivalence chart
somewhere, to make sure things are coherent between C, python, perl, and
any other future bindings.

Samuel