Re: Byte arrays and DLLs

That worked.  Many thanks Eryk. Rob On 30/06/2022 23:45, Eryk Sun wrote: On 6/30/22, Rob Cliffe via Python-list wrote: AKAIK it is not possible to give ctypes a bytearray object and persuade it to give you a pointer to the actual array data, suitable for passing to a DLL. You're overlooking

Re: Byte arrays and DLLs

Il giorno venerdì 1 luglio 2022 alle 00:46:13 UTC+2 ery...@gmail.com ha scritto: > On 6/30/22, Rob Cliffe via Python-list wrote: > > > > AKAIK it is not possible to give ctypes a bytearray object and persuade > > it to give you a pointer to the actual array data, suitable for passing > > to a

Re: Byte arrays and DLLs

On 6/30/22, Rob Cliffe via Python-list wrote: > > AKAIK it is not possible to give ctypes a bytearray object and persuade > it to give you a pointer to the actual array data, suitable for passing > to a DLL. You're overlooking the from_buffer() method. For example: >>> ba = bytearray(10)

Byte arrays and DLLs

I have an application in which I wanted a fixed-length "array of bytes" (that's intended as an informal term) where I could read and write individual bytes and slices, and also pass the array to a DLL (one I wrote in C) which expects an "unsigned char *" parameter. I am using ctypes to talk to

[issue217686] IDLE doesn't display long arrays well

Change by admin : -- github: None -> 33395 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue217686] IDLE doesn't display long arrays well

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Gregory P. Smith added the comment: off the top of my head that might actually work as I _think_ "empty" things are required to consume an unused byte of size no matter what meaning sizeof shouldn't change? Some testing and standards perusing for C99 is in order to confirm that though.

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

STINNER Victor added the comment: #ifdef __cplusplus char array[1]; #else char array[]; #endif Does it change the size of the structure between C and C++, sizeof(PyBytesObject)? Also, does the size of the struture matter? :-) I guess that the impart part is the ABI: offset of the

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Antoine Pitrou added the comment: How about: #ifdef __cplusplus char array[1]; #else char array[]; #endif ? -- ___ Python tracker ___

[issue38579] 'u' formatted arrays mostly prevent appends of 4 byte characters

Irit Katriel added the comment: Can you include a code snippet to demonstrate the problem? -- nosy: +iritkatriel ___ Python tracker ___

[issue45752] copy module doc wrongly says it doesn't copy arrays

Change by Andrew Svetlov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue45752] copy module doc wrongly says it doesn't copy arrays

miss-islington added the comment: New changeset 9f9a3028e3bb923e726789ab3ea5ce298b596bc6 by Miss Islington (bot) in branch '3.9': bpo-45752: Remove "array" from list of things that cannot be copied in `copy` module docstring (GH-29555)

[issue45752] copy module doc wrongly says it doesn't copy arrays

miss-islington added the comment: New changeset 55d24edaadba4ee90f464d88b44075649788f128 by Miss Islington (bot) in branch '3.10': bpo-45752: Remove "array" from list of things that cannot be copied in `copy` module docstring (GH-29555)

[issue45752] copy module doc wrongly says it doesn't copy arrays

Change by miss-islington : -- pull_requests: +27806 pull_request: https://github.com/python/cpython/pull/29558 ___ Python tracker ___

[issue45752] copy module doc wrongly says it doesn't copy arrays

Change by miss-islington : -- pull_requests: +27805 pull_request: https://github.com/python/cpython/pull/29557 ___ Python tracker ___

[issue45752] copy module doc wrongly says it doesn't copy arrays

miss-islington added the comment: New changeset c2c4fdf5ea6e9cba4ef469d08a52abb9cfa756a5 by Alex Waygood in branch 'main': bpo-45752: Remove "array" from list of things that cannot be copied in `copy` module docstring (GH-29555)

[issue45752] copy module doc wrongly says it doesn't copy arrays

