-
-
Notifications
You must be signed in to change notification settings - Fork 404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new Derived stream class #4532
Conversation
that generalizes the concept of having a stream that produces values based on one or more other streams. Update SelectionExpr stream to be a Derived stream subclass.
self.assertEqual(len(expr_stream._source_streams), 2) | ||
self.assertIsInstance(expr_stream._source_streams[0], SelectionXY) | ||
self.assertIsInstance(expr_stream._source_streams[1], Lasso) | ||
self.assertEqual(len(expr_stream.input_streams), 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a particular reason to switch from source
to input
here? Does that help make the terminology more consistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here was my thinking. For the SelectionExpr
stream, it happened to be the case that all of the input streams were always attached to a single source
element. The Derived
stream doesn't assume this, all it knows is that it should calculate a value based on a list of streams that come from somewhere else. So I guess it seemed to me that using "source" here was no longer accurate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks; makes sense to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me too.
The AppVeyor tests are failing due to a bunch a bunch of failures in Travis tests aren't even being run I don't think:
Does this mean anything to anyone else? |
spatialpandas master pins to <1.0 to avoid those issues, but it hasn't been released yet, so you're presumably still getting an older spatialpandas here. Pinning pyarrow here seems reasonable to me; @jlstevens was looking at releasing spatialpandas. |
Oh, and this particular immediate issue is presumably that Travis is providing 3.6 or 3.8, while the rest of the setup is assuming 3.7. That happens every time Travis updates their default images, I think, and we have to adapt. I forget the details, but again @jlstevens will presumably remember. |
The pyenv stuff can be fixed by switching back to |
No objection to pinning pyarrow in the test dependencies in setup.py for now. |
I went ahead and got spatialpandas working with pyarrow 1.0 in holoviz/spatialpandas#46. So hopefully this will take care of the issue here once that package is released. |
Looking good, I'll review and hopefully merge this evening. |
Actually, I'm working on the As you have time, I'd appreciate feedback on #4534 and I'll update this PR once I've gotten further with |
Ok, I removed |
I know this is WIP and I am only raising a naming issue, but I don't think The antonym I probably liked the most from this list is probably |
It may not be the best word, but it's a word people use: https://www.support.xerox.com/en-us/article/en/x_wc7245_en-O12395 I think it's useful to have the visual semantic link to |
Yeah, I believe these should be very nearly duals. I'll document more when that PR is ready. @jlstevens, just to clarify, |
@jonmmease Could you rebase both PRs? CI is working again on master. |
Updated with master, and things have gotten further! In AppVeyor, seeing this error
with this in the stack trace:
Based on https://bugs.python.org/issue14894, looks like this is an issue with comparing version numbers with different number parts that mix numbers and letters. e.g. this also raises the error |
Let's fix appveyor separately, as long as Travis passes I'm happy to merge. Only a very minor issue there:
|
ping @philippjfr. Travis is green now. Thanks for taking the time to look this over! |
Thank you for working on this! |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
closes #4530
This PR introduces a new
Derived
stream class that generalizes the concept of having aStream
that produces values based on one or more other input streams.The
SelectionExpr
stream had done this in a somewhat ad-hoc way, but with this PRSelectionExpr
is now a subclass of the newDerived
stream.The existing
SelectionExpr
tests pass with minimal updates. I also added a new set of tests forDerived
streams directly inholoviews/tests/teststreams.py
. This is a good place to look at for a simple example of what aDerived
stream subclass looks like.Let me know if you have any questions or concerns about the approach or API. Thanks!