Python 2 or 3?
- Thread starter robject
- Start date
bobblanchett
SOC-4
It's time to move on.
Py2 is getting buried in 2020 according to GVR/BDFL..
There's so much goodness in the recent releases, particularly in the collection classes and new dicts in 3.4/3.6, that I said goodbye to py2 last year.
Embrace it, and numpy arrays!
It's sad to say goodbye to a friend.
I switched from procmail to maildrop last week. Oh the feels.. procmail taught me regexes back in the 90s..
Py2 is getting buried in 2020 according to GVR/BDFL..
There's so much goodness in the recent releases, particularly in the collection classes and new dicts in 3.4/3.6, that I said goodbye to py2 last year.
Embrace it, and numpy arrays!
It's sad to say goodbye to a friend.
I switched from procmail to maildrop last week. Oh the feels.. procmail taught me regexes back in the 90s..
Last edited:
That doesn't mean much. It'll continue to build, and be build, and likely even ported to the modern OSes as time goes one, for quite some time.
There's no doubt a bunch of legacy code that no one is going to bother changing if they don't have to.
ShawnDriscoll
SOC-14 1K
If people are willing to freeze their C compilers as well, and not move on.
Well...
Check out: https://github.com/python-cmd2/cmd2/blob/python2/docs/install.rst
That's an older branch of cmd2 that's supposed to run with Python 2.7. Give it a shot and when you install, save the output so folks can advise on it.
Also, life has given me a few ups and downs lately. Of the "Start planning your exit strategy" type. I love Ruby but the market share is really low. Go is cool but I can produce more and faster with Python. My answer to your "Python 2 or 3" question is "yes!". The OS uses Python 2.6 but I'll install 2.7 and 3.whatever shortly.
That sets me up for good stuff and I can test some of the code you all produce. You are writing tests, yes?
That sets me up for good stuff and I can test some of the code you all produce. You are writing tests, yes?
ShawnDriscoll
SOC-14 1K
That sets me up for good stuff and I can test some of the code you all produce. You are writing tests, yes?
Ha! My stuff is all beta. So beta testing is the norm.
Funny, I just grabbed 2.0.1, from June of 2001.
And it built just fine on a brand new, Centos 7 box, with all the latest mcgreatest C-Compilers and what not.
"make test" passed, save for 1 error about a number being too large.
Enough to disqualify the entire installation? Considering the 112 other tests that passed (not including several that were skipped due to missing/optional libraries), I think for the vast majority of use cases, it's a solid enough implementation.
From out of the box, 17 year old source code.
I also built 1.5.2. It had a conflict with "getline". There were 4 references, so I renamed it to get_line (which is what they had in 2.0.1), then it built fine.
Still had the same number error.
That's from 1999.
So, yea, I wouldn't worry too much about 2.7 being "end of life". It'll probably build for another 10-20 years on a modern Linux box.
And, of course, there is still the pretty large professional investment in 2.7 that will help keep it alive, even if Guido gives up on it.
Enough to maintain an RPM? Who knows. Probably.
ShawnDriscoll
SOC-14 1K
With Linux, some will keep using 2.7 for awhile still. Because Linux.
2.6.6 is the base install for RHEL/CentOS 6. Like my desktop.
Spent part of the day watching 2.7 choke; didn't even install pip. Python 3.6.5 did but had other issues.
Took me a bit to see a personal failure, I was off course. Python is good, don't get me wrong. So is Go and even Tcl has great merit. But as soon as I moved away from Ruby my actual code production plummeted. I "should" write C or Python. Should doesn't put characters on the screen; "want to" does.
ShawnDriscoll
SOC-14 1K
I use Windows. So as long as my version of Python is still able to run on it, I'm good. I'm using the MSI/EXE version, rather than the C source.
Why move off Ruby?
And, for Heaven's sake, why would you want to write something like these things in C?
Toy utilities are great motivators to learn a language, that is if the goal is to learn the language.
If the goal is toy utilities, run what you brung, go with what you know.
Job prospects are a lot better with Python. I work as a contractor so it's good to stay close to the market. Python rules several of the markets I'm in. Computational power has reached the point that we don't have to prototype in a scripting language and then rebuild in a compiled language; Python is performant enough to stay in it and there are lots of libraries that cover many domains.
Yes, writing these toys in whatever is great fun. Traveller lends itself to coding so it's a win all the way around.
I'm actually trying to learn Object Oriented Design and Programming but it has been slow going.
Last edited:
Various issues around Py2 have emerged. So Python 3 it is. No big deal.
As in many things, on-the-job-training is immensely helpful because it has (1) project focus and (2) external motivation. Both of those seem to be good learning techniques. With me, internal motivation comes after the technology is learned.
I'm using Python at work, so I learn Python.
Because I am a fluent veteran in Perl, I find Python usable, with the internet handy to resolve "how do I..." issues.
1. It's accessible to anyone who's done dynamic-language scripting. That's a win.
2. I like its clean class syntax. That's a win.
3. I am puzzled that it didn't solve some of the problems Perl has (method signatures).
4. I am now even more convinced that dynamic typing is anathema to "big" and "good" software design (including prototyping, and I think you know why). This is Pythons "niche flaw". On the other hand, dynamic types are, and always will be, excellent for scripting.
5. Run-time compilation is, and always will be, a win for this sort of thing.
6. I hear that its ability to link in C subroutines is fun and easy. That's a HUGE win. If I need to, I can roll expensive loops into C.
As in many things, on-the-job-training is immensely helpful because it has (1) project focus and (2) external motivation. Both of those seem to be good learning techniques. With me, internal motivation comes after the technology is learned.
I'm using Python at work, so I learn Python.
Because I am a fluent veteran in Perl, I find Python usable, with the internet handy to resolve "how do I..." issues.
1. It's accessible to anyone who's done dynamic-language scripting. That's a win.
2. I like its clean class syntax. That's a win.
3. I am puzzled that it didn't solve some of the problems Perl has (method signatures).
4. I am now even more convinced that dynamic typing is anathema to "big" and "good" software design (including prototyping, and I think you know why). This is Pythons "niche flaw". On the other hand, dynamic types are, and always will be, excellent for scripting.
5. Run-time compilation is, and always will be, a win for this sort of thing.
6. I hear that its ability to link in C subroutines is fun and easy. That's a HUGE win. If I need to, I can roll expensive loops into C.
ShawnDriscoll
SOC-14 1K
Python tries not to be another Perl out there.
I was reading about dynamic typing a couple months ago. If I understand correctly, earlier java versions did the same thing and people built large applications with it. My security brain prefers strong typing but my language doesn't.
This is my "Year of Jubilee"; have fun and quit worrying about job stuff. I've been on the "must learn more" treadmill for a couple decades and need a break. Ruby is just fun, this morning I wrote some code to tell me where I need more tests. Code, and my test coverage, needs work. However, you can probably see what it's doing.
This is my "Year of Jubilee"; have fun and quit worrying about job stuff. I've been on the "must learn more" treadmill for a couple decades and need a break. Ruby is just fun, this morning I wrote some code to tell me where I need more tests. Code, and my test coverage, needs work. However, you can probably see what it's doing.
ShawnDriscoll
SOC-14 1K
I prefer all the dynamics that come with Python. Otherwise, I'd be writing Go or Rust apps.
Quite the opposite, to my surprise. I find it to be very perlesque, even to the point of using similar idioms... and even a couple of its minor irritations. Again, to my surprise.
I wrote Java 1 when it was new, and basically had to track with its development for my career. I don't ever remember Java having un-or-dynamically typed variables. If so, then no wonder they clamped down on that quickly. Perhaps it was in a prototype (Oak)?
Ruby started that way too. Moving away from it, but still...
