dict view to list

Discussion in 'Python' started by Aaron Brady, Mar 27, 2009.

  1. Aaron Brady

    Aaron Brady Guest

    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.
     
    Aaron Brady, Mar 27, 2009
    #1
    1. Advertising

  2. Aaron Brady

    alex23 Guest

    On Mar 27, 3:44 pm, Aaron Brady <> wrote:
    > 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.
     
    alex23, Mar 27, 2009
    #2
    1. Advertising

  3. Aaron Brady

    Aaron Brady Guest

    On Mar 27, 7:14 am, alex23 <> wrote:
    > On Mar 27, 3:44 pm, Aaron Brady <> wrote:
    >
    > > 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.


    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.
     
    Aaron Brady, Mar 27, 2009
    #3
  4. Aaron Brady

    Miles Guest

    On Fri, Mar 27, 2009 at 9:58 AM, Aaron Brady wrote:
    > 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
     
    Miles, Mar 27, 2009
    #4
  5. 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

    On 27 mar, 09:14, alex23 <> wrote:
    > On Mar 27, 3:44 pm, Aaron Brady <> wrote:
    >
    > > 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.
     
    Luis Gonzalez, Mar 27, 2009
    #5
  6. Aaron Brady

    Terry Reedy Guest

    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
     
    Terry Reedy, Mar 28, 2009
    #6
  7. Aaron Brady

    Aaron Brady Guest

    On Mar 27, 7:26 pm, Terry Reedy <> wrote:
    > 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.

    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.
     
    Aaron Brady, Mar 29, 2009
    #7
  8. Aaron Brady

    Tim Hoffman Guest

    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

    On Mar 27, 1:44 pm, Aaron Brady <> wrote:
    > 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.
     
    Tim Hoffman, Mar 30, 2009
    #8
  9. Aaron Brady

    Larry Riedel Guest

    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
     
    Larry Riedel, Mar 30, 2009
    #9
  10. Aaron Brady

    Tim Hoffman Guest

    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

    On Mar 31, 6:07 am, Larry Riedel <> wrote:
    > 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, Mar 31, 2009
    #10
  11. Aaron Brady

    Aahz Guest

    In article <>,
    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?
    >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 () <*> 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
     
    Aahz, Apr 4, 2009
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Skip Montanaro
    Replies:
    0
    Views:
    414
    Skip Montanaro
    Aug 15, 2003
  2. Alexander Kozlovsky

    dict!ident as equivalent of dict["ident"]

    Alexander Kozlovsky, May 21, 2006, in forum: Python
    Replies:
    5
    Views:
    360
    Alexander Kozlovsky
    May 22, 2006
  3. Paul Melis

    dict.has_key(x) versus 'x in dict'

    Paul Melis, Dec 6, 2006, in forum: Python
    Replies:
    48
    Views:
    1,322
    Kent Johnson
    Dec 15, 2006
  4. Almad
    Replies:
    8
    Views:
    402
    Terry Reedy
    Dec 14, 2006
  5. Parthiv Joshi
    Replies:
    1
    Views:
    691
    Samuel L Matzen
    Jul 6, 2004
Loading...

Share This Page