Python 3 support in master about medpy

[loli]

I refrained from this step, since I didn't had the time to thoroughly check if the Python3 is error-free. Do you use that branch? If yes, did you encounter any errors till now?

[cancan101]

I am using it, though only touching a subset of the code.

[cancan101]

I am looking over the diff and here are some thoughts. I assume you want to keep some python 2.x support:

• I think you will lose Python 2.5 support (maybe ok?)
• you might want to be explicit here, I don't think that is correct as written in python 3
• not sure what happened here
• import print function in this file and this one and this one
• maybe try catch this import and here

[loli]

1. That is fine.
2. Well spotted. Should use integer division //, which is also supported by 2.7.
3. Good question. I'll have to look into this.
4. Yes, here and in many more scripts.
5. Actually, this could stay like it is. First, I used cPickle simply for performance reasons. And second, all script in bin/ sub-folder are not actually part of the shipped version of medpy.

PS: Would you mind if I assign you as collaborator to medpy? Might facilitate things.

[cancan101]

sure, sounds good

[cancan101]

For 3, TIL: https://stackoverflow.com/questions/34916569/python-nested-parenthesis-function-parameter-list-invalid-syntax. Looks like Python 2 supported param unwrapping whereas python3 does not.

I started cleaning up some of the code: #57

[loli]

Perfect, Thanks for all the valuable input already! And please don't mess up the code ;)

Regarding point 3: This is unfortunate, since it means the required parameters can't be conveniently named and thus described in the doc-string. But well, it's not a big drawback. I would suggest renaming all occurrences of xxx_todo_changeme to boundary_term_args respectively regional_term_args, leave the unwrapping to the function body and adapt the function documentation accordingly.

[cancan101]

@loli I would like to understand better how you were using parameter unwrapping. What do you mean about "required parameters can't be conveniently named"?

[loli]

The Graph Cut module provides a convenience wrapper for N-D image segmentation cuts. In these arbitrary boundary and regional terms can be plugged in. Some of the more common I provide. As each of these requires other parameters, these are designated by the additional terms (a list of required arguments). The wrapper than requires the chosen boundary and/or regional terms as well as the variables it should pass to them.

For the user to know which information to pass, I chose parameter unwrapping, thus the names denote the required information. If these are condensed into a single argument named e.g. additional_args, the user wouldn't intuitively know which information is required for the used boundary/regional term.

Sorry, I'm on vacation and just have my mobile with me right now. It's difficult to give an example. You can perform the merge and I'll fix the issue when I'm back.

Great work!

[cancan101]

done in: #60