array objects from the array module have an extend method that 
only takes arrays.  The implementation would be more useful if it 
accepted arbitrary sequences (generators, lists, strings, etc).  
Similarly, the initializer currently only accepts lists and strings, 
but it should also support arbitrary sequences.

>>> from array import array
>>> array('c', iter('1234'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: array initializer must be list or string
>>> array('c').extend('1234')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only extend array with array (not "str")

Logged In: YES 
user_id=6656

I agree with your first point.  Should be easy, too.

I'm /slightly/ less enthusiastic about the latter point.  sequence-
>array conversion is sufficiently complex that I'm not sure I want 
it happening automatically.

This is the sort of report that a patch would help immensely, btw 
:-)

Logged In: YES 
user_id=80475

In Py2.4, I already made extend() take a general iterable. 
The goal was to simplify code doing repeated appends.

By calling array_extend, it should be easy to do the same
for the constructor.  The question is whether there are use
cases to warrant a further API change.  Most needs can
already be met with extend() or with array.array(code,
list(it)).  

My preference is to leave the constructor for cases with a
known sequence length.   With a single pre-allocation and
copy step, the performance is optimal.  I don't think it
would be obvious that using a general iterable would be much
slower and consume more memory than expected.  That's okay
for lists, but people use array when they are tight for
space or have other performance goals.

Logged In: YES 
user_id=99874

I'll just chime in to agree with Raymond's analysis... the
constructor doesn't need to take general iterables. One can
always construct an empty array and extend it if that's
what's needed.

Logged In: YES 
user_id=139309

One can construct an empty list and extend it too, but for some reason 
they let you make them out of arbitrary iterables.  I wonder why! :)

Logged In: YES 
user_id=6656

Interesting how intuitions differ :-)

It's just a call to PySequence_FAST, hardly an intrusive
patch (which didn't you use that for array_extend?).

The error message is wrong, btw: tuples are accepted too.

Logged In: YES 
user_id=80475

Guido, do you have an opinion on this?

If you want the constructor to accept general iterables,
that is not hard to do.

The question is whether the change is desirable.  On the
plus side, it better matches the list API.  On the minus
side, it allows array construction to invisibly slip into a
lower performance mode for both speed and space (with a list
style over allocation scheme).  I find that to be at odds
with the performance oriented use cases for the module. So,
I'm -0 on the feature request since general iterables can
already be handled explicitly with array.extend(it) or
array.array(code, list(it)).

Logged In: YES 
user_id=6380

Hm, I don't see the array module as a performance hack for
operations within Python. I see it as a storage savings hack
(occasionally) and as a way to create arrays that can be
directly manipulated by C code (mostly). Although the new
numeric module promises a much better solution for the latter.

I'd say that both the constructor and extend() should
support arbitrary iterables -- that's the Pythonic API style
these days.

Logged In: YES 
user_id=80475

Wish granted.
See Modules/arraymodule.c 2.97