miss-islington added the comment: New changeset 2081f9fe75a3a990394fbccd0c1c91c229c6289e by M. Mostafa Farzan in branch '3.10': [3.10] bpo-45752: Fix no-support examples in 'copy' docs (GH-29548) (GH-29556) https://github.com/python/cpython/commit/2081f9fe75a3a990394fbccd0c1c91c229c6289e

[issue45752] copy module doc wrongly says it doesn't copy arrays

Change by Mohammad Mostafa Farzan : -- pull_requests: +27804 pull_request: https://github.com/python/cpython/pull/29556 ___ Python tracker ___

[issue45752] copy module doc wrongly says it doesn't copy arrays

Change by Alex Waygood : -- nosy: +AlexWaygood nosy_count: 7.0 -> 8.0 pull_requests: +27803 pull_request: https://github.com/python/cpython/pull/29555 ___ Python tracker ___

[issue45752] copy module doc wrongly says it doesn't copy arrays

miss-islington added the comment: New changeset 6073920fcdb5a36d20a6a7c6ee204f74f00e1cb4 by Miss Islington (bot) in branch '3.9': bpo-45752: Fix no-support examples in 'copy' docs (GH-29548) https://github.com/python/cpython/commit/6073920fcdb5a36d20a6a7c6ee204f74f00e1cb4 --

[issue45752] copy module doc wrongly says it doesn't copy arrays

Change by miss-islington : -- nosy: +miss-islington nosy_count: 6.0 -> 7.0 pull_requests: +27802 pull_request: https://github.com/python/cpython/pull/29554 ___ Python tracker

[issue45752] copy module doc wrongly says it doesn't copy arrays

Andrew Svetlov added the comment: New changeset b7360ae395e9e633d384d16064c5dc04a9841e19 by M. Mostafa Farzan in branch 'main': bpo-45752: Fix no-support examples in 'copy' docs (GH-29548) https://github.com/python/cpython/commit/b7360ae395e9e633d384d16064c5dc04a9841e19 -- nosy:

[issue45752] copy module doc wrongly says it doesn't copy arrays

Stefan Pochmann added the comment: Just saw that it's in copy.py's docstring as well: "This version does not copy types like module, class, function, method, nor stack trace, stack frame, nor file, socket, window, nor array, nor any similar types."

[issue45752] copy module doc wrongly says it doesn't copy arrays

Change by Mohammad Mostafa Farzan : -- keywords: +patch nosy: +m2_farzan nosy_count: 4.0 -> 5.0 pull_requests: +27797 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29548 ___ Python tracker

[issue45752] copy module doc wrongly says it doesn't copy arrays

Terry J. Reedy added the comment: Should we just remove ' array,' from things that cannot be copied, or does this need more discussion? -- keywords: +easy, newcomer friendly nosy: +lukasz.langa, terry.reedy versions: -Python 3.6, Python 3.7, Python 3.8

[issue45752] copy module doc wrongly says it doesn't copy arrays

New submission from Stefan Pochmann : The doc https://docs.python.org/3/library/copy.html says: "This module does not copy types like module, method, stack trace, stack frame, file, socket, window, array, or any similar types." But it does copy arrays just fine: import c

[issue31155] Encode set, frozenset, bytearray, and iterators as json arrays

Change by sedrubal : -- nosy: +sedrubal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Laurent Gautier added the comment: Bump. I am still stumbling on that issue. I have a workaround by importing numpy but that's a rather large dependency for that one little thing. I see that the related issue https://bugs.python.org/issue35845 opened later has later discussion entries.

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Change by Gregory P. Smith : -- versions: +Python 3.11 -Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list

Re: ValueError: arrays must all be same length

gt; On Sun, Oct 4, 2020 at 8:39 AM Tim Williams wrote: >> >> > >> > >> > On Fri, Oct 2, 2020 at 11:00 AM Shaozhong SHI >> > wrote: >> > >> >> Hello, >> >> >> >> I got a json response from an API and tried t

Re: ValueError: arrays must all be same length

