How to print a sorted list as a multi-column table

Discussion in 'Python' started by Sverker Nilsson, May 23, 2008.

  1. Hi all,

    I would like to ask about opinions about the best way to format sorted
    tables of items for interactive use. I have begun to add interactive
    help to Guppy/Heapy (http://guppy-pe.sourceforge.net) because it lacks
    the usual ways for introspection (see for example
    http://www.pkgcore.org/trac/pkgcore/doc/dev-notes/heapy.rst) which is
    due to Heapy's use of dynamic things like __getattr__ and to some
    extent properties.

    There seems to be no (good or otherwise) way to hook into the standard
    help() (?) (At least not before 2.6 where I recall seeing a __dir__
    magic method may be introduced, but I want it to be backwards
    compatible to at least 2.4, preferably to 2.3.)

    So I am about to roll my own help system. It will be based on having
    the API objects supplying a standardized '.help' attribute which can
    be used interactively, and will limit the output it prints to say 15
    or 20 rows at a time.

    That's for a background. Now what I was stumbling on which pumped up
    enough adrenalin to make me begin to write this ---

    Why are tables formatted like the following, when sorted? (Both in
    linux eg ls, ftp help, and in Python help() when listing (eg)
    modules))

    (1)

    a g m s
    b h n t
    c i o u
    d j p v
    e k q
    f l r

    Wouldn't it be more natural to just sort them like this:

    (2)

    a b c d
    e f g h
    i j k l
    m n o p
    q r s t
    u v

    What's the rationale for the choice of (1)?

    In a pager, if you want to limit the number of lines output at a time,
    then yo'd see with (1) (if artifically limiting output to 2 lines):

    a g m s
    b h n t

    So to see the f item you would have to scroll down all the way. The
    number of times you would have to scroll down is in completely
    unrelated to the item's position in sort order. That seems to defeat
    the purpose of sorting in the first place. It feels strange, to me at
    least. Anybody had the same feeling?

    Well, what's the rationale (if any) for using the layout (1)?
    Wouldn't layout (2) be better? And/or would it be confusing /
    non-pythonic / non-unlixonic if a program used the (2) layout instead?

    Have a :)nice:) weekend :)

    Sverker
     
    Sverker Nilsson, May 23, 2008
    #1
    1. Advertising

  2. Sverker Nilsson

    Mensanator Guest

    On May 23, 10:30 am, Sverker Nilsson <> wrote:
    > Hi all,
    >
    > I would like to ask about opinions about the best way to format sorted
    > tables of items for interactive use. I have begun to add interactive
    > help to Guppy/Heapy (http://guppy-pe.sourceforge.net) because it lacks
    > the usual ways for introspection (see for examplehttp://www.pkgcore.org/trac/pkgcore/doc/dev-notes/heapy.rst) which is
    > due to Heapy's use of dynamic things like __getattr__ and to some
    > extent properties.
    >
    > There seems to be no (good or otherwise) way to hook into the standard
    > help() (?) (At least not before 2.6 where I recall seeing a __dir__
    > magic method may be introduced, but I want it to be backwards
    > compatible to at least 2.4, preferably to 2.3.)
    >
    > So I am about to roll my own help system. It will be based on having
    > the API objects supplying a standardized '.help' attribute which can
    > be used interactively, and will limit the output it prints to say 15
    > or 20 rows at a time.
    >
    > That's for a background. Now what I was stumbling on which pumped up
    > enough adrenalin to make me begin to write this ---
    >
    > Why are tables formatted like the following, when sorted? (Both in
    > linux eg ls, ftp help, and in Python help() when listing (eg)
    > modules))
    >
    > (1)
    >
    > a  g  m  s
    > b  h  n  t
    > c  i  o  u
    > d  j  p  v
    > e  k  q
    > f  l  r


    Because it's easier to read when the items have more
    than one letter. Have a look at a dictionary.

    >
    > Wouldn't it be more natural to just sort them like this:
    >
    > (2)
    >
    > a  b  c  d
    > e  f  g  h
    > i  j  k  l
    > m  n  o  p
    > q  r  s  t
    > u  v


    Well, it's certainly easier to program, but ease of
    programming often doesn't correlate to ease of use.

    >
    > What's the rationale for the choice of (1)?


    Easier to use although harder to program. Remeber,
    the user doesn't care how hard is was for you to
    implement.

    >
    > In a pager, if you want to limit the number of lines output at a time,
    > then yo'd see with (1) (if artifically limiting output to 2 lines):
    >
    > a  g  m  s
    > b  h  n  t
    >
    > So to see the f item you would have to scroll down all the way.  The
    > number of times you would have to scroll down is in completely
    > unrelated to the item's position in sort order. That seems to defeat
    > the purpose of sorting in the first place. It feels strange, to me at
    > least. Anybody had the same feeling?


    No.

    >
    > Well, what's the rationale (if any) for using the layout (1)?
    > Wouldn't layout (2) be better? And/or would it be confusing /
    > non-pythonic / non-unlixonic if a program used the (2) layout instead?


    The obvious solution is to do both, like the DOS directory
    command:

    c:\python25\user>dir/d
    Volume in drive C has no label.
    Volume Serial Number is D019-C60D

    Directory of c:\python25\user

    [.] ken_about_STD.txt
    [..] ldapart2.py
    153.py ldas.py
    23items.py lda_header.py
    3n35_ldas.mdb legendre.py
    3n35_ldas.xls long_ago.py
    3n_prime.py loops_outside_lda.py
    5sideddice.xls Matlab_useless.py
    5_sided_dice.py MHtest.py
    another_sqlite3_test.py MHtest2.py
    any_good_algo.py Minnie_Mouse.txt
    attractors023.exe mod32.py
    attractors025.exe mufbuff1.py
    attractors_vs_primitiveroots.py m_version.py

    c:\python25\user>dir/w
    Volume in drive C has no label.
    Volume Serial Number is D019-C60D

    Directory of c:\python25\user

    [.] [..]
    153.py 23items.py
    3n35_ldas.mdb 3n35_ldas.xls
    3n_prime.py 5sideddice.xls
    5_sided_dice.py another_sqlite3_test.py
    any_good_algo.py attractors023.exe
    attractors025.exe attractors_vs_primitiveroots.py
    attractor_test.py a_perm_generator.py
    bad_doc.py base6.py
    baseconvert.py big_pi_e.py
    bits.py Book2.xls
    buts_in_MH.py cc_test.py

    >
    > Have a :)nice:) weekend :)
    >
    > Sverker
     
    Mensanator, May 23, 2008
    #2
    1. Advertising

  3. En Fri, 23 May 2008 15:03:16 -0300, Mensanator <> escribió:
    > On May 23, 10:30 am, Sverker Nilsson <> wrote:


    >> Why are tables formatted like the following, when sorted? (Both in
    >> linux eg ls, ftp help, and in Python help() when listing (eg)
    >> modules))
    >>
    >> (1)
    >>
    >> a  g  m  s
    >> b  h  n  t
    >> c  i  o  u
    >> d  j  p  v
    >> e  k  q
    >> f  l  r

    >
    > Because it's easier to read when the items have more
    > than one letter. Have a look at a dictionary.


    I agree with the OP. Dictionaries have two or more columns, but they span several *small* pages. The index above asumes an infinite page height, like a dictionary with all pages joined together making a single giant page. If dictionaries were sorted like the index above, "Python" could appear in the first page, and "Django" in the last one...

    >> In a pager, if you want to limit the number of lines output at a time,
    >> then yo'd see with (1) (if artifically limiting output to 2 lines):
    >>
    >> a  g  m  s
    >> b  h  n  t
    >>
    >> So to see the f item you would have to scroll down all the way.  The
    >> number of times you would have to scroll down is in completely
    >> unrelated to the item's position in sort order. That seems to defeat
    >> the purpose of sorting in the first place. It feels strange, to me at
    >> least. Anybody had the same feeling?

    >
    > No.


    I do!

    >> Well, what's the rationale (if any) for using the layout (1)?
    >> Wouldn't layout (2) be better? And/or would it be confusing /
    >> non-pythonic / non-unlixonic if a program used the (2) layout instead?

    > The obvious solution is to do both, like the DOS directory
    > command:


    I'd use layout (1) *but* on a single page at a time. The layout you see on real dictionaries, or printed books.

    --
    Gabriel Genellina
     
    Gabriel Genellina, May 25, 2008
    #3
    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. savvy
    Replies:
    1
    Views:
    487
    savvy
    Jan 18, 2006
  2. Replies:
    2
    Views:
    512
    Gerard Flanagan
    Mar 22, 2006
  3. Larry R
    Replies:
    1
    Views:
    390
    marss
    Jun 8, 2007
  4. Santiago  Romero
    Replies:
    10
    Views:
    534
    Peter Otten
    Jan 21, 2008
  5. Xavier Noria

    print LIST vs print join "", LIST

    Xavier Noria, Apr 16, 2004, in forum: Perl Misc
    Replies:
    14
    Views:
    201
    Uri Guttman
    Apr 19, 2004
Loading...

Share This Page