Re: FW: [Numpy-discussion] typecodes in numarray

[Todd M. <jm...@st...>]

Francesc Alted wrote:

>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?
>  
>
I think that avoiding the charcodes would be an improvement. 
 Type-repetition tuples provide a clear well defined way to define data 
formats.   It's not so clear that it eliminates the requirement for 
on-going Numeric compatability,  but it might.

>  
>
>>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.
>  
>
Well,  I think there's truth to the danger of seperating names from data 
declarations,  but it is easy to map keys(), values() to the seperate 
pieces in a different layer if necessary.  

>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!. 
>
For a few seconds there,  I thought I was on a roll!  

>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.
>  
>
In truth,   numarray-0.4 and up already require Python-2.2 and up.

>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?.
>
What I was trying to see is that chararray types are not as well 
designed as the numarray types,  nor are they reflected in the C-API.

>  
>