API and tried to use pandas to put data > into > >> a dataframe. > >> > >> However, I kept getting this ValueError: arrays must all be same length. > >> > >> Can anyone help? > >> > >> The following is the json text. Regards, Shao &

Re: ValueError: arrays must all be same length

On Sun, Oct 4, 2020 at 8:39 AM Tim Williams wrote: > > > On Fri, Oct 2, 2020 at 11:00 AM Shaozhong SHI > wrote: > >> Hello, >> >> I got a json response from an API and tried to use pandas to put data into >> a dataframe. >> >> However, I ke

Re: ValueError: arrays must all be same length

On Fri, Oct 2, 2020 at 11:00 AM Shaozhong SHI wrote: > Hello, > > I got a json response from an API and tried to use pandas to put data into > a dataframe. > > However, I kept getting this ValueError: arrays must all be same length. > > Can anyone help? > >

Re: ValueError: arrays must all be same length

Am 02.10.20 um 14:34 schrieb Shaozhong SHI: Hello, I got a json response from an API and tried to use pandas to put data into a dataframe. However, I kept getting this ValueError: arrays must all be same length. Can anyone help? The following is the json text. What do you expect

Re: ValueError: arrays must all be same length

On Fri, 2 Oct 2020 13:34:46 +0100, Shaozhong SHI wrote: > Hello, > > I got a json response from an API and tried to use pandas to put data into > a dataframe. > > However, I kept getting this ValueError: arrays must all be same length. > > Can anyone help? > >

ValueError: arrays must all be same length

Hello, I got a json response from an API and tried to use pandas to put data into a dataframe. However, I kept getting this ValueError: arrays must all be same length. Can anyone help? The following is the json text. Regards, Shao { "locationId": "1-1004508435"

[issue5141] C API for appending to arrays

Change by Jeffrey Kintscher : -- nosy: +Jeffrey.Kintscher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5141] C API for appending to arrays

Change by STINNER Victor : -- components: +C API ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

Appending to and removing from numpy arrays

Hi, is it possible to append data to or remove data from numpy arrays like Python lists? I have some code where I currently use lists and often do things like a.append(elem) a += b del a[:-n] I am thinking of changing to numpy arrays but it seems I cannot modify numpy arrays like

[issue40433] Equality operations between lists and arrays

Raymond Hettinger added the comment: I concur with Terry that this would need to be taken to python-ideas. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker

[issue40433] Equality operations between lists and arrays

Terry J. Reedy added the comment: This is not clearly a good idea. Lists and tuples with same contents do not compare equal, although set and frozenset do. I suggest that you post this idea to python-ideas list. -- nosy: +rhettinger, terry.reedy versions: -Python 3.5, Python 3.6,

[issue40433] Equality operations between lists and arrays

New submission from Ahmed Amr : Hi, I was thinking if we could add equality between array and list to work out of the box on the supported datatypes by arrays. Currently, comparing a list and an array with the same contents returns False. Also, creating an array of floats from a listA

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Antoine Pitrou added the comment: Another possibility yet would be: typedef struct { PyObject_VAR_HEAD Py_hash_t ob_shash; char ob_sval; } PyBytesObject; #define PyBytes_AS_STRING(op) (assert(PyBytes_Check(op)), \ &(((PyBytesObject

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Gregory P. Smith added the comment: PyBytesObject could become a struct that contains a single opaque internal struct. there is some code out there that references PyBytesObjects internals by field name but my searches across a broad swath of code so far seem to suggest that is so rare

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Gregory P. Smith added the comment: agreed, being opaque seems ideal. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

STINNER Victor added the comment: For me, the most sane option is to make structures opaque in the C API, and then flexible array members. I did something similar for atomic types. First, we got tons of build isssues with various C compilers and then with C++ compilers. I moved the header

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Gregory P. Smith added the comment: updates: - extern "C" is indeed really only about linking so it has no bearing. What I'm hearing from talking to our C++ compiler team is unfortunately sad: The C++ standard does not support flexible array member syntax on purpose because it leads to

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Pablo Galindo Salgado added the comment: > How is it an undefined C behavior? It works well in practice, no? Famous last words ;) -- nosy: +pablogsal ___ Python tracker ___

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Serhiy Storchaka added the comment: AFAIK extern "C" only affects mangling of function names. Because of overloading in C++ you can have several functions with the same name, and to distinguish "int abs(int)" from "float abs(float)" the C++ compiler mangles function names, that makes them

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

