Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > How to print a sorted list as a multi-column table

Reply
Thread Tools

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

 
 
Sverker Nilsson
Guest
Posts: n/a
 
      05-23-2008
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/...otes/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
 
Reply With Quote
 
 
 
 
Mensanator
Guest
Posts: n/a
 
      05-23-2008
On May 23, 10:30*am, Sverker Nilsson <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
 
Gabriel Genellina
Guest
Posts: n/a
 
      05-25-2008
En Fri, 23 May 2008 15:03:16 -0300, Mensanator <(E-Mail Removed)> escribió:
> On May 23, 10:30*am, Sverker Nilsson <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Sorting a list depending of the indexes of another sorted list Santiago Romero Python 10 01-21-2008 03:10 PM
Convert (sorted) list of dics to nested list ? shearichard@gmail.com Python 2 03-22-2006 09:34 PM
Print dict in sorted order Kamilche Python 6 01-30-2006 01:03 PM
print LIST vs print join "", LIST Xavier Noria Perl Misc 14 04-19-2004 01:44 PM



Advertisments