I've just implemented an efficient tuple(seq) function which converts
any sequence to a tuple... Will be in the next release (don't ask me
when :-). If you insist I could make a patch available.
> The first: the fact that tuples and strings are immutable. And I do
> believe you, that a lot of thought went into it. I can see it in the
> simplicity of the language, and it's capacity to support rather large
> programs. Python has features I wish compiled languages had.
> However, I think some things are a pain. And these things are
> related to sequence types. There are a few functions that require
> specific types, such as:
> apply(), which requires a tuple. But in constructing an argument
> list, I used the more flexible list. Now I have to convert. Why
> can't apply take a list also?
> hash keys for dictionaries can be tuples, but not lists. Again: I
> constructed my key as a list, because it was most suitable, and
> now I have to convert.
There are many places in Python where a built-in function requires a
tuple (or a list) where an arbitrary sequence would make sense. This
is an oversight, which will be remedied one time. apply() is one
(although a tuple is needed by the implementation).
On the other hand, hash() won't work on lists for a reason -- if L
were a list object used as as dictionary key, L.append(...) would
change its hash value and break an invariant of the dictionary
implementation. So therefore you need the new tuple() built-in.
> Yesterday, I needed to duplicate a dictionary. new_dict = dict[:]
> won't do it. Is there a good way to do this?
new_dict = {}
for k in dict.keys(): new_dict[k] = dict[k]
This is about as efficient as a built-in function could do it (unlike
tuple(), where a built-in implementation can turn an O(N*N) algorithm
into an O(N) algorithm).
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
<URL:http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>