Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bokeh – a Python interactive visualization library

bokeh.pydata.org

Post reply on HN
Print view View original

61–67 of 67 posts

Re: Bokeh – a Python interactive visualization library

#61

Post by SiVal »

bootload wrote: post #58
fpliger wrote: post #46

Earlier quoted context omitted.

Thanks for the feedback. We keep a continuous and frequent effort to make documentation more efficient and straightforward .. Building clear is a constant/endless effort and feedback is very important. To clarify, Futures is required for bokeh server as an extra dependency on Python 2.7 since it's not a battery included like for Python > 3.2.. if you conda install Bokeh it should be installed already for you. You can…

thx @fpilger, fantastic to see another Py3 ready application. It's clear now. One way to avoid this is either give a install write up an installation guide [0] that explicitly mentions the python version and dependencies. This is one of the first questions I ask, "is this code Python3 ready?", so I look at the install requirements first. Maybe I'm an edge case. A short cut might be just to say in big words, Python3 r…

If wanting to know up front if this is designed for the future or the past is an edge case, it's a pretty crowded edge. Python 3 was released eight years ago, and I will ALWAYS choose a competing technology (if it means a language other than Python, that's fine with me) before I'll let Python 2 play any role in a new project I architect.

The first thing I looked for on the Bokeh website was some sort of clear statement on the front page about it being Python 3. I don't have an immediate need for it, but if it's Python 3, I'll keep it in mind. If it's just that euphemistic "Python", it may as well be Cobol for all I'd care.

I thought I'd skim over these comments just in case someone asked the obvious question, and someone did. (Thank you.) And, yes, it is apparently Python 3 enough that we wouldn't need to use any Python 2 if we adopted it.

Very nice. Now I wish I DID need it, but maybe I'll do a side project of my own with it, just for fun. I'll be keeping it in mind in any case. I'll bet "Python 3" is mentioned somewhere on the site, but I didn't spot it right away. It might be worth making it a bit more prominent, since it is an important feature for those designing for the future.

Re: Bokeh – a Python interactive visualization library

#62

Post by bigreddot »

SiVal wrote: post #61
bootload wrote: post #58

Earlier quoted context omitted.

thx @fpilger, fantastic to see another Py3 ready application. It's clear now. One way to avoid this is either give a install write up an installation guide [0] that explicitly mentions the python version and dependencies. This is one of the first questions I ask, "is this code Python3 ready?", so I look at the install requirements first. Maybe I'm an edge case. A short cut might be just to say in big words, Python3 r…

If wanting to know up front if this is designed for the future or the past is an edge case, it's a pretty crowded edge. Python 3 was released eight years ago, and I will ALWAYS choose a competing technology (if it means a language other than Python, that's fine with me) before I'll let Python 2 play any role in a new project I architect. The first thing I looked for on the Bokeh website was some sort of clear stateme…

I wrote most of the docs, and my default day-to-day python is Python 3, so it's really just a matter of forgetting that "Python 3 ready" is something still needs to be mentioned at all. In fact we even have a python 3 only feature at the moment (python->JS compilation) But yes, just to clarify our CI tests run on python 2.7, 3.4 and 3.5

Re: Bokeh – a Python interactive visualization library

#63

Post by bigreddot »

noobermin wrote: post #50
ISL wrote: post #16

Earlier quoted context omitted.

If you're not wedded to Python, have a gander at Gnuplot. Despite its quirks, it's my favorite plotting tool.

I severely dislike Gnuplot, but then again, I am wedded to Python. I'm not sure how versatile it is, at least from the slightly acquainted position I am.

FYI it's really dead simple to write new "bokeh" command line tools as Bokeh apps now. We already have several ("bokeh html" and "bokeh json") but we are definitely interested in make a gnuplot-like bokeh command line tool that you can just point at a CSV or log file and get a visualization right out. E.g. something like "bokeh graph foo.log -x time -y connections --tail" would create an automatically updating visualization of a growing log file. Or if anyone is interested in this functionality and wants to help speed along the development, please let us know!

Re: Bokeh – a Python interactive visualization library

#64

Post by bigreddot »

herrkanin wrote: post #4

Since I have never really liked Matplotlib I would really like to learn Bokeh, but unfortunately its inability to export its visualizations in SVG or similar formats makes it kind of useless for me as a scientist wanting to publish my results.

I definitely empathize. It's a technically challenging problem, there are lots of competing important priorities, and we are a small team that can only humanly accomplish so much work at once. Our vision for Bokeh was to be able to create and share interactive data applications with a minimum of python and little-to-no JS and "web tech" required. We are closing in on that vision, so it is my fervent hope (and intention) that we'll be able to turn to this important priority soon as well.

Re: Bokeh – a Python interactive visualization library

#65

Post by ricleal »

jackgolding wrote: post #31
herrkanin wrote: post #4

Since I have never really liked Matplotlib I would really like to learn Bokeh, but unfortunately its inability to export its visualizations in SVG or similar formats makes it kind of useless for me as a scientist wanting to publish my results.

I would suggest Plot.ly which is now open source and can export to html (with a lot of JavaScript which generates the SVG)

Plot.ly looks better to me as well. Specially the 3D stuff.

Re: Bokeh – a Python interactive visualization library

#66

Post by bootload »

SiVal wrote: post #61
bootload wrote: post #58

Earlier quoted context omitted.

thx @fpilger, fantastic to see another Py3 ready application. It's clear now. One way to avoid this is either give a install write up an installation guide [0] that explicitly mentions the python version and dependencies. This is one of the first questions I ask, "is this code Python3 ready?", so I look at the install requirements first. Maybe I'm an edge case. A short cut might be just to say in big words, Python3 r…

If wanting to know up front if this is designed for the future or the past is an edge case, it's a pretty crowded edge. Python 3 was released eight years ago, and I will ALWAYS choose a competing technology (if it means a language other than Python, that's fine with me) before I'll let Python 2 play any role in a new project I architect. The first thing I looked for on the Bokeh website was some sort of clear stateme…

"If wanting to know up front if this is designed for the future or the past is an edge case, it's a pretty crowded edge. Python 3 was released eight years ago"

good point: a quick search reveals that Py2.x is still in a lot of legacy code (dependencies -- the big one), so I always check first:

- https://python3wos.appspot.com/

- http://stackoverflow.com/questions/30751668/python-2-vs-pyth...

- http://hiltmon.com/blog/2014/01/04/python-its-a-trap/

- https://blog.newrelic.com/2014/01/21/python-3-adoption-web-a...

- http://www.randalolson.com/2015/01/30/python-usage-survey-20...

Re: Bokeh – a Python interactive visualization library

#67

Post by dbyte »

Rapidwire wrote: post #45
dbyte wrote: post #23

Earlier quoted context omitted.

Working on SVG? What about EPS instead? For scientific publishing EPS is much better unless your visualisation is pretty much an high entropy one.

Please explain why EPS is better.

Reason is quite simple. EPS is based on PostScript. PDF specification contains a subset of PostScript. Embedding EPS into PDF is trivial and yields high quality results. For a printing publication workflow having EPS files at hand saves a lot of time and problems.

SVG is nice too, just needs few more intermediate steps.

Post reply on HN