Python Adopts a 12-month Release Cycle (lwn.net) 38
The steering council of Python said it is adopting a 12-month release cycle as it seeks to bring more consistency to schedule. In their mailing list they announced the change would mean developers would: 1. Know when to start testing the beta to provide feedback.
2. Know when the expect the RC so the community can prepare their projects for the final release.
3. Know when the final release will occur to coordinate their own releases (if necessary) when the final release of Python occurs.
4. Allow core developers to more easily plan their work to make sure work lands in the release they are targeting.
5. Make sure that core developers and the community have a shorter amount of time to wait for new features to be released. They added: It should also fit into the release schedule of Linux distributions like Fedora better than previously proposed so the distributions can test the RC when they start preparing for their own October releases. If this turns out to be a mistake after we try it out for Python 3.9 we can then discuss going back to longer betas and shorter RCs for the release after that. This will not change when feature development is cut off relative to PyCon US nor the core dev sprints happening just before the final release or the alpha of the next version.
2. Know when the expect the RC so the community can prepare their projects for the final release.
3. Know when the final release will occur to coordinate their own releases (if necessary) when the final release of Python occurs.
4. Allow core developers to more easily plan their work to make sure work lands in the release they are targeting.
5. Make sure that core developers and the community have a shorter amount of time to wait for new features to be released. They added: It should also fit into the release schedule of Linux distributions like Fedora better than previously proposed so the distributions can test the RC when they start preparing for their own October releases. If this turns out to be a mistake after we try it out for Python 3.9 we can then discuss going back to longer betas and shorter RCs for the release after that. This will not change when feature development is cut off relative to PyCon US nor the core dev sprints happening just before the final release or the alpha of the next version.
Re: (Score:2)
Re: (Score:2)
It's an okay scripting language. I've known a few people who even used it as a shell.
It's certainly not *only* a scripting language. Although judging from many of the comments you see here, I'd guess that most Slashdotters have never really used it as anything but.
Re: (Score:2)
mostly gluing together libraries, not for scratch development.
Relearn Python Once a Year (Score:1)
Every year a new Python, subtly incompatible with your old Python!
Re: (Score:2, Insightful)
Re: (Score:2)
The biggest compatibility problem with Python isn't so much the base language but there are so many popular libraries that seem to like to change their API and deprecate functionality at the drop of a hat. Create any Python project with any complexity that pulls in a bunch of extra dependencies, and in a few years it's simply not going to run on the newest Python with the newest versions of those libraries. And since those libraries themselves also pull in their own dependencies, things can get pretty mes
Better than FF (Score:2)
Python's lifecycle reminds me of Perl (Score:5, Interesting)
Re: (Score:1)
Re: (Score:2)
I can attest to the enthusiasm for Perl. The "cpan install" model to fetch arbitrary dependencies from around the world and build them up locally was a new kind of power. Python has replicated this, along with many of its dangers and difficulties, with "pp intall".
Re:Python's lifecycle reminds me of Perl (Score:4, Interesting)
Remember how in the late 90's everyone was supposed to learn Perl as the "next big thing" and if you didn't you were just going to be left behind and codgerly yelling at people to get off your lawn?
No.
No, I don't.
There have been a few others since then like Java.
Java actually was the next big thing. It still dominates in several industries.
Ultimately, in terms of pay/career, in my opinion, you'd have been much better off just sticking to C programming and ignoring the trends.
Possibly true, although by now you'd better have picked up C++ as well.
Nothing is bad or wrong with Python (except forced indention, *grin*), but I think it's definitely going to end up in the same bucket as Perl, Ruby (weren't all website supposed to be using Rails by now?), Java (write once... nevermind), and others.
Perl is still just as good for the things it was always good at, and it's still the best for some of them... notably anything involving big text files. Python is dominant in scientific computing, and I already addressed Java above. Ruby is pretty much over though, I haven't had to hear anything about it in ages.
It's nothing so amazing or special as to actually live up to it's hype. It's just another scripting language, nothing more or less.
I share your distaste for Python's indentation bullshit, I have personally had problems copying and pasting code samples and having them fail. But it's carved out its niche pretty definitively.
Personally, I find Lua a lot more special than Python, but it all depends on which logical fallacy you like to use to justify your programming preferences.
Lua is less special, which makes it better than Python, because it isn't designed to be used on punch cards. (Why else would indentation matter?)
Re: (Score:2)
No. No, I don't.
Fair enough, but I definitely do remember the same hype. Only the name of the language has changed.
Java actually was the next big thing. It still dominates in several industries.
That completely depends on your value system. It's a viable job, yes. The language is popular in some spaces, true. However, it's a lot like fucking fat women. There are people who like it, yes. There are people who will do it. However, I'm absolutely thrilled that it's not my job. Even PHP coders probably have better lives than guys competing for those bottom scraping Java gigs. I wouldn't even wish a Java g
Says the C coder... (Score:1)
My experience is, that C /C++ coders just have very little experience with anything but C/C++, and if, then only with languages that are in a different league or with a different purpose, and only so much, so they can keep feeling superior and sniff their own farts.
C is alrigh on the low level, albeit cumbersome and primitive, and the main source of unchecked bounds and pointer bugs that allow hacks. (Cause you aren't all that smart and perfect after all, in doing that job that any good programmer would hav
Re: (Score:2)
My experience is, that C /C++ coders just have very little experience with anything but C/C++
That's can be an advantage. They focus on what works. Design patterns are much more important to learn than languages, as any good programmer knows. Having your focus on design patterns and tool mastery is much more helpful than learning the next flavor-of-the-month language, in my opinion.
then only with languages that are in a different league or with a different purpose, and only so much, so they can keep feeling superior and sniff their own farts.
HAHAHAHA. You take this giant swing at C coders then dare to mention *Haskell*. Dude. I've never seen a group that thought they were more superior than the LISP, and ML, OCaML, Haskell folks. They are the biggest ivory to
Re: Says the C coder... (Score:2)
I don't know which is worse... LISP or Hal.... that's a never ending war. They only take breaks to regroup under Vi & Emacs. I think it is one of things where one only stays alive because the other still exists.
Re: (Score:2)
In domains where C dominates, like embedded controls, they're moving to auto-generated code.
Mathworks has a full suite of ISO26262, DO-189C, MISRA, etc tools. The C Simulink generates is technically 'perfect' even if it's over the top verbose with casting.
Automotive, Aerospace and Heavy Equipment have been moving that direction since 2000.
https://www.sae.org/publicatio... [sae.org]
https://www.sae.org/publicatio... [sae.org]
https://www.sae.org/publicatio... [sae.org]
Re: (Score:2)
Re: Python's lifecycle reminds me of Perl (Score:2)
As another poster said, I don't recall any of that. And I was learning C & Java in the mid-to-late 90s. Perl was basically a meta of C like C was to assembly. And Linux was also this "thing" around that time.
In the late 90s, Perl was already a decade old. Perl & Python are older than Java & Linux, and were more standardized than C++ till 1998.
Perl is over 30 years old. Python 28. At what age does one consider it to be something other than a fad? There is enough old code in each to keep the
Re: (Score:2)
Re: (Score:2)
The fads around languages often correspond to some particular application of the language. Ruby got it's fame from Rails. If the Rails developers hadn't chosen Ruby, it would have remained obscure.
Java rose to fame due to sustained advertising by Sun/Oracle.
Re: (Score:2)
Perl didn't have near the ecosystem that Python has.
If you want to re-invent everything from scratch, you can. But with Python there's a strong possibility that if I type in "____ module python" someone will have already written something for what I'm trying to do.
Re: (Score:2)
Perl didn't have near the ecosystem that Python has.
wat
with Python there's a strong possibility that if I type in "____ module python" someone will have already written something for what I'm trying to do.
perl -MCPAN -eshell
Perl had a massive library of libraries before Python even existed. And if Python hadn't come along and stolen its thunder, it would have continued to grow.
Re: (Score:2)
And has a fraction of the functionality of Python's ecosystem, especially in the scientific/engineering space.
Python is cutting into Matlab and C like Perl never did.
it would have continued to grow.
It wouldn't have because the people that learned Python wouldn't have learned Perl.
Re: (Score:2)
I've programmed in over 25 different languages over the last 50+ years. I started with BASIC, FORTRAN, and ALGOL. I've had years of experience in COBOL and Java, as well as SQL. Also had lots of fun teaching C to experienced programmers -- and actually got paid heaps to do so!
I actually like the fact that indentation is semantically meaningful in Python, and especially no longer needing to terminate statements with a semicolon (or full stop, in the case of COBOL). There are several Python features I'd r
Re: (Score:2)
Tech is very fad and marketing driven.
Re: Python's lifecycle reminds me of Perl (Score:2)
I'm an embedded C/C++ coder for my day job. Even that is increasingly Python and you only have to take a look at Micropython for the ESP32/ESP8266 to see the future for easy-to-implement embedded devices.
Gone are the days of writing your own PWM or SPI libraries. There's a module for that.
You will regret it (Score:1, Funny)
It's dangerous, here's the proof. [cnn.com]
Re: (Score:2)
that's why I avoid python. Too constrictive.
Re: (Score:1)
I program in Eel++ myself.
Let's just get it over with already ... (Score:2)
And jump ahead to the logical conclusion of a continous release system with zero hardening time, like it seems to be fashionable among the nutjobs nowadays.
Everyone, please install python-3.9999_live! Each day, from now on! And fix old bugs each day, while installing new ones. Who needs a stable, non-broken system anyway?
(And I say that as somebody who runs Gentoo Stage 1 unstable installations continuously since 2004. Aka your beta tester. ... Hello! *waves*)
Continuous integratioin and instant upgrades (Score:2)
Having a release cycle is such a naughties concept.
These days you know that every patch that is submitted is go to go because you do continuous integration. Then you have your clients pull a new release every few weeks via Python Update.
Everyone runs the same version. No need to support old versions. No need to worry too much about security flaw because they can patched almost as quickly as they are found.
Welcome to the brave new world of software development!
12 month? (Score:2)
The 70's called, they want their waterfall back.
when it's ready (Score:2)
what's wrong with - when it's ready?
everything needs to be on a scheduled release these days, once a week/month/quater/etc.
what is the point? i now see project releases where sometimes nothing has changed except for 2 bug fixes or so.
in the past a set of features was defined and when they were implemented the new version was released, followed by bug fix releases.
nothing is wrong with this approach depending on the product.