## [Matplotlib-users] to zip or not to zip - that is the question

 [Matplotlib-users] to zip or not to zip - that is the question From: Simson Garfinkel - 2009-03-02 03:14:04 ```In working on code for matplotlib, I would generally find it easier to provide an array of objects than to provide an array of X values and a second array of Y values. I understand that X[] and Y[] is the way that matlab does it, but we would find it easier to provide an array of either tuples [(x1,y1), (x2,y2), ...] or else an array of objects with .x and .y properties. Other than doing our own cover, is there any other way to do this? Any thoughts of adding this functionality? -Simson ```

 [Matplotlib-users] to zip or not to zip - that is the question From: Simson Garfinkel - 2009-03-02 03:14:04 ```In working on code for matplotlib, I would generally find it easier to provide an array of objects than to provide an array of X values and a second array of Y values. I understand that X[] and Y[] is the way that matlab does it, but we would find it easier to provide an array of either tuples [(x1,y1), (x2,y2), ...] or else an array of objects with .x and .y properties. Other than doing our own cover, is there any other way to do this? Any thoughts of adding this functionality? -Simson ```
 Re: [Matplotlib-users] to zip or not to zip - that is the question From: Eric Firing - 2009-03-02 04:37:34 ```Simson Garfinkel wrote: > In working on code for matplotlib, I would generally find it easier to > provide an array of objects than to provide an array of X values and a > second array of Y values. I understand that X[] and Y[] is the way > that matlab does it, but we would find it easier to provide an array > of either tuples [(x1,y1), (x2,y2), ...] or else an array of objects > with .x and .y properties. > > Other than doing our own cover, is there any other way to do this? Any > thoughts of adding this functionality? Internally, we often do end up using Nx2 ndarrays. I don't think it makes sense to complicate the API by directly supporting other function signatures, however, if this is what you are proposing. For example, we have plot(y) and plot(x,y); to support either of the alternatives you mention above would require either a kwarg or a different function name. Personally, I would rather leave it to the user to take care of this as needed, and keep the additional complexity out of matplotlib. Eric > > -Simson > ```