Will Python SKIP these versions?

ever since the first version of python was released to the public in 1989 its versioning system has stayed the same the exact specifics of how things are released and when exact version numbers go up has changed over the years but the versioning system itself a modified version of senver has stayed the same however that could all be about to change with proposals to switch python from a sver system to a Calver system and of course cuz python always has to be different it's a modified version of the Calver system in this video I'm going to be talking about the proposals which are outlined in a pep it is still in draft at the moment so it may or may not happen but before that I want to talk to you about Cod Crafters code Crafters is a service that provides programming challenges for beginners and advanced users alike you can choose whatever language you like and if you're new to a language you could select an easy mode and if you're used to a language you could select an advanced mode to give you the right level of challenge all the challenges are focused around building your own system so building your own reddis or building your own Docker or shell or git and on top of anything you may learn with the language you use you also get to learn the underlying processes and ideologies behind all these systems and how things interact better I've been tackling a few different challenges and the step-by-step nature and the instructional nature of them is really nice and also if you get stuck you get to look at some code examples of what other people have done and that can give you some inspiration as to what to do next if any of that sounds interesting to you you can sign up for free using the link in the description and if you are grade you can get 40% of any plan that you select again that's 40 4% off any plan use a link in the description with Cod Crafters but with all that out of the way let's see what these proposals are all about the proposals themselves lie in pep 2026 which is very appy named considering what year this is going to start if it gets approved it's currently in draft was only created about 10 days ago uh so we'll see what happens I suppose but the general idea of the pep is for python to switch to a specific type of calendar versioning rather than the semantic versioning or the flavor of semantic versioning that it uses at the moment uh so it be starting with python 3.15 not 3.14 I'll talk about that why uh later but we'll see that the version will be three and then a short year do micro so the three will say the same the micro will stay the same but the year will change so instead of uh python 3.15 releasing in 2026 it'll be python 3.26 releasing in 2026 and this is an October release still so it would be October and then the year will be uh the version and this helps with a few things so this helps um specifically with end of life uh calculations python versions reach end of life 5 years after their first final version has been published and that'll be a lot easier to calculate if it's a year so python 3. 26 will release in 2026 and so it will reach end of life uh 5 years after that in 2031 and and the same for 3.27 will be releasing in 2037 end of life 5 years beyond that 2032 it's a lot simpler to work out and this is made possible I guess is the word to use uh by pep 602 so uh pep 602 introduced the annual release cycle for python which brought in the 17mon development Cadence which allowed uh python releases to be released every year in October so every single year the version number is going up but if I scroll down a little bit uh we'll see that it is sort of calendar based as described here and it's offset by 11 years so 3.15 released in 2026 3.16 27 etc etc etc and the new system will lineing up because it is essentially calendar versioning already it's just not matched to the year it wasn't always the case of course that python was released yearly that started with 3.9 uh so it's a a relatively new innovation which is why it hasn't been changed yet the reason why specifically it's been proposed now is Hugo van I'm going to pronounce this wrong Kady K I really don't know I'm so sorry uh but he is the release manager for python 3.14 and I believe through python 3.16 will he he'll be it because he's the release manager he's been a proponent of calendar versioning for a little while I believe and so he's bringing this in now that he's release manager so if we take a more detailed look at the specification we can see that three is the major version number it says here it is always three there will never be a python 4 so this pet pretty much destroys any chance of there ever being a python 4 which makes sense because it it has become a bit problematic with regards to you know expect surrounding it and you know whether or not it'll be around or not so much so that in the year 201100 should python be around that long uh the version will be 3.100 rather than four and this will allow Python 3 specifically to remain as the brand so Python and Python 3 are both synonymous in that they describe the brand uh the second Point here is that you know the year is the uh the minor version number it's a short year so you can think of it as the year minus 2000 and then micro is the micro version number this will work exactly the same as it does currently so there'll be a new release every two months and it'll be bug fix and security releases so this backwards compatibility section and the rejected ideas section over here talk more in detail about why this exact version of calvo was selected rather than using something like python 26 and it's simply because it's just safer it keeps uh backwards compatibility in a number of ways allows us to keep the Python 3 executable as well so if I go down to the rejected ideas section I'll talk a little bit about some of these so platform compatibility tags are one of them and these are used when packaging things so I believe they're used in wheels and stuff like that and python 3.10 we had uh 310 so it's just an integer number string but if python would have changed to using say python 26 instead of Python 3 then you'd eventually get to python 31 and then this 310 could either mean 3.10 or version 31 uh there was a pep 641 to address this using underscores but it was eventually rejected because it wasn't known what side effects there would be and it was considered just safer to keep it as Python 3 and then have the minor version as the version number uh there are things with ecosystem changes as well which talk about roughly the same things the Python 3 commands again it's just more effort that needs to be expended for a problem that doesn't really need to exist and the same thing with yy. mm versioning they thought about that but they rejected it for the same reason uh 3. 2026 using the full year is just not quite as clean and that introduces backwards incompatibilities with the version number being two digits they did actually talk about additions as well which is pretty funny so those that I in to know rust uses additions and and you can have different versions of rust and then you have different additions and these different additions are what represent breaking changes so the actual versions in the API remain stable and it's the additions that change things and then we're thinking of bringing that in for python but it didn't really make much sense as pretty much every minor version of python even under its senar system brings in bre uh braking changes there are always deprecations there are always removals there are always changes and doing it like this just means that you have to track two versions rather than one and it's just not really workable they did also consider skipping python 4 and moving on to python 5 and 6 in 2027 and so on but they decided that they wanted the benefits of count um calendar versioning so they didn't go with that either and the reason I said at the start it wasn't going to happen for python 3.13 is pi someone actually acknowledged it I'm so happy I've had a number of comments especially on my 3.13 videos talking about 3.14 being python in the next release and one of these peps actually acknowledged it and I'm I'm so happy let me know what you think of these proposals in the comments do keep in mind that these aren't accepted yet they may be rejected still I actually think it makes a lot of sense I'd thought about this before I'm not normally a proponent of Cala I find it really annoying when people on the python package index use it because there's just no information regarding what is a braking change and what isn't but for something huge like an operating system a bun to uses it and for a programming language like python where every minor version breaks things anyway because there are deprecations and removals in every release it makes sense to just match that to the year for the extra convenience and I also thinking that keeping the Python 3 so having the three as the major version also makes sense it breaks less things it's a little bit more recognizable you still will lose Python's uh 3.15 through 25 but I think that's probably fine it's not going to break any version constraints or anything it might just be a bit weird for a bit but I think overall it's a good change if you're looking to learn some cool tips and tricks about python I would heavily recommend the python is awesome series which will be linked in the end cards but I'll see you next time whatever we do next

Channel: Carberra

Views: 3,573

Keywords: pyfhon, pytho, pytbon, pytjon, ptyhon, pytyon, ptthon, pyyhon, pythn, pythoh, pythpn, ython, pytgon, pyhon, pytohn, phthon, oython, pthon, pyghon, pythoj, pythno, pythkn, ypthon, pytuon, lython, pyrhon, pythom, pythob, puthon, pgthon, python, pyhton, pythln, pythin, pytnon, pyton

Id: RtJ_d9dvgkg

Length: 9min 57sec (597 seconds)

Published: Mon Jun 24 2024