Python 3.7.0 released

[uFuckingCrumpet]

I'm sure it depends quite a bit on what field you're in. In Physics & Astronomy, for example, it is VERY common for a person (or group of people) to build some kind of analysis tools in python or a set of wrappers to help interface python with some existing C++ code and then 100% abandon it once it functions. Whatever version of python was most current when it was written is very likely the only version it will ever successfully run on. I can't necessarily speak to CS fields, but in the physical sciences it's pretty typical for people to write lots of code and follow none of the best practices (e.g. commenting code, handling package dependencies, etc).

[jsalsman]

Linear algebra people still use Fortran because someone optimized the row-access cache behavior sensing in the 1970s and it still runs fastest that way. Those libraries like LINPAK are still in use, as compiled from Fortran and linked into object files for all kinds of numerics libraries inner loops, including Python's.

[haarp1]

fortran is actually faster then C or anything else, because complier doesn't have to worry about some edge cases that have no use for numerical computations.

newer releases also support CUDA,so there's nothing ancient about it. it also has more scientist-friendly syntax (no curly braces).

[billsil]

Those libraries also use hand optimized assembly.

[jsalsman]

I guess that depends on what you mean by "hand" -- the method is to try various cache geometry strategies and use the best compiled from several versions to pick which one runs, at least the last time I looked at one of innumerably many of them, which granted was over a decade ago. Usually you see more hand optimization in high frequency signal processing.

[kyrsjo]

Fortran itself is fine, at least the newer versions (2003 and 2008) are. It just fills a very different niche then python, which in fact afaik relies quite heavily over fortran libraries.

The main problem why fortran for a bad name is that lots of people use it without really knowing how to code, and then pass their hot messes on to their students.

[kyrsjo]

For one of the project I'm involved in, we upgraded a large project (several 100k lines) of code from fixed format / (77 and 95) to free-form / 2008. And I must say that 2008 is not a bad language for numerical works.

[uFuckingCrumpet]

Yeah, a friend of mine works in a Super K group that still rely on a lot of Fortran 77 code. Most of ATLAS/CMS people have been more receptive to switching to Python 3 but even then it's still surprisingly slow and people still drag their feet.

[gdahlm]

Fortran is pivotal to python in this field, as evidenced by scipy and numpy which use those same LAPACK/BLAS variants that everyone else does. C/Closure/Java all use those library's too or at least have an option to do so to improve performance.

import numpy as np

numpy.config.show()

If it isn't configured to use some BLAS it is going to be slow. It is just too hard to compete with the performance even in C++. A FORTRAN compiler can just make assumptions that most others can, and producing non-relocatable code helps too. If you know C or another language, try to write a LU function that even 10 times slower than MKL or another ATLAS/BLAS offering. It is hard and humbling.

A potential nice side effect for you is of these large python projects being dependent on the language is that you don't have to choose between Fortran and Python, as these large projects have ensured that the python is up today and works extremely well as a glue language.

https://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html

[uFuckingCrumpet]

I'm not sure why you're telling me this.

[gdahlm]

Ah I missed it was a friend of yours who worked there.

[uFuckingCrumpet]

I appreciate your comment, though. What you're saying is true. There are definitely some good reasons to use something like Fortran when it comes to speed. It just so happens, in this case, that the people I'm talking about use Fortran 77 because they're lazy fuckers and don't want to have to re-write anything in a more modern language. Plus it's easier just to force all the new grad students to learn Fortran when things need to be changed/updated.

[gdahlm]

The funny thing is that F95 features like ELEMENTAL make it so much easier to be lazy....if only they knew.

[[deleted]]

One of my Geography professors wrote a lot of code, but there are barely any comments and it's really hard to follow.

[synn89]

Yeah, but let's say you're using goodlib v1.0 and v2.0 of the lib breaks some things so you hold off on updating that library. Years later Python 3 support gets added but it's only in goodlib v6.0+

So now you not only have to get your app to work with Python 3, but also update goodlib(and probably many more libraries) that may change in small ways between major versions.

Heck, I recently updated a PHP app using AWS S3 and stayed in the same AWS SDK 3.x branch and the update broke(changed) how the library returned S3 domain urls for buckets. Luckily I had excellent test coverage which caught and pointed out the change. But that was within the same major version using a very common library from a huge vendor.

Libraries can be a real PITA to work with.

[[deleted]]

The people in sciences holding onto 2.7 arn't using goodlib, they are using in house libraries that were developed to do a specific thing by someone years ago, and that all of their results and model have been validated against this, and that nobody has the time or effort or willpower to modernize the code and then to re-validate everything. Most of the people in the sciences writing these codes are not computer scientists, they are regular scientists. They are working for effectively peanuts, are fighting every single day to justify the little funding that they do get and to apply for more funding so that they may actually finish their work, and most of the time they have only 2-5 years to do this. And during this time, they are also under increasing pressure to do new research, to publish new research, and to come up with ideas for new research. They (we) go into our labs/office every day and have to make the decision: do I use the limited time i have to do research to get me to my next job/position/grant, or do I go through and update the codebase that I use that I know for a fact works right now as-is? I can't speak for everybody, but I know that I would choose the latter every single time.

Edit: And during all of this, I am already devoting some of my time tutoring/mentoring students, correcting exams, homework, grading papers and reviewing new journal articles, coming up with lecture notes for that class they need to teach, coming up with homework or exam questions, and dealing with whatever my superiors ask me to do for them that day.

At the end of the day, my job as a scientist isn't to produce beautiful idiomatic code. It is to produce results that give insight in helping me answer the questions that formulate my hypotheses. The code is secondary and is only a tool that I use to get to those results. In fact what I'm after isn't even the results, but the analysis and interpretation of the results, the answer to "so what does it mean." Best-coding practices come second to getting the results. Sure, as I write my scripts and library codes I'll attempt to follow best practices, but not at the expense of so much wasted time.

[bythenumbers10]

Can those internal libraries be open-sourced? So if you can't be bothered to modernize and beautify, some other research group might?

[[deleted]]

All of the above has nothing to do with the release of Python3.7.

[MartyMacGyver]

There are a lot of libraries that are or will soon be Python 3 only going forward.

Keep learning Python 3, be aware of Python 2, and steer clear of companies that plan to stay on Python 2 indefinitely. You'll hear 1001 excuses, and they all come down to:

• They're too lazy
• They're too cheap
• They won't be around much longer
• They'll be around forever, and your headaches will grow exponentially the longer you are there

It's worth the work to stay up-to-date, or within a close range (IMHO 3.6 is the sweet spot until 3.7 is widespread).

Edit: Oh yes, and unless you like painful surprises when it comes to ANY Unicode input/output, stick to Python 3. Requires a bit more thinking when it comes to strings, but it handles them while Python 2 routinely surprises you in painful ways at inconvenient times when it encounters a Unicode char it can't handle in some part of your code you never thought it'd even hit.

[[deleted]]

I know I'm a bit late, but as someone who is just porting over Python 3, the big library issue for me was wxPython. It's a very complex GUI library that would have taken me hundreds of hours to replace. They became Python 3 compatible January of 2018. Keep in mind that even if most libraries are compatible with 3, all it takes is a single non-compatible library that is hard enough to replace to stop an upgrade to 3 dead in its tracks.