[Python-Dev] Replacement for array.array('u')?
steve.dower at python.org
Mon Mar 25 11:48:59 EDT 2019
On 25Mar2019 0812, Martin (gzlist) wrote:
> On Fri, 22 Mar 2019 at 16:12, Steve Dower <steve.dower at python.org> wrote:
>> On 22Mar2019 0433, Antoine Pitrou wrote:
>>> The question is: why would you use a array.array() with a Windows C API?
>> I started replying to this with a whole lot of examples, and eventually
>> convinced myself that you wouldn't (or shouldn't).
>> That said, I see value in having a type for array/struct/memoryview that
>> "is the same size as wchar_t", since that will avoid people having to
>> guess (the docs for array in particular are deliberately vague about the
>> actual size of the various types).
> This is pretty much what ctypes provides for dealing with unicode?
> Seems a fine place to have things that help with win32 api interactions.
Sure, though there are other reasons to deal with "pure" data that would
benefit from having the data type in array. I don't need to directly
refer to an existing buffer in memory, just to easily create/reinterpret
bytes (for which memoryview is often better, though it inherits its
codes from struct, which has no 'u' code, which is probably why I end up
using array instead ;) )
Also, I keep finding that every time I deploy Python these days, it's
critical to remove ctypes to reduce the attack surface area (I'm getting
it into more and more high value systems where the rules are more
strict). So I'm a big fan of treating ctypes as optional.
More information about the Python-Dev