A Dilluns 27 Gener 2003 15:42, Todd Miller va escriure:
Yes. So one question is: if we were to add type-repetition tuples to recarray as an alternative to the current character code strings, would that be any form of improvement to recarray from your perspective?
Well, at least, charcodes can be avoided. I think it's a big win... or maybe not as big?
As I see it, recarray currently has a clean seperation between format and naming which permits the latter to be optional. Before changing that, I'd need a clear argument why. (I didn't design and generally don't even maintain recarray).
One argument is the fact that a map is very clear to the user, although that such a map can be built *after* the names and format are passed to the recarray constructor and be accessible as an atribute. However, the latter solution is worse IMO, because the user has to supply two separate pieces of information when, actually, these should be regarded as a unity. Anyway, this maybe a subjective perception.
This would not be difficult to support because, by accessing to the Small().__dict__, you get also a dictionary. In addition, the latter will ensure (by construction) that you are not using a non-valid python identifier, which is mandatory in my current implementation. I find these containers (dictionaries and classes) both elegant and convenient.
I'm not trying to be Mr. Negative here, but one thing to keep in mind
Oh dear, you are right!. In fact, I forgot that to make this to work, you need to use the metaclasses introduced in Python 2.2 (see Alex Martelli's post: http://mail.python.org/pipermail/python-list/2002-July/112007.html). I was following this recipe, but I forgot that I was using Python 2.2. So, as numarray has to work with previous python versions, there is no point to care about that.
I'm sure that's not the easiest way to capture struct layout, but I take your point. Since position matters to me, I'd prefer that capturing them was implicit. Since it doesn't to you, it seems OK for it to be explicit. Either default mode can support the other, but capturing order with tuples is free, while capturing order with a __dict__ will take some kind of extra work.
That's right. We have some different needs and priorities, and we should take the approach better suited to each other. But exchanging points of view is always a great thing.
I'm thinking the general format for this may be converting N-tuples of types and ints into N arrays of types and ints. And vice versa. It's obvious how this works with numarray types. I think the chararray types need work and need to be mapped into the same integer enumeration as the numeric types in a non-overlapping way.
I can't catch your point here. Why there should be a problem with chararrays?. -- Francesc Alted