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

[Francesc A. <fa...@op...>]

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,  woul=
d
> 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 ma=
ybe
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 t=
hat
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 latte=
r
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 w=
ill
> >ensure (by construction) that you are not using a non-valid python
> >identifier, which is mandatory in my current implementation. I find th=
ese
> >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)=
=2E
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 po=
int
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 v=
iew
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?.

--=20
Francesc Alted