STINNER Victor added the comment: > Undefined C behavior going beyond end of struct via a [1] arrays. How is it an undefined C behavior? It works well in practice, no? -- ___ Python tracker <https://bugs.python.org/issu

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

STINNER Victor added the comment: Modules/hashtable.c and Modules/hashtable.h use a different approach. The variable size data is *not* part of the structure: typedef struct { /* used by _Py_hashtable_t.buckets to link entries */ _Py_slist_item_t _Py_slist_item; Py_uhash_t

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

STINNER Victor added the comment: The following C++ code fails to build: --- #ifdef __cplusplus # include #else # include #endif #ifdef __cplusplus extern "C" { #endif typedef struct { int x; int y; char array[]; } mystruct_t; #ifdef __cplusplus } #endif int main() {

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Gregory P. Smith added the comment: Isn't the only actual way for a C .h file to be compatible with C++ via extern "C" { } which all of our non-meta include files appear to have already? -- ___ Python tracker

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Serhiy Storchaka added the comment: I concur with Sam that we should keep compatibility with C++ in header files. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Change by Gregory P. Smith : -- title: Undefined C behavior going beyond end of struct via a char[1]. -> Undefined C behavior going beyond end of struct via a [1] arrays. ___ Python tracker <https://bugs.python.org/issu

[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.

Change by Gregory P. Smith : -- stage: patch review -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue39494] Extra null terminators in keyword arrays in sqlite module

Change by Berker Peksag : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: resource usage -> ___ Python tracker ___

[issue39494] Extra null terminators in keyword arrays in sqlite module

Berker Peksag added the comment: New changeset 188bb5b1e868eecf2342195dc45caa332ac3b6c7 by Alex Henrie in branch 'master': bpo-39494: Remove extra null terminators from kwlist vars (GH-18267) https://github.com/python/cpython/commit/188bb5b1e868eecf2342195dc45caa332ac3b6c7 -- nosy:

[issue39494] Extra null terminators in keyword arrays in sqlite module

Change by Alex Henrie : -- keywords: +patch pull_requests: +17644 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18267 ___ Python tracker ___

[issue39494] Extra null terminators in keyword arrays in sqlite module

es/_sqlite/module.c has two additional kwlist variables with the same problem. -- components: Library (Lib) messages: 361001 nosy: alex.henrie priority: normal severity: normal status: open title: Extra null terminators in keyword arrays in sqlite module type: resource usage versions:

[issue38579] 'u' formatted arrays mostly prevent appends of 4 byte characters

e kind. -- components: Library (Lib) messages: 355319 nosy: bup priority: normal severity: normal status: open title: 'u' formatted arrays mostly prevent appends of 4 byte characters type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Laurent Gautier added the comment: Bump. Is there anything I could do to move this forward (as in write and submit a patch for review) ? -- ___ Python tracker ___

[issue23933] Struct module should accept arrays

Change by Kyle Stanley : -- nosy: +mark.dickinson, meador.inge ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue23933] Struct module should accept arrays

Change by Joannah Nanjekye : -- title: Struct module should acept arrays -> Struct module should accept arrays ___ Python tracker <https://bugs.python.org/issu

How to create a boolean mask for the data arrays with uint16, int8 type?

Hi, How can I create a boolean mask for the data arrays with integer type? I want to create a 'useSample' boolean array for masking or discarding the unwanted data from the array. [nr,nc] = np.shape(ftype) # useSamples = np.full((nr,nc), True, dtype=bool) I want to transform the following

[issue31155] Encode set, frozenset, bytearray, and iterators as json arrays

