Skip to content
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

Closed
drvinceknight opened this issue Mar 7, 2015 · 16 comments
Closed

Should this be a 'pure Python' package? #98

drvinceknight opened this issue Mar 7, 2015 · 16 comments

Comments

@drvinceknight
Copy link
Member

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)

@meatballs
Copy link
Member

(matplotlib is another kettle of fish as there is no alternative)

Could use https://plot.ly/ instead

@langner
Copy link
Member

langner commented Mar 7, 2015

There are many alternatives to matplotlib.

@langner
Copy link
Member

langner commented Mar 7, 2015

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.

@drvinceknight
Copy link
Member Author

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 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.

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.

@langner
Copy link
Member

langner commented Mar 7, 2015

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.

@drvinceknight
Copy link
Member Author

And I am in now way proselytizing NumPy, at least for this project. I just noticed that you had started to use it again, 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? :)

@langner
Copy link
Member

langner commented Mar 7, 2015

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 run_tournament.py. If I give some thought to a "new user", that is the first file they will run/open/read. It will take them less time to download and install NumPy that to understand how to use your code independent of run_tournament.py.

So, if I were you I would choose between using numpy everywhere or getting rid of it altogether.

@drvinceknight
Copy link
Member Author

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.

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".

It will take them less time to download and install NumPy that to understand how to use your code independent of run_tournament.py.

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...

So, if I were you I would choose between using numpy everywhere or getting rid of it altogether.

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.

@langner
Copy link
Member

langner commented Mar 7, 2015

So... what is the decision? :)

@drvinceknight
Copy link
Member Author

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 😿

@drvinceknight
Copy link
Member Author

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:

  1. Remove Numpy
  2. Include an exception catcher for matplotlib (used to be in a script so wasn't a big deal but @meatballs is doing some cool stuff to get it in the library itself). So if someone tries to plot but doesn't have matplotlib they get a message saying 'woops no matplotlib... type pip bla bla bla' .

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).

@meatballs
Copy link
Member

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.

@meatballs
Copy link
Member

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.

@drvinceknight
Copy link
Member Author

Yes but matplotlib is being caught be the exception, so I think it make sense to not have numpy actually used specifically for anything: so someone could use this and code for it using just basic Python (they wouldn't be able to plot though).

@meatballs
Copy link
Member

OK

@drvinceknight
Copy link
Member Author

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

marcharper pushed a commit to marcharper/Axelrod that referenced this issue Nov 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants