Hello, sorry for responding late, unfortunately I don't always have time...
> At any rate, in order to avoid messes in the future, do not try to merge > things from trunk into branches (unless absolutely necessary, e.g. you need a > feature in trunk). The normal work-flow is merging from branches into trunk, > and not the contrary. OK, I'll do that in the future > Since 2.2 beta 3 is already out, I guess I'm a bit > late for 2.2, but for the next release I guess it's fine. Yeah, it is a bit late, and in addition, there are some tests that do not work correctly: Hmm. OK, I'll look into that. > > - implemented a class "reference" as a new type for > > numpy arrays, which represents HDF5 references. > > I've had a look at it. There a couple of things that I don't like specially: > > - When dereferrencing, you need to pass the `file` argument to `deref()` > method. IMO, this is non-natural. Perhaps it would be possible to add a new > attribute in the `reference` class (and perhaps new `__getattr__()` and > `__setattr__()` special methods for keeping the file info? Well, thats not as easy as it sounds. In the beginning, I tried exactly that. The problem is, that there is just no space whatsoever to store this additional information. The numpy array contains exactly the reference, and numpy, knowing the type of the array, calls a constructor of the class "reference" to make an object of that type. The only information passed to this constructor is the array, and where the data is stored. This constructor thus does not know which file this reference belongs to. I had several ideas to store this information elsewhere. One could store it in the array object. Unfortunately, numpy has no space whatsoever in its structures to do so (actually, numpy 1.4 adds a new field to the array class that might be used for it. This is what the famous ABI incompatiblity was about.). Another option would be to make a new array class that inherits from numpy arrays, and contains a new field. This possibility unfortunately would mean that we have to make all parts of pytables aware of this new class, as well as all users. I don't consider that cool. A third option would have been to introduce different numpy types, one for each open file. That would mean that we need many typecodes, and do a lot of magic and abuse of numpy API. I think this is a particularly bad idea, since every change in numpy would likely lead to incompatiblities, making maintenance a nightmare. So, I opted for the admittedly unnatural way of passing the file as a parameter to the dereferencing method. Once documented, everyone knows how to deal with it, without the downsides of the above mentioned problems. I also think that references will always stay a rather rarely used feature, so I think we should go with the simplest option, making future maintenance more simple. > - You have chosen the 'r' typecode for the class. But what would happen if > the NumPy developers use 'r' in the future? I think I've already expressed my > worries about this before, but perhaps it is not as dangerous as I think? I think there is a very simple solution to this problem: Tell the guys over at numpy that we're going to use that letter, and ask them to reserve the letter for us. I don't think they get that kind of questions very often (given that the numpy code regarding new typecodes was buggy to the point that it was unusable I wouldn't be too astonished that we are the first ones requesting that at all), and so they won't have to much a problem following us. > > - attributes which are a list of strings are stored and >> loaded as variable-length strings > > That's nice, but your implementation seems to interact badly with existing > functionality (see tests failures above). I'll look into that. > The excerpt about the ABI incompatibility among NumPy 1.3 and 1.4 no longer > applies as NumPy crew have decided to declare 1.4 as invalid and released > 1.4.1 which is ABI compatible with 1.x series. So you may want to remove the > note about this. Oh, didn't see that yet, great! That made me lots of headaches... Yep, I'll change that note. Greetings Martin ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Pytables-users mailing list Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users
