Concatenation operators about altair HOT 4 CLOSED

Good point -- altair.vegalite.v2.schema.core.VegaLiteSchema is too broad of a parent class because it includes stuff like Scales.

Digging a bit more into the Altair class structure, it looks like "altair.vegalite.v2.api.TopLevelMixin" is actually more likely to be the right parent class. That is where these operators are defined in the Altair source code: https://github.com/altair-viz/altair/blob/master/altair/vegalite/v2/api.py#L399. The individual Chart classes inherit the operator methods from that parent class.

Having an additional check for both arguments seems like a great idea to get more informative error message.

from altair.

I like it!

There seems to be a manageable set of chart classes, so I hope it would work to consider something like:

"|.altair.vegalite.v2.api.Chart"
"|.altair.vegalite.v2.api.HConcatChart"
"|.altair.vegalite.v2.api.VConcatChart"
"|.altair.vegalite.v2.api.LayerChart"
"|.altair.vegalite.v2.api.FacetChart"
"|.altair.vegalite.v2.api.RepeatChart"

I don't have enough experience, but can all operators be used with all types of charts? I suppose we will find out...

A weird thing I came across when I was hashing out examine() was that one of the compound charts I had created had only the top-level python class "python.builtin.object", but not the rest of the classes. This is what motivated me to add examine.python.builtin.object. I was not smart enough to make a reproducible example, and I can't seem to reproduce it now 😐- so maybe it does not need to be there.

Just a heads-up in case you come across something similar.

from altair.

I think the operators will work with all types of charts but I haven't tested them all out yet... will try more out.

I am suspecting that "altair.vegalite.v2.schema.core.VegaLiteSchema" might be the right parent class that covers all the chart types you listed but also need to more carefully verify that.

"|.altair.vegalite.v2.schema.core.VegaLiteSchema" <- function(e1, e2) {
 alt$hconcat(e1,e2)
}

Would be nice to be able to have one function rather than six, if possible! I've put together these functions for all three operators in a branch on my fork, but will test them out more with different plot objects and combinations before making a PR.

That does sound weird about the chart that was only "python.builtin.object". I'll keep a lookout for that occurring, thanks for the heads up. I am a bit hesitant to define something as common as "+" for a class that would occur for any reticulate/python object, though.

from altair.

I completely agree that we should not be defining + for "python.builtin.object" - I had it in the back of my head to sort out whose "fault" it was, and I thought "I'll remember how I got here"...

Please go ahead with a PR as you see fit.

My motivation in suggesting six functions was the possibly-cryptic Python error-message that will get thrown upon rendering if we try to + an alt$Chart() with an alt$Scale(), as both are "altair.vegalite.v2.schema.core.VegaLiteSchema". But this does not defend against the second argument being a scale, only the first. So, faulty motivation.

Following the one-function route, what do you think about throwing an error if the names of the first-level classes do not match the regex "Chart$"?

from altair.