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

General python support #145

Merged
merged 8 commits into from
Jun 29, 2018

Conversation

VikingScientist
Copy link
Contributor

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.

This was referenced Jun 28, 2018
@Butt4cak3 Butt4cak3 added Implementation This provides an implementation for an algorithm. (Code and maybe md files are edited.) Implementation Edit This provides an edit to an algorithm implementation. (Code and maybe md files are edited.) labels Jun 28, 2018
@leios
Copy link
Member

leios commented Jun 28, 2018

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.

@jiegillet
Copy link
Member

I think the consensus is that we don't want to have a compromise on versions. Getting rid of py2 and py3 and use py is great, but I don't think we want to include from __future__ import print_function at all. People who want to use python 3 code using python 2 should add that themselves.

@@ -89,7 +89,7 @@ Program.cs
[import, lang="javascript"](code/javascript/euclidean_example.js)
{% sample lang="py2" %}
Copy link
Member

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" %}
Copy link
Member

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" %}
Copy link
Member

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)

@leios
Copy link
Member

leios commented Jun 29, 2018

As a quick note the py label should be defined in the book.json file in the root directory. this will make sure that all py labels will have the correct tag at the top of the screen ("Python" instead of "Python 2" or "Python 3"). I can do this and submit a PR to your branch @VikingScientist , or you can change

                                {
                                        "lang": "py2",
                                        "name": "Python 2"
                                },
                                {
                                        "lang": "py3",
                                        "name": "Python 3"
                                },

to

                                {
                                        "lang": "py2",
                                        "name": "Python 2"
                                },
                                {
                                        "lang": "py3",
                                        "name": "Python 3"
                                },
                                {
                                        "lang": "py",
                                        "name": "Python"
                                },

and then just check to make sure the language is correct and syntax highlighting is right by running gitbook serve. I figure we should leave py2 and py3 in there for now and get rid of them once everything's updated.

Note: Indentation was from file.

@jiegillet
Copy link
Member

jiegillet commented Jun 29, 2018

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

@leios
Copy link
Member

leios commented Jun 29, 2018

@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?

@jiegillet
Copy link
Member

No I mean in the book. The topic is bound to come up. It should be stated somewhere, maybe?

@leios
Copy link
Member

leios commented Jun 29, 2018

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?

@jiegillet
Copy link
Member

jiegillet commented Jun 29, 2018

No #141 is the right place to discuss that. Here is not though, so let's get back to code reviewing, sorry @VikingScientist

@VikingScientist
Copy link
Contributor Author

VikingScientist commented Jun 29, 2018

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 book.json as well as fixing the last python-code in the FFT. After this, all version-specific code is gone, so I'll remove py2 and py3 from book.json.

Edit: just have to get this gitbook-things installed and running so I can verify that it all works locally.

@jiegillet
Copy link
Member

Coolz. Ping me when you feel it's ready for a merge.

@leios
Copy link
Member

leios commented Jun 29, 2018

Oh yeah, if this PR removes all version specific stuff from the whole book, it should be fine to remove py2 and py3. I just thought there were more python implementations hiding somewhere.

@VikingScientist
Copy link
Contributor Author

I did grep for any mention of py2 or py3, but can't find any trace of it anymore.

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 git rebase -i HEAD~6 --autosquash and then it's ready to be merged.

@Butt4cak3
Copy link
Contributor

We always squash and merge PRs (through the GH interface) anyway. There's no need to manually squash. But thanks for the consideration!

@VikingScientist
Copy link
Contributor Author

Rebased to resolve some merge conflicts. Ready to be looked at @jiegillet

@leios
Copy link
Member

leios commented Jun 29, 2018

Great!, so once this is merged, we can have a look at the python 3 implementations #146 #144 #138 , all of which should have modifications in their markdown files.

I am mentioning this now so we remember on those later.

Copy link
Contributor

@Butt4cak3 Butt4cak3 left a 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.

@Butt4cak3 Butt4cak3 merged commit 908e7b6 into algorithm-archivists:master Jun 29, 2018
@VikingScientist VikingScientist deleted the MorePython branch June 29, 2018 14:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Implementation Edit This provides an edit to an algorithm implementation. (Code and maybe md files are edited.) Implementation This provides an implementation for an algorithm. (Code and maybe md files are edited.)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants