dict view to list
Aaron Brady
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
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
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
> 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 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.
Rhodri James
wrote:
> I guess there are two arguments for the change.
>
> 1. Flat is better than nested.
I don't think that's really what this is refering to.
> 2. It interferes with the way people read text.
Insert "some" before "people" and I'd have to agree.
> The order of events are: First, get the view. Then convert it to a
> list. Hence, dictA.get_view( ).to_list( ).
Alternatively, "get the list of dictA's view," or
list(dictA.get_view()). Both are legitimate text, after all.
> 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.
Sorry, but if what you're describing isn't essentially calling a
method, then I don't understand the point you're trying to make.
If it is, you still need to address Terry's point about why lists
get the special treatment and not other built-in types.
> 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.
Erm, this isn't what I understand by 'nesting' in language, which has
more to do with how many subclauses, like these, you can cope with
being active at any one time before you forgot what the sentence
started off being about :-)
--
Rhodri James *-* Wildebeeste Herder to the Masses
Tim Hoffman
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
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
Luis Gonzalez <lui...@gmail.com> 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?
>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 (aa...@pythoncraft.com) <*> 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