Inada Naoki added the comment: I concur with Raymond. If you really need this feature, please discuss on python-dev ML. -- nosy: +inada.naoki resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker

[issue36450] 3D Array Assignment to all 2D sub-arrays

Eric Snow added the comment: In Python, multiplication on a list does not make copies of the values in the original list. So what you have done is equivalent to the following: a = [0, 0] b = [a, a] M = [b, b] Hence: >>> M[0] is M[1] True >>> M[0][0] is M[0][1] True >>>

[issue36450] 3D Array Assignment to all 2D sub-arrays

Change by John Bachman : -- versions: +Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36450] 3D Array Assignment to all 2D sub-arrays

assign to any list inside the 3D matrix, all lists in the array are changed, 2D Matrix works but 3D modifies every 2D matrix. -- components: Interpreter Core messages: 338963 nosy: John Bachman priority: normal severity: normal status: open title: 3D Array Assignment to all 2D sub-arrays

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Change by Stefan Krah : -- assignee: -> skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Laurent Gautier added the comment: > General support for strides in cast(), i.e. a zero-copy view for > non-contiguous arrays does not seem possible because buf.ptr is > moved around. Even NumPy does not support that: I'd be happy enough with zero-copy `cast()` of f-continguous arr

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Stefan Krah added the comment: It seems reasonable to support f-contiguous for cast() and tobytes(). For tobytes() it's implemented in the issue that Antoine linked to. General support for strides in cast(), i.e. a zero-copy view for non-contiguous arrays does not seem possible because

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Nick Coghlan added the comment: +1 for Antoine's comment - while our approach with memoryview has generally been "If you're doing serious work with n-dimensional data, you still need NumPy (or an equivalent)", we've also been open to borrowing more NumPy behaviours for memoryview as

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Antoine Pitrou added the comment: I think feature creep is ok if it stems from user needs. Slighty related, but simpler, is https://bugs.python.org/issue35845 -- ___ Python tracker

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Stefan Krah added the comment: CC Antoine and Nick. I think we can do it, but we'd need cast(shape=[2,3], order='F') to allow casting back. The only practical objections are feature creep. To preserve symmetry with tobytes(), we'd need to add tobytes('F') (and tobytes('A')). --

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

