Should we have seperate python2 and python3 codes?

[VikingScientist]

The current state of python code:

• Tree Traversal (python2 and unfinished python3)
• Euclidean Algorithm (python2)
• Bubble Sort (python3, but unlisted)
• FFT (python2)

My question is if we really need to split the code into separate implementations for python2 and python3. It would probably be a much better design to just have a python implementation, and write it so it runs on both versions. For practical purposes this means that it is the print-statement that is going to be the most obvious problem to combine, but this very neatly fixed by including the following code at the start

from __future__ import print_function

which allows python2 to write print('Hello World'). The second most obvious difference is that the division operator / is interpreted as integer-division in python2 while always floating point division in python3. Again: we can write compatible code by including the __future__ library

from __future__ import division

[Butt4cak3]

I would honestly not have a problem with going for Python 3 completely. As far as I know, unless you're working with legacy code, there is not much reason to use Python 2 at all. Let's hear some more opinions.

[jiegillet]

Honestly, my opinion on this is: dump Python 2 altogether. It's retiring anyway. There is so little difference, any beginner should start learning Python 3 and we should encourage that.

[zsparal]

Yeah I agree, we should use Python 3 only

[VikingScientist]

I think a sensible solution would be to pretend that there are no python versions. At least project this to the outside audience. We write "python" and never "python 2" or "python 3". This means that it will stand the test of time, in that it makes sense after 2020 when py2 is discontinued. All python files should start with from __future__ import print_function which means that almost everything should work for both versions. Anyone which have either version installed will have no problems running the examples and it is very non-intrusive.

In the off-chance that the single import statement does not suffice in making the code python2/python3 compatible (no such codes as of yet), then we take the stance that we only support the python3 version, but there is still no need to cumber any reader with the distinction as we continue to just write "python" when we talk about it.

[HugoGranstrom]

I think @VikingScientist has a good compromise for the time being. We write python3 code but add the import statement at the top and if it breaks on Python2, sad for them.

[Butt4cak3]

I thought about this one and I now strongly support the decision to just drop Python 2 altogether and go with Python 3 without added compatibility for Python 2. Here is why.

Get with the times

Python 2 support will be dropped soon-ish. There is no reason to keep it around unless you're dealing with legacy code. Beginners should learn Python 3 right away and we, as a learning resource, should encourage that.

Python 2 and 3 are similar enough

Every Python 2 developer will be able to read and understand our Python 3 code. If you can run Python 2 code on your machine, you can get Python 3 to work just as well, either by installing it or by porting it yourself. If you want to use an algorithm in your Python 2 application, you should rewrite it anyway (or use a third-party library), as explained in the next section.

The Algorithm Archive is not a library

It's a learning resource. While we do try to adhere to style guides and best practices and make sure our examples compile and run, you're not supposed to directly copy and use the examples in production code anyway. That is also why there's no reason to make it compatible with both versions. You are supposed to rewrite it if you're going to use it in your project. Or better yet: Use an existing third-party library.

Clarity and simplicity are very important

As I mentioned before, the Algorithm Archive is a learning resource. The code examples should be easy to read and understand. Adding some kind of compatibility layer to support multiple versions of an interpreter takes away from that, even if only slightly. I don't think it's a good trade-off for the reasons I outlined above.

In addition to that, when we start to make all our Python code compatible with both versions, we will have to require all future contributions to also be compatible with both versions and that opens a whole other can of worms. It will raise the barrier of entry for new contributors (we value this aspect of the project very highly) and cause trouble once we're getting into territory in which it's not trivial to make the code compatible.

Summary

The code examples are not production code. They should stay clean, simple and follow best practices. Nobody will have a problem with the fact that there's only a Python 3 implementation for a certain algorithm. We could make it happen, but I don't think it's worth it.

[leios]

Agreed, we can kick Python 2 out.

In my head, it made sense to have a Python 2 and a Python 3 at some time, but that was partially because we had two very different python submissions for the same algorithm and I wasn't sure which would be more "proper." To be fair, this came at a time before we had code reviews and such, so it wasn't a decision I really asked the community about beforehand.

[Butt4cak3]

The consensus seems to be "Drop Python 3 2". Let's do it as always and keep the issue open for another day or two to give people a chance to voice their opinions. However, we should get done with this very soon because all of the current Python PRs depend on it.

[HugoGranstrom]

@Butt4cak3 You meant "Drop Python 2", right? ;-)

[Butt4cak3]

@HugoGranstrom Of course. Thanks for pointing that out.

[june128]

@Butt4cak3 s arguments make sense. I think it's a good move to push Python 3 and simplify things.

How would we go about keeping the existing Python 2 implementations? Are we going to remove them from the book or are we just going to hold on to them for now?

[Butt4cak3]

Good question. I'd say port them to Python 3 if there's currently no Python 3 implementation for a given algorithm, overwise remove them.