jonmmease / ipyplotly Goto Github PK

It would be great to support something like the link and directional_link functions of traitlets (http://traitlets.readthedocs.io/en/stable/utils.html) between combinations of ipyplotly Figure properties and ipywidgets.

For example, something like the following could be used to create a two-way link between a FloatRangeSlider and the range extents of a Figure's xaxis

x_slider = FloatRangeSlider(value=[0, 1])
link((x_slider, 'value'), (fig, 'layout', 'xaxis', 'range'))

Or the marker.color properties of two scatter traces could be linked together to keep the colors in sync

link((fig1, 'data[0]', 'marker', 'color'), fig2, 'data[0]', 'marker', 'color')

I don't see add_ternary anywhere in the autocomplete... is that intentional?

Add Python 2.7 support in preparation for integration with the plotly.py codebase.

• Replace type annotations with numpydoc docstring type annotations. Make sure that PyCharm/Jedi completion engines can still pick up full type inference.
• TBD...

Note: The codegen code will stay in Python 3.6 so that we can continue using PEP498 literal string interpolation.

Idea: add an ipyplotly.graph_objs package for backward compatibility with plotly.py.

Mappings from ipyplotly.graph_objs to ipylotly.datatypes

• graph_objs.Figure -> datatypes.Figure
• graph_objs.Layout -> datatypes.Layout
• graph_objs.Scatter -> datatypes.trace.Scatter
• graph_objs.[TraceType] -> datatypes.trace.[TraceType]

All graph_objs classes besides Figure , Layout, and TraceType will map to dictionaries. For example

• graph_objs.Marker -> dict

This should be enough to make code like the following example from the Dash users guide work.

figure=go.Figure(
        data=[
            go.Bar(
                x=[...],
                y=[...],
                name='Rest of world',
                marker=go.Marker(
                    color='rgb(55, 83, 109)'
                )
            )
        ],
        layout=go.Layout(
            title='US Export of Plastic Scrap',
            showlegend=True,
            legend=go.Legend(
                x=0,
                y=1.0
            ),
            margin=go.Margin(l=40, r=0, t=40, b=30)
        )
    ),

Note: Nested types (like graph_objs.Marker and graph_objs.Margin above) wouldn't have their properties validated until they are assigned to a top-level trace or the layout.

I just noticed some slightly inconsistent behaviour...

This works:

f = Figure()
f.layout.margin = dict(l=10,r=10,b=10,t=10)

but this doesn't:

f = Figure()
f.layout.hoverlabel.font = dict(family="Verdana")

but this does:

f = Figure()
f.layout.hoverlabel = dict(font = dict(family="Verdana"))

After #3,

• codegen datatypes and validators for the frames object hierarchy
• Add a .frames property to datatypes.Figure
• Add validation logic to make sure that a Figure doesn't have both frames and a widget at the same time.

Currently the datatype.Figure class is a subclass of ipywidgets.DOMWidget. In preparation for integration into plotly.py, and for use in Dash, the widget code should be separated from the base Figure class.

The idea is to create a new FigureWidget class that would be an optional property of datatypes.Figure (e.g. fig.widget). The FigureWidget could be initialized the first time the property is accessed and, after initialization, the widget would be notified of every modification of the Figure object hierarchy.

This has several advantages

• The ipywidget library can become an optional dependency
• No widget code will be active when the library is used outside the notebook (e.g. from Dash)
• Methods that require an active widget (e.g. to_image) can be moved to the widget class to clarify to users when the methods are available.
• Frames and JS-initiated animations are not currently supported because of the complexity of keeping multiple JS views in sync with a single data Python data model. With this refactor, the object hierarchy could support frames (in terms of data validation) even if the widget logic does not. When a widget is initialized we could check to make sure that no frames are present. And, after the widget is initialized we can prevent the assignment of frames.

I love the error messages that come from this library but I find that they're quite buried below the rather uninformative stack trace, as below... I wonder if there's not a way to catch and re-throw the exception a bit higher up in the stack, so as to have the informative text show up earlier? It's not good practice in general to hide stack traces of course, but for an interactive library like this perhaps an exception is in order (no pun intended)...

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-4-7941ea484f21> in <module>()
----> 1 f.add_scatterternary(title='no')

~/plotly/ipyplotly/ipyplotly/datatypes/__init__.py in add_scatterternary(self, visible, showlegend, legendgroup, opacity, name, uid, ids, customdata, selectedpoints, hoverinfo, hoverlabel, stream, a, b, c, sum, mode, text, hovertext, line, connectgaps, cliponaxis, fill, fillcolor, marker, textfont, textposition, selected, unselected, hoveron, subplot, idssrc, customdatasrc, hoverinfosrc, asrc, bsrc, csrc, textsrc, hovertextsrc, textpositionsrc, **kwargs)
   5247             hovertextsrc=hovertextsrc,
   5248             textpositionsrc=textpositionsrc,
-> 5249             **kwargs
   5250         )
   5251         return self.add_traces(new_trace)[0]

