> > What are the pro's and con's of making:
> > type(array('f')) == <type 'array-f'>
> > type(array('l')) == <type 'array-l'>
> > ... etc.
> This would be awkward, since these types all share the same
> implementation. Especially since I am hoping to generalize the array
> type to support arrays of arbitrary structures. It is no coincidence
> that the format string uses the same letters as the 'struct' module.
Except that struct uses 'h','i','l'
and array uses 'h' and 'l' but not 'i'.
But, yes - a good idea.
> Note that 'type', despite its name, is a low-level implementation-
> related property of an object. You really want to talk about an
> object's 'signature', which is a list of supported operations
> augmented with any restrictions that apply. Unfortunately this is not
> accessible to a program -- Python as a language is currently not
> powerful to express such signatures in a useful manner. Although
> Python doesn't support it in its syntax, my the model for type
> compatibility is the following: a piece of code (e.g. a module, class,
> or function) publishes the requirements on the data types passed into
> it in the form of signatures. It is then an error to supply an object
> whose signature isn't compatible with the required signature. Maybe
> someday we can experiment with adding a form of signatures and
> checking them at compile time (or at least at function entry time).
Thanks - that is a very clear explaination of a reasonable distinction.
And actually, I had started that post before I noticed that there
was an array( ).typecode - which will probably handle the problem
80% of the time.
What _would_ typecode of an array of struct return ? the entire struct
I would like to/from network byte order, But what format character
should we use ? The traditional unix ntohs/htons/ntohl/htonl are
really a sort of misnomer - they refer to translating a host
(long|short) to/from a network (long|short) where the host size is
compiler and host variable, but a *network* long and short are assumed
to be 32 and 16 bits respectively. i.e. they aren't really longs and
shorts on the network end - they are octet strings of length 4 and 2.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics