I think SQL can be used, so I just use SQLite for the data visualization. I wrote a extension to do so, but many thing it does not yet include. I think SQLite extensions for doing graphics will be good idea.
Can you elaborate on how exactly you're "using SQLite for data visualization?"
Python Data Visualization 2018: Why So Many Libraries?
101–105 of 105 posts
Re: Python Data Visualization 2018: Why So Many Libraries?
#102Earlier quoted context omitted.
How do you transfer data from Python to R? I like the look of ggplot2, but most of my data I keep as pickle files.
Exporting as a CSV (e.g. pandas's to_csv) works fine, since R/ggplot2 expects tabular data. You probably shouldn't be keeping data as pickles, for both compatibility and security reasons.
It's science research. My own simulation code and data. Some of it is hdf5, but pickle files are pretty convenient. Workflow is mainly turning data into plots. Heh, I thought I was doing alright since I'm not using textfiles.
Re: Python Data Visualization 2018: Why So Many Libraries?
#103Earlier quoted context omitted.
Can you elaborate on how exactly you're "using SQLite for data visualization?"
The data is either stored in a SQLite database or can be imported (either permanently or temporarily), and then queried (including with a WHERE clause and/or various other stuff, if applicable), and extension for graphics can be use for making the graphics (sqlext_graph), display on screen (sqlext_xwindows), or save to disk (sqlext_pipe and Farbfeld Utilities). Mainly, I fail to see why should I need a different prog…
Also, by the time you're leveraging SQL extensions, are you really still "using SQL"?
Re: Python Data Visualization 2018: Why So Many Libraries?
#104Re: Python Data Visualization 2018: Why So Many Libraries?
#105Earlier quoted context omitted.
Oh wow, thanks! I'd seen the yhat port before but not this one.
It's way, WAY better than the yhat port
But if I said that, I have to be a pedant with no joy in their life, so...