[Python-Dev] Array Enhancements (original) (raw)

Tim Peters tim.one@comcast.net
Fri, 05 Apr 2002 15:58:12 -0500

Sounds like a PEP to me.

Very breifly:

*** Changing the 'l' and 'L' typecodes to use LONGLONG.

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 ).

... 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 .

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.