how to duplicate array entries

Steven D'Aprano steven at REMOVE.THIS.cybersource.com.au
Mon Jan 11 09:26:05 CET 2010


On Mon, 11 Jan 2010 08:56:36 +0100, Alf P. Steinbach wrote:

> * Paul Rudin:
>> Sebastian <sebastian.langer at gmx.de> writes:
>> 
>>> I have an array  x=[1,2,3]
>> 
>> In python such an object is called a "list".
>> 
>> (In cpython it's implemented as an automatically resizable array.)
> 
> I don't think the OP's terminology needs correction.
> 
> A Python "list" is an array functionality-wise.
> 
> If one isn't observant of that fact then one ends up with O(n^2) time
> for the simplest things.

Well that's certainly not true. Some operations may be O(N**2), but 
others are not: list.append() is amortized O(N) and for individual 
appends, may be can be as fast as O(1).


> Using the term "array" accentuates and clarifies this most important
> aspect.

But Python lists are designed to behave as lists. Just because CPython 
implements them using arrays doesn't make them arrays. Other Python 
implementations might use other implementations... 

If the creator of CLPython is out there, perhaps might like to comment on 
whether he uses Lisp linked-lists for the Python list type?


> Using the misleading term "list", even if that's the type's name in
> Python, hides this most important aspect, and so is not, IMHO, a Good
> Idea except where it really matters that it's a 'list' array as opposed
> to, say, a 'tuple' array.

Or an "array" array.


>>> from array import array
>>> array
<type 'array.array'>



>>> Is there an operator which I can use to get the result
>>> [1,1,1,2,2,2,3,3,3] ?
>> 
>> There's no operator that will give you that directly - but there are
>> plenty of one-liners that will yield that list. e.g:
>> 
>>>>> list(itertools.chain(*([x]*3 for x in [1,2,3])))
>> [1, 1, 1, 2, 2, 2, 3, 3, 3]
> 
> And I think it's worth noting that, for the general case, this notation
> is also hiding a gross inefficiency, first constructing sub-arrays and
> then copying them and joining them.

I wouldn't call that a gross inefficiency -- that's a gross exaggeration 
unless count is very large, and even then, possibly not that large. Only 
one such sub-array (sub-list) exists at any time. (Unless I am grossly 
misinformed.)



> It doesn't even buy clarity.

Not if you're unused to the functional, iterator-based idioms, no.

But if you are, it does.



> And if one absolutely feels like trading some efficiency and clarity for
> some more functional-programming expression like thing (I don't
> understand why people desire that!), 

I don't understand why you assume that functional forms are necessarily 
less efficient and clear than non-functional. Which is easier to read?

>>> print sum([1,2,3])
6

versus

>>> total = 0
>>> for i in [1, 2, 3]:
...     total += i
... 
>>> print total
6


[...]
> Re the thing I don't understand: it's the same in C++, people using
> hours on figuring out how to do something very simple in an ungrokkable
> indirect and "compiled" way using template metaprogramming stuff, when
> they could just write a simple 'for' loop and be done with in, say, 3
> seconds, and much clearer too!

Amen to that brother!

It's the obsession with one-liners and the desire for a single built-in 
command to do every imaginable task.





-- 
Steven



More information about the Python-list mailing list