-
-
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
Should we have seperate python2 and python3 codes? #141
Comments
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. |
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. |
Yeah I agree, we should use Python 3 only |
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 In the off-chance that the single |
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. |
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 timesPython 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 enoughEvery 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 libraryIt'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 importantAs 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. SummaryThe 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. |
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. |
The consensus seems to be "Drop Python |
@Butt4cak3 You meant "Drop Python 2", right? ;-) |
@HugoGranstrom Of course. Thanks for pointing that out. |
@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? |
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. |
I created an FAQ entry for that topic. The first one btw :D |
The current state of python code:
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 theprint
-statement that is going to be the most obvious problem to combine, but this very neatly fixed by including the following code at the startwhich 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__
libraryThe text was updated successfully, but these errors were encountered: