Possible interactions with taldcroft/asciitable?

[wesm]

No description provided.

[EmlynC]

asciitable works really well with pandas already. I've been using asciitable to format the dataframes out to Latex tables and it's already pretty terse because you can use the to_records method on the DataFrame object.

asciitable.write(dataframe.to_record(), "table.dat", Writer=asciitable.Latex, latexdict=latexdict)

We could always bundle a dictionary of sane defaults, perhaps prepopulate the caption, the title etc based on metadata from the DataFrame object. Perhaps hide the need to call to_record() by subclass it.

[wesm]

Maybe we should create an xtable-lite inside pandas using asciitable (or simpletable in statsmodels) for easily outputting DataFrame to LaTeX. If you wanted to create some fully worked examples of this I'd be happy to include them in the documentation (pull request would be best!)

[EmlynC]

... create some fully worked examples of this I'd be happy to include them in the documentation ...
Sure, I'll have a look at doing that when I've got a moment.

... create an xtable-lite inside pandas using asciitable (or simpletable in statsmodels) ...
Reusing code from those packages is definitely the right way to go but if I may be so bold, I think we can go one step further and build a class that dispatches method to build any conceivable table structure.

Consider a proposed write_to method.

dataframe.write_to('xls', options=default, filename=filepath)

Underneath that we can use a dispatcher function to write the table out to any sensible binary table format such as XLS (using xlwt), XML formats such as XSLX (using openpyxl) and ODS (using pyODF or ezODF), Python objects such as numpy, array etc and of course the plaintext delimited variety (using asciitable or the numpy methods as a fallback). Once done, I reckon this interface would be cleaner than the current collection of methods you've made thus far such as to_records() and to_csv. Plus we can gracefully handle the dependency issues that this will inevitably raise by catching when a dependency isn't there and telling the user to try one of the fallback methods i.e. using numpy.

The impetus for suggesting this is because I'm kind of sitting on the code already because my clients in the Pharma industry always seem to want it in a bazillion formats and this is a common method I use in my programs. I'd be more than happy to do a 'pull' and work on integrating the code I have into the pandas code because I 'own' it and this is probably the best way I can contribute back to your library that I use a lot.

Sound like a plan capt'n?

[EmlynC]

Sorry for the double post but I've just seen the other pull request (#735) with regards to the excel parser. I'll check that code before I proceed.

[wesm]

I think it makes sense to build up a suite of IO adapters to all of the foreseeable formats. Then can decide on the question of the user API. Perhaps augmenting the save method is the way to go (which currently uses pickle, but will eventually use a custom binary format, whenever I can get around to doing that. Pull request away IMHO!

[EmlynC]

Fair enough, a case of first things first - the specifics of the API comes after you have methods to populate the API with. I'll have a look at save also. I've got a fork now so I'll send a pull request when I've got something to show for it.

[cpcloud]

superceded by #3190