mattip added the comment: > the original decision to exclude non 'C' views was deliberate Seems this is reflected in the code: ``` a = np.array([[0, 1, 2], [3, 4, 5]]) mv = memoryview(a.T) mv.f_contiguous # True mv.cast('i', (3, 2)) # TypeError: memoryview: casts are restricted to

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

, but this is an incomplete workaround . If the rationale was to follow what `tobytes` is doing, this delegates the justification for excluding non 'C' views it. Then I do not understand the rationale behind `memoryview.tobytes`'s exclusive relationshop to C-contiguous arrays. A memmoryview is a window

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Stefan Krah added the comment: memoryview.cast() was originally meant to be a faster version of tobytes(), which always converts to C-contiguous. The 'shape' keyword was added because it is odd if you can cast from ND-C to 1D-Bytes but not back. I'm not sure if we should introduce that

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Laurent Gautier added the comment: Bump. What are the next steps here ? -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue16865] ctypes arrays >=2GB in length causes exception

Serhiy Storchaka added the comment: This issue is specific to system with 32-bit long but 64-bit size_t. Yes, seems the only supported impacted system is Windows. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___

[issue16865] ctypes arrays >=2GB in length causes exception

STINNER Victor added the comment: > The environment is Windows 8 Pro 64-bit running Python 64-bit in the > WinPython distribution. This issue is specific to system with 32-bit long but 64-bit void* I guess? So only Windows is impacted? -- nosy: +vstinner

[issue16865] ctypes arrays >=2GB in length causes exception

Serhiy Storchaka added the comment: New changeset 93d7918f77278f973a4a106c1d01ad2d9805816d by Serhiy Storchaka in branch '2.7': [2.7] bpo-16865: Support arrays >=2GB in ctypes. (GH-3006). (GH-7441) https://github.com/python/cpython/commit/93d7918f77278f973a4a106c1d01ad2d98058

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Laurent Gautier added the comment: Wouldn't a contiguity argument ('C' or 'F') be simpler ? (Independently, an argument strides is likely also missing from "cast"). Do you know what are the next possible steps here ? Bring this to the python-dev list ? Submit a patch ? --

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

mattip added the comment: Sorry, I meant a "strides" keyword. "shape" is already a valid keyword -- ___ Python tracker ___ ___

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Laurent Gautier added the comment: @mattip : do you mean that it can currently be achieved by calling `cast` with a specific shape parameter ? If the case, how so ? -- ___ Python tracker

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

mattip added the comment: This could be done via a `shape` kwarg to `cast` -- nosy: +mattip ___ Python tracker ___ ___

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Change by Stefan Krah : -- nosy: +skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

New submission from Laurent Gautier : The buffer protocol is accounting for the row-major or column-major arrays, and that information is shown in the attributes, `c_contiguous` and `f_contiguous` respectively, of a memoryview object. Using the method `cast` allows one to specify a shape

[issue16865] ctypes arrays >=2GB in length causes exception

Change by Serhiy Storchaka : -- pull_requests: +7068 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33636] Unexpected behavior with * and arrays

Steven D'Aprano added the comment: Nathan, the bug tracker is not the place to debate Python behaviour. For the purposes of the bug tracker, all we need say is that it is documented behaviour and not a bug. If you want to change that behaviour, there is a process

[issue33636] Unexpected behavior with * and arrays

R. David Murray added the comment: I wrote up a response before Mark closed the issue, so despite his excellent no discussion suggestion I'm going to post it for the edification of anyone reading the issue later rather than waste the work :) Nathan: this is *long*

[issue33636] Unexpected behavior with * and arrays

Mark Dickinson added the comment: @nanthil: If you want to discuss the reasons behind this design decision further, I'd suggest asking on one of the mailing lists, e.g. https://mail.python.org/mailman/listinfo/python-list This is not the right forum for this discussion.

[issue33636] Unexpected behavior with * and arrays

nathan rogers added the comment: [[], [], [], [], []] How is it expected behavior in python, that when I update position 0, it decides to update positions 1-infinity as well? That is nonsense, and there is not a use case for this behavior. If you have already

[issue33636] Unexpected behavior with * and arrays

nathan rogers added the comment: Can anyone give me a legitimate answer as to why this would be expected behavior? When at any point would you ever need that? If the list is local, you already have the thing. If it isn't local, you can pass it to a function by

[issue33636] Unexpected behavior with * and arrays

Steven D'Aprano added the comment: This is not a bug, it is the documented behaviour: the * operator does not copy the lists, it duplicates references to the same list. There's even a FAQ for it:

[issue33636] Unexpected behavior with * and arrays

tion 0 to be appended. The sensible behavior, from my view, would be to make n unique values, not n duplicates. -- messages: 317572 nosy: nanthil priority: normal severity: normal status: open title: Unexpected behavior with * and arrays type: behavior versions: Pyth

[issue33593] Support heapq on typed arrays?

Raymond Hettinger added the comment: As noted by Serhiy, the interaction with the Array type would incur significant overhead. Your fastest approach will be to follow his suggest to first convert to a list and then perform heap manipulations. Marking this as

[issue33593] Support heapq on typed arrays?

Serhiy Storchaka added the comment: Workaround: alist = list(a) heapq.heapify(alist) a[:] = alist And it should be not much slower than using heapq.heapify() directly if it could support general sequences. Using it with array.array would add significant overhead

[issue33593] Support heapq on typed arrays?

Diego Argueta added the comment: However I do see your point about the speed. -- ___ Python tracker ___

[issue33593] Support heapq on typed arrays?

Diego Argueta <diego.argu...@gmail.com> added the comment: I was referring to the C arrays in the Python standard library: https://docs.python.org/3/library/array.html -- ___ Python tracker <rep...@bugs.python.org> <https://

  1   2   3   4   5   6   7   8   9   >