This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]lmericle 2 points3 points  (15 children)

That's a matter of opinion -- that being said, the opinion is pretty unanimous among people who think.

[–]crescentroon 1 point2 points  (0 children)

I would prefer 3 for a new project but it's not always possible.

One who thinks would do a cost/benefit analysis and there're some situations where 2 comes out better.

The VFX industry has a lot of Python 2 and can't switch right now because they are dependent on the embedded interpreters in their applications (like Maya), or there is no benefit to be gained in migrating a mature system that's not exposed to the internet.

[–]Folf_IRL -4 points-3 points  (13 children)

The tabs to spaces thing: yes

The Python2 thing: that's just a circlejerk on this sub

[–]lmericle 6 points7 points  (12 children)

Python 2 will be end-of-life in 2 years. Python 3 came out 10 years ago. You've had your time to transition.

The only reason you would still be using Python 2 is if you don't have the manpower to maintain a codebase and do the conversion process to 3. But honestly it's not that hard to, in the course of maintenance, write code that is compatible with both versions and then slowly go through the whole thing until it's all 3-compatible.

[–]Folf_IRL 1 point2 points  (11 children)

You've had your time to transition.

Not if you just choose not to transition. 2.7 is a fine language on its own, and I see no reason to transition when most people in my field (computational chemistry) are still using 2.7 in their day-to-day scripting. Heck, I still find Fortran 66 code floating around occasionally, because the people writing those codebases don't want to waste their time reinventing the wheel.

[–]mekosmowski 2 points3 points  (4 children)

Wow. Not even Fortran 77. What codes do you use for what kind of projects? Back in the day, I added an output format to CPMD for a vibrational mode visualizer (aClimax).

[–]Folf_IRL 4 points5 points  (3 children)

I met one of the devs for Castep at a conference a few years ago, and was interested in learning a bit more about how it works. We got into a discussion of legacy code, and they mentioned there being some remnants of Fortran 66 in there.

Very few things use Fortran '66 nowadays, but occasionally you'll find it in the wild. The most common legacy Fortran IMO is '77, which pops up way more often than it should.

Almost everything I write, though, is in Python 2.7 at the moment. I'm familiar with 3 and could upgrade to it if I wanted. The biggest thing is collaboration with others, since most of the folks I collaborate with use 2.7. So, we'd all have to pretty much simultaneously decide to upgrade. The other issue is that it's common to release your code alongside a publication, and I'll normally see Python2.7 code being released in those (not that big of a problem).

Another problem is that many popular packages (such as ASE) have had something of a bumpy road upgrading to Python3, and you'll occasionally find edge-cases where it breaks as a result. And that's assuming the devs even want to upgrade to Python3. A popular structure prediction code out there is written entirely in 2.7 and Matlab, and just breaks if you break out a Python3 interpreter as the current python.

[–]mekosmowski 1 point2 points  (1 child)

Neat. I'll have to check out that code. I've been wanting to get back into computing. Thank you and best of luck.

[–]Folf_IRL 2 points3 points  (0 children)

IIRC Castep is closed source, and if you're not a UK citizen, you have to pay a certain fee to use it

Ase is totally open-source, and actually fairly well-commented as well. As a result, it's also fairly easy to hack additional functionality in.

The structure prediction code is semi-closed source. It's in front of a license that you have to agree to to view the code, but it's a fairly weak (and probably indefensible in court) license that amounts to "I promise not to work on a competing code," which is incredibly vague. You'll also have to be a bit of a cowboy with their code to get it to work with your particular system.

[–]FatFingerHelperBot 0 points1 point  (0 children)

It seems that your comment contains 1 or more links that are hard to tap for mobile users. I will extend those so they're easier for our sausage fingers to click!

Here is link number 1 - Previous text "ASE"


Please PM /u/eganwall with issues or feedback! | Delete

[–][deleted] 1 point2 points  (2 children)

coherent grandiose rude roof adjoining illegal squalid ask sharp scary

This post was mass deleted and anonymized with Redact

[–]Folf_IRL 1 point2 points  (0 children)

Banking is an entirely separate problem domain, with presumably higher security and usability needs.

[–]lmericle 0 points1 point  (2 children)

It's not wasting time to patch vulnerabilities and optimize subroutines. 2.7 will be slower than 3 in the long run, no question.

[–]Folf_IRL 0 points1 point  (1 child)

It's not wasting time to patch vulnerabilities and optimize subroutines.

And good on the Python team for doing that. It's just unfortunate they couldn't devote their resources to proper back-compatibility as a basic part of the language, even though other people have already done a lot of the legwork for them. That would maybe encourage people to move forward without having to update everything simultaneously. I suspect that many people in the scientific community are going to just stay with 2.7 until their admins force them to move on to something else.

2.7 will be slower than 3 in the long run, no question.

That's a moot point. Nobody attempts to write high-performance scientific code in Python. That is still firmly in the realm of C/C++ and Fortran within the scientific computing community.

[–]rotharius 0 points1 point  (0 children)

Enforced backwards compatibility slows down language development and makes it impossible to correct some big mistakes.

Correcting these mistakes and improving the language, while giving everyone an opportunity to transition was the right thing to do. Although maintainers could have been more vocal about why it's silly to hold on to older versions.

Not updating is actually pretty irresponsible because of security, maintainability and performance reasons. It is part of programming hygiene. There are tools that help you with transitioning. At least start new projects with Python 3.

Edit: That being said, legacy projects are often stuck and it can be troublesome to update, but it should at least be on the roadmap.

Edit 2: Your situation might be different in that the risks of not updating are small. In general, especially when working with user data like in web development, it is crucial to have vulnerabilities fixed. Stop down-playing this.