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

[Sverker Nilsson]

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

 

[Mensanator]

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

 

[Gabriel Genellina]

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...

No.

I do!

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.