force facecolor to be an array, NOT a list

[Kully]

Testing if Python 2 and Python 3 are in agreement between the facecolor numpy.arrays

[Kully]

@theengineear @choldgraf I'm trying to see if the tests fail because of a difference in np.array/list facecolor. I just got a test failure but I think it was for something unrelated, so I'm rebuilding...

[Kully]

Okay, a success it looks like. Shall we merge @theengineear ?

[theengineear]

Sure! 💃 Not sure how efficient the np.asarray call is, but I'm guessing it's an improvement?

[Kully]

Sure! 💃 Not sure how efficient the np.asarray call is, but I'm guessing it's an improvement?

It was there before iirc.

[choldgraf]

Hey all - thanks for being on top of this! I've got a couple deadlines this/next week and heading out of the country today, so I'm a little slow on the uptake right now.

As a general rule, I think we can treat 1-D arrays almost exactly like lists, with the exception of some methods that lists have that arrays don't (most notably, append). Other than that, my guess is that we can safely use arrays. Even in cases where an array isn't explicitly needed, I think just using them in general will encourage better computational practices (e.g., vectorizing operations with arrays instead of looping through lists).

Thanks a bunch of pushing this through!

[theengineear]

@choldgraf sounds good. I know that we didn't originally want to require numpy to use plotly. I think we should be a little careful about where we use arrays, fwiw. I don't think we want to require numpy as a dep for plotly.

@chriddyp am I off here? I'm guessing we're still against numpy as a dep, right?

EDIT: For example, we can't pull color functions that use numpy into our core plotly functionality.

[choldgraf]

really? what's the reason for not having dependency on numpy? in the space of data analysis it's pretty much the only standard way to represent numerical data in memory. Do you have users that want to do data viz in python, but that don't use numpy?

I think that not using numpy (or a package similar to it) does encourage poor efficiency. E.g., the improvements I initially made to trisurf were just wrapping things in numpy arrays and then doing the same calculations with those, and it was like 2 orders of magnitude improvement in speed. It's probably not a big deal if your users only ever have tiny amounts of data, but for anything non-trivial in size I think you get big benefits.

[theengineear]

I think it was mostly a slippery slope concept. If you let one big package be a dep, then another, then another... pretty soon it might take a loong time to get a new user to install plotly and get up and running.

I'm assuming the APIs for interacting with a list and an array are basically the same. I wonder if we could just use a custom Array or something that is either list or array based on whether numpy can be imported?

I'm, at once, in support of no strictly unnecessary deps and efficiency. I feel like with a little extra thought, we might be able to manage both?

[choldgraf]

hey all - sorry for the slow response. I'm trying to get a bunch of work done before a trip to Vietnam next week (!!!!).

re: slippery slope, I totally agree that this is a good mentality to have. At the same time I feel like at this point numpy is pervasive enough that it's practically a part of the core python language (for anybody that's doing any kind of data analysis or visualization, anyway). If numpy made any big API changes etc, I think it'd disrupt the field of data usage in python just as much as the python switch from 2 -> 3 did. :P

But either way, I do understand the mentality :)

[theengineear]

trip to Vietnam

!!! Hope it's amazing!

OK, lemme give it a thought. numpy seems like a pretty obvious choice to bring in. I might play around with it this weekend and get back to ya!

[choldgraf]

Sounds good - it might be worth talking to somebody like @fperez for advice on dependencies w/ the scientific python stack. He usually has good insights about this sort of thing.