[Python-Dev] Array Enhancements

[Tim Peters]

Sounds like a PEP to me.

Very breifly:

> *** Changing the 'l' and 'L' typecodes to use LONG_LONG.

Please follow the lead of the struct module, which now uses 'q' and 'Q' for
8-byte ints.

> ...
> *** I'd really like it if the array module gave a "hard commitment" to
> the sizes of the elements instead of just sayings "at least n bytes".

It cannot, unless you abandon the notion that it stores native C types.
Even C99 refused to guarantee any "exactly n bytes" types, beyond the
trivial sizeof(char)==1 (which is definitional in C:  if you need to store a
char in 128 bits, that's "one byte" to C).

> ...
> *** I really need complex types. And more than the functionality
> provided by Numeric/Numarray, I need complex integer types.

This will meet resistance, as it's a pile of code of no conceivable use to
the vast majority of Python users.  That is, "code bloat".  Instead the
array type should be subclassable, and extreme special-purpose hair like
"complex integers" should be supplied by extension modules.

> ...
> *** The ability to construct an array object from an existing C
> pointer.  We get our memory in all kinds of ways (valloc for page
> aligned DMA transfers, shmem etc...), and it would be nice not to copy
> in and copy out in some cases.

Exploit the buffer interface (but write a PEP so there's a single place to
record all this stuff -- I'm not getting sucked into a massive one-shot
thread about this <wink>).

> ...
> Well if someone authoritative tells me that all of the above is a great
> idea,

At least some of it is at least a good idea <wink>.

> I'll start working on a patch and scratch my plans to create a
> "not in house" xarray module.

Please write a PEP as the first step:  a design document will be invaluable
before this is done.  I suggest thinking harder about an extensible design
than about piling all conceivable features into it at the start.