~/plotly/ipyplotly/ipyplotly/datatypes/trace/__init__.py in __init__(self, visible, showlegend, legendgroup, opacity, name, uid, ids, customdata, selectedpoints, hoverinfo, hoverlabel, stream, a, b, c, sum, mode, text, hovertext, line, connectgaps, cliponaxis, fill, fillcolor, marker, textfont, textposition, selected, unselected, hoveron, subplot, idssrc, customdatasrc, hoverinfosrc, asrc, bsrc, csrc, textsrc, hovertextsrc, textpositionsrc, **kwargs)
  14934         Scatterternary
  14935         """
> 14936         super().__init__('scatterternary', **kwargs)
  14937 
  14938         # Initialize validators

~/plotly/ipyplotly/ipyplotly/basedatatypes.py in __init__(self, prop_name, **kwargs)
   1829 class BaseTraceType(BaseTraceHierarchyType):
   1830     def __init__(self, prop_name, **kwargs):
-> 1831         super().__init__(prop_name, **kwargs)
   1832 
   1833         self._hover_callbacks = []

~/plotly/ipyplotly/ipyplotly/basedatatypes.py in __init__(self, prop_name, **kwargs)
   1820 
   1821     def __init__(self, prop_name, **kwargs):
-> 1822         super().__init__(prop_name, **kwargs)
   1823 
   1824     def _send_update(self, prop, val):

~/plotly/ipyplotly/ipyplotly/basedatatypes.py in __init__(self, prop_name, **kwargs)
   1389 
   1390         self._prop_name = prop_name
-> 1391         self._raise_on_invalid_property_error(**kwargs)
   1392         self._validators = {}
   1393         self._compound_props = {}

~/plotly/ipyplotly/ipyplotly/basedatatypes.py in _raise_on_invalid_property_error(self, **kwargs)
   1437                                      full_prop_name=full_prop_name,
   1438                                      invalid_str=invalid_str,
-> 1439                                      prop_descriptions=self._prop_descriptions))
   1440 
   1441     @property

ValueError: Invalid property specified for trace.scatterternary: 'title'

    Valid properties:
        visible
            Determines whether or not this trace is visible. If *legendonly*,
            the trace is not drawn, but can appear as a legend item
   ...

Add Figure.extend_traces and Figure.prepend_traces methods that match the semantics of the corresponding Plotly.extendTraces and Plotly.prependTraces functions.

This will allow us to efficiently support streaming use-cases in the notebook. See https://github.com/mrocklin/streamz for example.

We could also consider trace-level convenience methods. e.g.

fig.data[0].extend_props({'x': rand(), 'y': rand(), 'marker.color': rand()})

I started work on adding JupyterLab widget support but ran into various build errors.

Done so far:

• Added jupyterlab entry to js/package.json
• Added js/src/jupyterlab-plugin.js

I don't currently recall the failing build steps that I had tried.