You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The docs on MarkDef show that it takes the composite mark strings 'boxplot" etc as arguments, but this is not correct. Those need to be passed to CompositeMarkDef instead. The type hint is correct and does not include the composite marks:
I think the docstring is fetched from mark.ts in Vega-Lite, where there is only a generic definition, so I'm not sure that we can actually separate it on the Altair level. We might even argue we don't need to list the individual strings now that they are already included in the type hint (but again, not sure how to exclude that from being fetched from VL).
The text was updated successfully, but these errors were encountered:
I think that this is ideally changed in VL so that we can just can keep taking these descriptions from the VL schema. Also, the VL schema itself would also be improved by it.
Docstring seems to come from that place you linked to and is then used for MarkDefhere and for CompositeMarkDefhere. There should probably a separate docstring for these two so that it matches with the type hints. Would you be ok if we move this to the VL repo?
Great, I didn't see that there were separate definitions of MarkDef and CompositeMarkDef; hopefully it can just be changed in each one of those classes then. I couldn't transfer to another org so I opened vega/vega-lite#9290
Follow up on #3266
The docs on
MarkDef
show that it takes the composite mark strings'boxplot"
etc as arguments, but this is not correct. Those need to be passed toCompositeMarkDef
instead. The type hint is correct and does not include the composite marks:I think the docstring is fetched from
mark.ts
in Vega-Lite, where there is only a generic definition, so I'm not sure that we can actually separate it on the Altair level. We might even argue we don't need to list the individual strings now that they are already included in the type hint (but again, not sure how to exclude that from being fetched from VL).The text was updated successfully, but these errors were encountered: