search

gp1313 / iep

Automatically exported from code.google.com/p/iep
0 stars 0 forks source link

Better lists, tuples and dicts display in the Workspace view #173

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
At the moment lists and tuples display in the Repr column in the workspace like 
so: "<list/tuple with n elements>"; while dicts show the first element like so: 
"{k: v" .

Those should be displayed in a uniform, informative format: The content of the 
list/tuple/dictionary up to the limit of the column width or to a set number of 
values (to prevent overflow with large numbers of items)

For example:
Name     Type     Repr
----     ----     ----
list1    list     [1, 2, 3, 4, 5...]
tuple1   tuple    (1, 2, 3, 4, 5...)
dict1    dict     {k1: v1, k2: v2, k3: v3...}

(The closing bracket are optional.)

Original issue reported on code.google.com by zaha...@gmail.com on 4 Mar 2013 at 2:23

GoogleCodeExporter commented 8 years ago 
The point of "<list/tuple with n elements>" is that for large lists, the number 
of items is usually more informative than the first few elements. 

Having said that, the current implementation also shows lists/tuples in that 
way when there is just one element. Which does not make sense.

Perhaps the type-field could also show the size (for objects that have a size)?

Original comment by almar.klein@gmail.com on 4 Mar 2013 at 2:49

GoogleCodeExporter commented 8 years ago 
I personally dislike fields that display more than one kind of textual data 
without clearly identifying what is being displayed - can be problematic. 
Perhaps a new column - "Size" - and "Repr" be relabelled "Content"?

And both function and modules have sizes that can be displayed - the former in 
rows, the latter either in rows or in kbs - though I'm not sure what benefit 
this specifically will give outside of refactoring.

Original comment by zaha...@gmail.com on 4 Mar 2013 at 3:25

GoogleCodeExporter commented 8 years ago 
> Perhaps a new column - "Size"

I like that.

> both function and modules have sizes that can be displayed - the former in 
rows, the latter either in rows or in kbs

Rows as in number of lines? That is problematic, because these cannot be 
determined for functions defined in extension modules. I'm not even sure it can 
be determined from a function object.

But there's nothing wrong with leaving the size column blank for objects to 
which it does not apply.

Original comment by almar.klein@gmail.com on 4 Mar 2013 at 3:42

GoogleCodeExporter commented 8 years ago 
> Perhaps a new column - "Size"

I like that.

> both function and modules have sizes that can be displayed - the former in 
rows, the latter either in rows or in kbs

Rows as in number of lines? That is problematic, because these cannot be 
determined for functions defined in extension modules. I'm not even sure it can 
be determined from a function object.

But there's nothing wrong with leaving the size column blank for objects to 
which it does not apply.

Original comment by almar.klein@gmail.com on 4 Mar 2013 at 3:42

GoogleCodeExporter commented 8 years ago 
Yes, I just thought about it. Maybe leave in the code itself a placeholder in 
case some use for rows number etc. is found in the future.

Original comment by zaha...@gmail.com on 4 Mar 2013 at 4:15

GoogleCodeExporter commented 8 years ago 
As part of migrating our code repositories from Googlecode
to Bitbucket, all IEP issues are now tracked at 
https://bitbucket.org/iep-project/iep/issues

To view this issue, use this link (with X replaced by the issue number):
https://bitbucket.org/iep-project/iep/issue/X

Issues on Bitbucket can be created by anyone. Commenting on issues requires 
login via Bitbucket, Google, Twitter or Github.

Original comment by almar.klein@gmail.com on 11 Jun 2013 at 2:40