On Fri, Feb 21, 2020 at 02:42:16PM +0200, Serhiy Storchaka wrote:
> 21.02.20 10:36, Steven D'Aprano пише:
> >On my machine, at least, constructing a bytes object first followed by
> >an array is significantly faster than the alternative:
> >
> >[steve@ando cpython]$ ./python -m timeit -s "from
On Fri, Feb 21, 2020 at 12:43 AM Steven D'Aprano
wrote:
> On Thu, Feb 20, 2020 at 02:19:13PM -0800, Stephan Hoyer wrote:
>
> > > > Strong +1 for an array.zeros() constructor, and/or a lower level
> > > array.empty() which doesn't pre-fill values.
> > >
> > > So it'd be a shorthand for something
21.02.20 10:36, Steven D'Aprano пише:
On my machine, at least, constructing a bytes object first followed by
an array is significantly faster than the alternative:
[steve@ando cpython]$ ./python -m timeit -s "from array import array"
"array('i', bytes(50))"
100 loops, best of 5: 1.71 msec
On Feb 21, 2020, at 00:46, Steven D'Aprano wrote:
>
>
> Got some actual measurements to demonstrate that initialising the array
> is a bottleneck? Especially for something as small as 64, it seems
> unlikely. If it were 64MB, that might be another story.
>
> What's wrong with
On Thu, Feb 20, 2020 at 02:19:13PM -0800, Stephan Hoyer wrote:
> > > Strong +1 for an array.zeros() constructor, and/or a lower level
> > array.empty() which doesn't pre-fill values.
> >
> > So it'd be a shorthand for something like this?
> >
> > >>> array.array("i", bytes(64))
> > array('i', [0,
On Thu, Feb 20, 2020 at 12:43 PM Steve Jorgensen wrote:
>
> > But frankly, it would be a rare case where this would be noticeable.
> > -CHB
>
> Maybe uncommon, but I don't know about rare. Let's say you want to perform
> list-wise computations, making new lists with results of operations on
>
On Thu, Feb 20, 2020 at 2:11 PM Chris Angelico wrote:
> On Fri, Feb 21, 2020 at 8:52 AM Stephan Hoyer wrote:
> >
> > On Thu, Feb 20, 2020 at 12:41 PM Steve Jorgensen
> wrote:
> >>
> >> Christopher Barker wrote:
> >> ...
> >> > > Perhaps the OP wanted the internal array size initialized, but
On Fri, Feb 21, 2020 at 8:52 AM Stephan Hoyer wrote:
>
> On Thu, Feb 20, 2020 at 12:41 PM Steve Jorgensen wrote:
>>
>> Christopher Barker wrote:
>> ...
>> > > Perhaps the OP wanted the internal array size initialized, but not used.
>> > Currently the internal array will automatically be
On Thu, Feb 20, 2020 at 12:41 PM Steve Jorgensen wrote:
> Christopher Barker wrote:
> ...
> > > Perhaps the OP wanted the internal array size initialized, but not
> used.
> > Currently the internal array will automatically be reallocated to grow as
> > needed. Which could be a performance hit if
Christopher Barker wrote:
...
> > Perhaps the OP wanted the internal array size initialized, but not used.
> Currently the internal array will automatically be reallocated to grow as
> needed. Which could be a performance hit if you know it’s going to grow
> large.
> But frankly, it would be a
On Thu, Feb 20, 2020 at 7:34 AM Serhiy Storchaka
wrote:
> 20.07.11 23:48, Sven Rahmann пише:
> > What's missing is the possiblity to specify the final size of the
> > array (number of items), especially for large arrays.
>
> array.array(typecode, [fillvalue]) * n
Perhaps the OP wanted the
20.07.11 23:48, Sven Rahmann пише:
At the moment, the array module of the standard library allows to
create arrays of different numeric types and to initialize them from
an iterable (eg, another array).
What's missing is the possiblity to specify the final size of the
array (number of items),
I discovered that same trick. It would be nice to have that specifically
indicated in the documentation until/unless a length argument is added to the
constructor.
It would be nice for the supported operators to be documented at all, actually.
I didn't realize that array.array had
13 matches
Mail list logo
