Luis Gonzalez wrote:
Yes, I know the python approach is to use built-ins.
But wouldn't it be cool if we could do mydict.values().tolist()
instead?
Should we also give every collection a .toset(), .tofrozenset(),
.totuple(), and .todict() method? This way lies the madness of
combinatorial explosion.
It would be more regular and intuitive and readable from an OO point
of view.
In my opinion, this is backwards. From an OO point of view, instances
of class X should be created by the constructor for that class. That is
where the knowledge of the intermal structure of class X instances
belongs. The principle of information hiding dictates that other
classes should not know how to create an X. On the other hand,
collection classes should be iterable and know how to de-structure
themselves. So list(iterable) operates by iterable providing an iterator
that list uses to create an instance. The stream of object provided by
the iterator is the common means of transferring information.
In my oppinion, this would be cleaner.
To me, the hypothetical
import operator
map(operator.attrgetter('tolist'), [[1,2,3], (1,2,3),
{1,2,3},{1:'a',2:'b',3:'c'}])
is a lot dirtier than the current
map(list, [[1,2,3], (1,2,3), {1,2,3},{1:'a',2:'b',3:'c'}])
Built-ins used like this look like an early decission made when
designing an imperative language.
It is part of python basic design. Functions used as functions can be
passed as arguments to functions and used to operator on heterogeneous
collections, as in the example above.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
