-
-
Notifications
You must be signed in to change notification settings - Fork 360
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
General python support #145
General python support #145
Conversation
Thanks for the PR. Quick question, since we have decided to get rid of Python 2 in #141 , is this code immediately mergable, or is it just an example of how we can make the code version agnostic? EDIT: I have just been told I was incorrect about what this PR does, It corrects python 2 code to work with python3 syntax, right? So this PR might go away if we get rid of Python 2. |
I think the consensus is that we don't want to have a compromise on versions. Getting rid of |
@@ -89,7 +89,7 @@ Program.cs | |||
[import, lang="javascript"](code/javascript/euclidean_example.js) | |||
{% sample lang="py2" %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You missed a py2 here
@@ -41,7 +39,7 @@ Because of this, the most straightforward way to traverse the tree might be recu | |||
{% sample lang="js" %} | |||
[import:15-23, lang:"javascript"](code/javascript/Tree_example.js) | |||
{% sample lang="py2" %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
py 2 here
@@ -41,7 +39,7 @@ Because of this, the most straightforward way to traverse the tree might be recu | |||
{% sample lang="js" %} | |||
[import:15-23, lang:"javascript"](code/javascript/Tree_example.js) | |||
{% sample lang="py2" %} | |||
[import:8-16, lang:"python"](code/python2/Tree_example.py) | |||
[import:7-15, lang:"python"](code/python/Tree_example.py) | |||
{% sample lang="py3" %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
py3 here (although there is no code)
As a quick note the
to
and then just check to make sure the language is correct and syntax highlighting is right by running Note: Indentation was from file. |
@leios is there a place we could mention explicitly our stance on python version? EDIT: Wait, can I edit other people's comments? That's amazing. |
@jiegillet I think I we already did in #141. Maybe we should make language-specific style guides and mention it in there? EDIT: How do you feel when I edit YOUR comments, mister? |
No I mean in the book. The topic is bound to come up. It should be stated somewhere, maybe? |
Yeah, that's what I meant too. We should add some style guidelines to the How to Contribute section and for python, we just say that we are sticking to python 3 for this. I am not sure where else to put it, but @julianschacher was mentioning he wanted to create a How to Contribute guide... So that would be a good place too. Maybe we should move this to a separate issue? |
No #141 is the right place to discuss that. Here is not though, so let's get back to code reviewing, sorry @VikingScientist |
Hehe. This is fine. I initiated the discussion, and if it is discussed here or in #141 really doesn't bother me. I agree with @leios though: we should put the "python 3 only"-stance somewhere (i.e. in the How to contribute section) so that it is available for new contributers. The issue tracker will fade; in fact auto-close after this PR is merged, so it's not a good long-term documentation. There's a few upcoming commits more where I make the requested changes to Edit: just have to get this gitbook-things installed and running so I can verify that it all works locally. |
Coolz. Ping me when you feel it's ready for a merge. |
Oh yeah, if this PR removes all version specific stuff from the whole book, it should be fine to remove |
I did I like fixup commits such as 2356130 as it makes the reviewers life easier, but I want these to be squashed with it's referencing commit before being merged into trunk. So if I get a thumbs up on this so far then I'll run |
We always squash and merge PRs (through the GH interface) anyway. There's no need to manually squash. But thanks for the consideration! |
2356130
to
777c512
Compare
Rebased to resolve some merge conflicts. Ready to be looked at @jiegillet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's it! I'm pretty sure I checked everything, so let's merge this and get going with the other Python PRs.
In awaiting the conclusion from #141, I tried to show how a general version-agnostic approach could look. In practice, you only need to add the line
from __future__ import print_function
to all python files and they will in 99% of the times work for both versions. At least when considering small algorithms such as this project here and not huge complex interconnected libraries that have lots of dependencies.