On May 23, 10:30 am, Sverker Nilsson <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
