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

[Mensanator]

On May 23, 10:30 am, Sverker Nilsson <s... at sncs.se> 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