search

lmaurits / prettytable

Automatically exported from code.google.com/p/prettytable
Other
22 stars 6 forks source link

Add the ability to parse pretty table output back into its original format #27

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Currently many people use pretty table to create nice ASCII tables, which is 
great, but then there is a set of people who want to read that ASCII format 
back into python. It might be useful to associate with each ASCII table 
generator class a way to reverse said ASCII table back into a dictionary.

Original issue reported on code.google.com by harlo...@gmail.com on 19 Mar 2013 at 12:41

GoogleCodeExporter commented 9 years ago 
Hi there,

Thanks for the suggestion.  Can I ask you to describe what your use case is 
that has made you want this feature?

This is something I have thought about previously, more than once, but I 
usually end up shying away from actually implementing it.  There are a few 
reasons for this.  One, I am keen to try to keep PrettyTable from expanding 
into a "kitchen sink" module, and to instead keep it focused on doing just what 
it needs to do to get its job done.  Two, there is quite some complexity 
involved.  For example, going from a string back to a PrettyTable object, 
there's no way to know if a table entry of "4" was generated from a string "4" 
or an integer int(4), so one can never guarantee that the reverse mapping is 
exactly right.  Also, there will be pathalogical cases that are hard to parse 
(like when some table entry contains an instance of the horizontal or junction 
character).  Basically, writing something which works with 100% reliability 
would probably be as big a project as PrettyTable in the first place.  Finally, 
I have never been able to think of a good reason why someone would truly need 
this.  If the tables you want to "reverse" were produced previously by your 
application, then it would be a much better idea to, rather than saving the 
ASCII tables, just save the data that was used to build them in the first place.

However, I am totally willing to listen to reason.  If you have a compelling 
use case where you really have to be able to do this and there's no other way 
to solve your problem, then I will consider implementing it.

Original comment by luke@maurits.id.au on 19 Mar 2013 at 2:19

GoogleCodeExporter commented 9 years ago 
I am closing this issue due the high effort involved in impelementing it and 
the lack of compelling arguments for why it might be needed, after a 
sufficiently long wait.  If anybody wants to put forth a good argument, feel 
free to comment or open a new issue.

Original comment by luke@maurits.id.au on 5 Oct 2013 at 10:31