-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should this be a 'pure Python' package? #98
Comments
Could use https://plot.ly/ instead |
There are many alternatives to matplotlib. |
My opinion is that it is good to choose solid dependencies and stick to them throughout the whole project. And I think NumPy is about as solid as they get. |
Matplotlib would be the standard thing I'd suggest to go for for a Python project (even with adding in the 1 liner that transforms plots in to plot.ly plots).
My only query with that is with the entry level to contributing (I know some colleagues who have never installed a packaged or used a cli and if they read that they needed to would just shrug and walk away). Given that we don't need to use Numpy (it's probably saving 4~10 lines of code) I wonder if we should. It could be nice to decide this here (and as you say @langner: stick to it, perhaps write it in the README.md somewhere). I'm in no way adverse to using numpy if we think that's the way to go, I just want to make sure we do it for the right reasons. |
And I am in no way proselytizing NumPy, at least for this project. I just noticed that you had started to use it again in the "core" code, and so simplified some of the more bulky nested lists I encountered. |
Yup, I think that got past me in a PR to be honest. What do you reckon though, do you agree with me that it's nicer to keep it plain Python if possible or do you think that's not worth worrying about? :) |
Well... no, I don't agree that it's nicer. You have a clear case where using numpy arrays is more natural than plain Python. Besides, you already do use it, even if only in So, if I were you I would choose between using numpy everywhere or getting rid of it altogether. |
I think by nicer, I did not mean the code base (I certainly agree with you) but that it's nicer to have a philosophy of "you don't need anything else to make this run".
I know some (fair few actually) for which that would not be true, but perhaps those are not the people who would be able to contribute anyhow (although I have had a student contribute with no knowledge of Python which was cool). If someone is getting this from github they probably can install Numpy...
This is exactly what I'm trying to do. Just want to talk it over that's all :) Ultimately (thinking aloud here) I keep coming back to the fact that Numpy is not doing much here at all. It's a minor convenience I would argue to use it. The numerics are not heavy and we just want to make writing to csv a bit less of a pain. |
So... what is the decision? :) |
Let me just see if @meatballs has anything to add and then I'll make a call. I think it's just important that we set out from now what the guidelines are (as you say) before it takes too long to actually go through and change it 😿 |
Ok, have been watching some reality TV and mulling this over in my head (instead of figuring out who should be voted off for their mediocre singing) and I think I've made a decision. I'd like to keep this base Python:
I don't think Numpy is currently doing enough to warrant losing the 'built in pure Python' tag. @langner and @meatballs: you guys are pretty much the main contributors to this (and I'm so very grateful, this has been such great fun!) so if you think I'm being stupid (or a d**k) let me know. Otherwise I'll open two issues for the above two points to 'de-Numpify' everything (although the second point might be able to be incorporated in to Owen's upcoming PR). |
Having never used numpy or matplotlib before, they are the areas where I start to lose track of what's going on. Issue #88 is a good example. The numpy documentation is good, so there's less of a problem there. It also made the code to pre-populate the scores with zeroes a lot more concise and easier to read. Not sure I care too much either way on this one. I find the matplotlib documentation hard going, but once we have that within a properly tested class of its own, we shouldn't have to touch it too much (and I'll just avoid it)!! So, to conclude, I'm happy with the suggestion above. |
Just realised (possibly slightly too late) that numpy is a dependency of matplotlib - it doesn't make a whole lot of sense to use one but not the other. |
Yes but |
OK |
I have branched and started to write a document about contributing, I'll keep adding to it when I get a moment here and there but just let you guys know in case it's of interest - 3e89576 |
In other words should we try to avoid
numpy
in the couple of places that we use it (it would be relatively straightforward to remove it as a dependancy)?(
matplotlib
is another kettle of fish as there is no alternative)The text was updated successfully, but these errors were encountered: