dict view to list

[Aaron Brady]

Hi.

Is there a possibility of the dict_values, dict_items, and dict_keys
objects growing a 'tolist' method? It's one of those little things
that contributes to one's user experience.

P.S. Yes, yes, I know, -1.

 

[alex23]

Is there a possibility of the dict_values, dict_items, and dict_keys
objects growing a 'tolist' method?  It's one of those little things
that contributes to one's user experience.

Probably not, because the Python approach is to use the builtins. I'm
not sure what you feel mydict.values().tolist() might offer over the
conventional list(mydict.values()).

So yeah, -1.

 

[Aaron Brady]

Probably not, because the Python approach is to use the builtins. I'm
not sure what you feel mydict.values().tolist() might offer over the
conventional list(mydict.values()).

So yeah, -1.

I'd like to address this, even though if I weren't an interested
party, I'd probably recognize a -1 too. I'll try to be impartial.

The suggestion is entirely a "look and feel" observation. In an
interactive session, to examine the contents of a dictionary I've just
created, I need to type list(_), and lose the previous return value.
It's a better for my <anecdote> train of thought too.

I don't necessarily advocate that every collection and iterator should
grow one, though I don't really have the case for a special case for
dict views. OTOH, I find three 'tolist' methods in the standard
library: array, memoryview, and parser.ST. It could offer the same as
they do.

Mostly a convenience request I guess.

 

[Miles]

The suggestion is entirely a "look and feel" observation.  In an
interactive session, to examine the contents of a dictionary I've just
created, I need to type list(_), and lose the previous return value.
It's a better for my <anecdote> train of thought too.

Versus _.tolist(), which would also overwrite the previous return value?

I don't necessarily advocate that every collection and iterator should
grow one, though I don't really have the case for a special case for
dict views.  OTOH, I find three 'tolist' methods in the standard
library: array, memoryview, and parser.ST.  It could offer the same as
they do.

array has had that method since before Python v1.0. memoryview, for
whatever reason, is not iterable; parser.ST is also not, since it
doesn't convert to a flat sequence but rather a list tree. I don't
see the special case for dict views, at all.

-Miles

 

[Luis Gonzalez]

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?
It would be more regular and intuitive and readable from an OO point
of view.
In my oppinion, this would be cleaner.
Built-ins used like this look like an early decission made when
designing an imperative language.

Luis

 

[Terry Reedy]

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

 

[Aaron Brady]

Should we also give every collection a .toset(), .tofrozenset(),
.totuple(), and .todict() method?  This way lies the madness of
combinatorial explosion.


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. snip
The stream of object provided by
the iterator is the common means of transferring information.

AKA the iterator protocol.

snip

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

I guess there are two arguments for the change.

1. Flat is better than nested.
2. It interferes with the way people read text.

The order of events are: First, get the view. Then convert it to a
list. Hence, dictA.get_view( ).to_list( ).

This may call for a more fundamental change to a programming language
than Python should make; and it may have to wait for another
generation. It entails that function applications should be of the
form '( x )f' instead of 'f( x )', in a pretty general way.

I also recognize that natural language and thus human thinking does
admit of a certain depth of nesting. English, notably, has two means
of nesting, at least in the possessive case. 'The mother of
invention' and "invention's mother". Here is a predicate example too:
'The cat is on the mat' and 'On the mat is the cat', although the late
is mostly unattested-to these days.

 

[Tim Hoffman]

Hi Aaron

I personally don't understand how somedict.values().to_list() is
actually preferable to
list(somedict.keys())

In the standard python idiom I am constructing a new object (which I
can control the type of) using a standard language mechanism (and I
can substitute list with set or for that matter
any other class that accepts an iterable as initial argument) where
as what you advocate
is calling some special method of an instance which in fact is a
factory for instantiating some
other class, this seems to be less flat than the standard idiom and
significantly less flexible.

and more typing ;-)

How do you see the to_list() to be better or contributing the the user
experience ?

Rgds

Tim Hoffman

 

[Larry Riedel]

I see list(x.f()) as like x.f().iter().list(), where "list()"
is a method of all "iterator" objects, and "iter()" is a method
of all "iterable" objects, and whatever object is returned by
x.f() is of a type which conforms to the "iterable" interface.
I am not saying this is the way things /should/ be, but if it
was, it would make sense to me.


Larry

 

[Tim Hoffman]

Hi Larry

I actually feel this is a bad idea, (that is making list() a method of
all iterators)
because quite often iterators are created that don't end.

What happens then, is you have a method that will intentionally cause
you to run out of memory
or you exclude it from such iterators (creating inconsistancies in a
standard protocol. Ok you can do the same silly thing with list
(infiniteiterator) but
a list() method on an iterator is just plain wrong in such a
circumstance, don't you think

Regards

Tim

 

[Aahz]

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?
It would be more regular and intuitive and readable from an OO point
of view.
In my oppinion, this would be cleaner.
Built-ins used like this look like an early decission made when
designing an imperative language.

What kind of language do you think Python is?
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." --Brian W. Kernighan