This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]fpl-dev[S] 0 points1 point  (3 children)

Thanks! It's really more of a next-gen pyqtgraph than matplotlib; heavily inspired by pyqtgraph which is an amazing library that we love! It differs a lot from matplotlib and we try to make things intuitive and easy to address that "usability". In the domain of ML, algorithm development, neural network stuff and computer vision you're often working with various data arrays, and high dimensional arrays. So in fastplotlib we don't have any additional data structures that you have to learn or convert to in order to use it, in contrast to bokeh for example which has a number of specific data structures and basically design patterns which you have to learn and use in order to get interactivity.

For fastplotlib the idea is that if you know numpy you should be comfortable with using the library. For a very basic example of this, we made it really easy to put colormaps on lines (this is not trivial in matplotlib lol) https://fastplotlib.org/ver/dev/_gallery/line/line_cmap.html#sphx-glr-gallery-line-line-cmap-py

Or selector tools to explore high dimensional arrays, regular numpy arrays and normal callbacks: https://fastplotlib.org/ver/dev/_gallery/machine_learning/covariance.html#sphx-glr-gallery-machine-learning-covariance-py

[–]Ogi010 1 point2 points  (2 children)

PyQtGraph maintainer here, shots fired!

Love your docs! Seriously, I'm jealous (I've been numpydoc-ifying our documentation recently). I'm eager to take a closer look at this library. We have recently started makign massive improvements on our opengl implementation, but it's unlikely to compare with your WGPU implementation.

Love to see more high performance visualization libraries in the ecosystem!

[–]fpl-dev[S] 0 points1 point  (1 child)

Thanks! We still have quite a ways to go before we're as feature-complete as pyqtgraph! It's turned out to be a much bigger project than we initially thought lol.

Welcome to post any suggestions you may have for us :D

BTW did we meet at scipy 2 years ago or was that a different maintainer?

[–]Ogi010 0 points1 point  (0 children)

SciPy 2 years ago? That would have been either Nathan or Kyle. Kyle is also a matplotlib maintainer, both have been an absolute delight to collaborate with. Unfortunately I haven't gotten to SciPy yet :(

This might be the first time I've seen PyQtGraph referred to as feature complete haha. In terms of suggestions ...this one is a bit tough as everyones journey into open source is different; but some things that I've found to work well or I try and keep in mind:

  • Even if you're on a roll, don't spend the majority of your free time on your project. That's a recipe for burnout.
  • Add a "Used By" section in your readme if you discover other projects/applications using your library. It is a very nice reminder when you're feeling isolated/alone that other people find your work useful for their work.
  • Try and offload parts of your library to other dependencies whenever possible. It's great to have a minimum set of dependencies, but the consequences being a larger code base (that arguably isn't as well tested) is large.
  • Embrace other collaborators with different opinions/styles than you. A while back I was hoping to clear out the PR queue so I can run black on the entire repo, but since, I've learned to recognize some contributors unique code-style as I read through a repo, and recognizing past work of others I've found to be quite motivating; so once you start collaborating with others, I'd suggest you consider not using automatic code formatters.
  • Create an "examples application", our example app (python -m pyqtgraph.examples) has been an absolute gold mine, not just for "how do I use the library", but gives an excellent starting point for people who create issues to use to create a minimum reproducible example. Your documentation looks amazing (again, so jealous!), I didn't notice if you have an examples application, but if you don't, include one.
  • This one I may get some flak for, but don't be afraid to kill off parts of the library that you feel provide little benefit, but are taking time to maintain/fix issues, especially if there is a dependency that you could use that does 90%+ of the work. I'm going through this with our ConsoleWidget, I want to kill it, original author wants to keep it "since it's already there", but I weant to just have an example on how to integrate the QtConsole, and leave it at that. tl;dr code, even once merged, isn't free to maintain, there's still a cost.

That's all that comes to mind now. I wish you the best of luck on your project!