18 ms·
All Python versions less than 3.6 are now EOL
- mrfusion 6y agoIt’s nice you don’t have to choose between python 2 and 3 anymore.
- Waterluvian 6y agoYes. That problem suddenly doesn’t exist anymore. Wonderful stuff.
- devenblake 6y agoAccording to a quick `apt remove python` you still need Python 2 for (on Debian Stable, at least): * minetest * mpv * npm * qbittorrent * smbclient * virtualbox-6.1 These are the more popular ones. I write and don't hate (compared to Python2) Python3 but apparently if I remove Python2 I have to shed all these programs because they still depend on it!
- marcan_42 6y agompv, really? That has nothing to do with python as far as I know. There are Python bindings to libmpv, which I maintain, but I doubt they're included in Debian's mpv package (and they're Python 3 compatible). Maybe it's a VapourSynth thing?
- shakna 6y agompv seems to use python-docutils for generating the documentation, which has had a very long path towards full Python3 compatibility and only really "reached" it last year (after Debian's freeze).
- formerly_proven 6y agoYeah but the tools for building the docs wouldn't be included in a binary package?
- marcan_42 6y agoExactly, build tools shouldn't be deps of binary packages.
- CydeWeys 6y agoCan you include versions of all these deps? For example, as of late 2019 npm does work on Python3. So maybe some of this is just Debian Stable being slow with new version releases as usual? npm is one of the few pieces of software I've had to install outside of the package manager recently because the version available was just too old.
- OskarS 6y agonpm, really? What’s going there?
- sstephant 6y agoI believe it's for node-gyp and the build system for native modules.
- throwaway8941 6y agoYou have legacy versions as far as upstreams are concerned. I have every package you listed and I there's no Python 2 on my system.
- duckerude 6y ago`apt remove python2.7` doesn't show any trouble on Debian Testing. It should be released as stable around mid-2021, and then it'll be over.
- nemetroid 6y agoThe contents of Debian Stable, to my understanding, generally reflect the state of those applications in early 2019[1]. 1: https://release.debian.org/buster/freeze_policy.html https://release.debian.org/buster/freeze_policy.html
- 3np 6y agoIndeed. They haven't announced any dates for the next stable release, but looking at past cycle I think we can expect python3 to be the base python within a year, being conservative.
- fizzled 6y agonpm's dependency on 2.7 enrages me.
- simcop2387 6y agoNextstable fully removes it. Its not even available to install anymore
- deleted 6y ago[deleted]
- ericmcer 6y agoYeah except for your OS depending on python 2 and most python code you write being in python 3.
- monadic2 6y agoSounds like a problem for your os to worry about. They don't even need to expose their internal runtime.
- duckerude 6y agoI like this visualization of Python's release cycle: https://python-release-cycle.glitch.me/ https://python-release-cycle.glitch.me/
- kevindong 6y agoPython 3.0 is surprisingly short (~7 months) and Python 2.7 is impressively long (~9.5 years).
- Izkata 6y agoI have no experience of this myself, but I remember people saying that 3.0 had at least one major-yet-unnecessary incompatibility with 2.7, and that converting 2.7 to 3.2 or 3.3 was significantly easier than 2.7 to 3.0 (and so that could explain the speed it was dropped - the fix may have been 3.1 and not 3.2 like I have in my head)
- pansa2 6y agoPerhaps they were talking about the explicit `u` prefix for Unicode strings? This was present in 2.7 but missing from 3.x until 3.3 [0]. [0] https://www.python.org/dev/peps/pep-0414/ https://www.python.org/dev/peps/pep-0414/
- BeetleB 6y ago> Python 2.7 is impressively long (~9.5 years). It's not impressively long, it is artificially long. It was decided there would be no 2.8, so they kept 2.7 up for compatibility reasons for a long time to make it easier for people to transition.
- mixmastamyk 6y agoCould use just a bit more detail on the X axis.
- di 6y agoHi! Author here. If you hover over the individual bars, it will give you more detail like start/end month and total lifespan.
- AndrewDucker 6y agoYup, the sunset date for Python 2 was moved from 2015 to 2020. People have had plenty of time to move. https://www.python.org/doc/sunset-python-2/ https://www.python.org/doc/sunset-python-2/
- p_l 6y agoShould have been 2010 or earlier, with less breaking changes. I expect the pains of dealing with 2vs3 to continue for few years at least, and that's with policy of avoiding and removing python were possible.
- bscphil 6y agoYou're getting downvoted for what seems like a harsh policy. I think it's definitely understandable that most people want to make the switch as easy as possible, and that's the reason for the delay in discontinuing Python 2. But I would make the case like this: The slow approach failed. Chances are, most Python 2 code was written after 2010. By switching earlier, yes, you make the switch harder for the handful of people who actually did port their code, but on the other hand you avoid the exact same porting difficulties for many more because the majority of Python 2 code would never have been written! Someone upthread mentioned scientists, for example, who were still writing their analysis code in the late 2010s and are now confused about why none of it runs. To be sure, it's worth thinking about why it failed, as many other projects have been able to get away with a longer deprecation periods. But its seems like there is a case to be made, in pure consequentialist terms, that Python would have been better off killing Python 2 earlier.
- p_l 6y agoAlso consider that a lot of hardest to port python code in various enterprise systems is going to be python 2 for as long as it takes to kill last RHEL version that defaulted to Python 2 (which I think, is the RHEL7, which is going to be supported till I think 2026?)
- sixstringtheory 6y agoMISTER PROSSER: But Mister Dent the plans have been available in the planning office for the last nine months! ARTHUR DENT: Yes! I went round to find them yesterday afternoon. You hadn’t exactly gone out of your way to pull much attention to them have you? I mean, like actually telling anybody or anything. MISTER PROSSER: The plans were on display. ARTHUR DENT: Ah! And how many members of the public are in the habit of casually dropping around the local planning office of an evening? MISTER PROSSER: Er – ah! ARTHUR DENT: It’s not exactly a noted social venue is it? And even if you had popped in on the off chance that some raving bureaucrat wanted to knock your house down, the plans weren’t immediately obvious to the eye were they? MISTER PROSSER: That depends where you were looking. ARTHUR DENT: I eventually had to go down to the cellar! MISTER PROSSER: That’s the display department. ARTHUR DENT: With a torch! MISTER PROSSER: The lights, had… probably gone. ARTHUR DENT: So had the stairs! MISTER PROSSER: Well you found the notice didn’t you? ARTHUR DENT: Yes. It was on display in the bottom of a locked filing cabinet, stuck in a disused lavatory with a sign on the door saying “Beware of the Leopard”. Ever thought of going into advertising?
- epistasis 6y agoAbout every other month I have to help a biologist who has pulled down an older program from Github debug why it broke in their data only to find that they were trying to run in Python 3 instead of Python 2. These are people that can write shell scripts, but don't program. It makes me aware of all the old code out there that is not used super frequently, but still solves people's problems, and would continue to if there hadn't been breaking changes. As I write Python 3 now, I am less than impressed with the reasons for breaking compatibility. I'm told that it was necessary for proper bug-free Unicode code, but there's enough difficulty when using, say, gzip, and little enough documentation about the "proper" way to handle Unicode that I doubt that it will actually reduce Unicode-related bugs. Python is still a great tool, but Python 3 really took the shine off for me.
- tyingq 6y agoI wonder if there's any merit to python3 kicking off a "is this script python2?" on some subset of common errors that crop up. Then it could tack on a "looks like you're trying to run a python 2 script on python 3" final error to stderr.
- minot 6y agoThat’s a great idea. Perhaps even offer to 2to3...
- hprotagonist 6y agohttps://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/ so “helpful”!
- Alex3917 6y ago> little enough documentation about the "proper" way to handle Unicode that I doubt that it will actually reduce Unicode-related bugs. There are hundreds if not thousands of pages of unicode documentation. If anything the problem is that there is way too much for any normal person to actually understand it. For most people though, knowing when to normalize strings to NFC versus NFKC is all they need to not unknowingly accumulate tons of technical debt.
- deleted 6y ago[deleted]
- remram 6y agoThey are unsupported by the PSF, but still supported by Linux distributions. For example Ubuntu 16.04 uses Python 3.5 and is still supported until April 2021 (security updates until April 2024).
- pmontra 6y agoYep. BTW an easy way to use more recent versions of Python (and multiple different versions) is to use a version manager. I like asdf which is multi language (and multi database) https://asdf-vm.com/ https://asdf-vm.com/ The Python plugin is at https://github.com/danhper/asdf-python https://github.com/danhper/asdf-python
- mixmastamyk 6y agopyenv is the python-only alternative.
- pmontra 6y agoYes. I like asdf because most projects are multilanguage nowadays, usually something + Node. Asdf also manages databases so I don't have to keep track of docker containers for multiple versions of postgresql or mysql.
- dehrmann 6y agoAnd Jython never made it to 3, but continues releases based on 2.7.
- mixmastamyk 6y agoUbuntu only does security patches to my knowledge, so don’t expect and bug fixes. Better than nothing however.
- ciupicri 6y agoRHEL 8 comes with Python 3.6.
- throw8769758 6y agoAs someone interested in learning Python, does it mean I dont have to worry about version 2.x? Do I just skip any book or tutorial containing that version?
- deleted 6y ago[deleted]
- airstrike 6y agoYes. Start from the latest stable and don't look back You can use tools like six to port python 2 to python 3 which should cover 90% of the code in small scripts
- seabrookmx 6y agoYes
- amluto 6y agoYes. Unless you specifically need to work on legacy code, start with Python 3. IMO you should consider simultaneously learning mypy and Python type annotations. Python with some typing is a vast improvement.
- hprotagonist 6y agoinstall 3.8 and go without fear
- heavyset_go 6y agoNo, you don't need to worry about it. Do ask about it in interviews, though. There are still Python 2.7 apps running in production, and there's a good chance that companies are looking upgrade their code to Python 3. If you're interested, this document[1] is a good resource should you want to port from 2.7 to 3. [1] https://docs.python.org/3/howto/pyporting.html https://docs.python.org/3/howto/pyporting.html
- fouronnes3 6y agoSerious question: when will Python be done?
- CogitoCogito 6y agoYou are free to fix your use to a specific version whenever you want. So I guess it's done whenever you choose it to be done.
- strombofulous 6y agoAssuming the libraries you want support the older version you are using
- CogitoCogito 6y agoThat doesn't really contradict me. You _can_ fix your python version. You can even continue using all the libraries you have installed with your python version. Of course you can't necessarily use newer versions of those libraries or possibly new that haven't been written yet, but of course you can keep using your python and whatever libraries you have installed for it. But yes you can't expect new code to continue to support your fixed choices forever. Then again that's true of essentially every language out there so I don't really see what's special with python.
- rhacker 6y agoWhen JS is done.
- gruez 6y agoIs there any programming language that's "done"? I feel like any programming language that's "done" is closer to "abandoned" than the developers saying "the language is perfect now, there's no need to add or change anything".
- eesmith 6y agoTeX is the closest I know of.
- mlang23 6y agoI believe the fundamental error was to try and break backwards compatibility in a dynamic language. I can see how this would be much safer for a strongly typed language to pull off. It would still be a PITA, but at least I'd feel a bit more save about it. I watched the transition of a NVDA from Python2 to Python3. It took a pretty long time, and some of the commit logs read like voodoo. I would really not want to be in charge of having to migrate a semi-largish codebase from Python2 to Python3, especially if there is only limited amount of automated tests.
- leephillips 6y agoPython is strongly typed.
- mlang23 6y agoSince when?
- afiori 6y agoIn some contexts strong typing means that all values have a well-defined unique type that cannot be changed. For python this means that the language takes care of performing meaningful conversions when a value of a type A need to be turned into type B and also that there is no way to convince python that a value is a String (for example) if that value is not a valid string. Or from wikipedia: In Luca Cardelli's article Typeful Programming, a "strong type system" is described as one in which there is no possibility of an unchecked runtime type error.
- leephillips 6y agoSince its original design and first release. Try to do 1 + 'a' in Python and see what kind of error you get. Now try it in Javascript, which is actually weakly typed. If you still don’t believe me, try reading the documentation.
- makecheck 6y agoIt frustrates me that even now I regularly find out about some new thing being written at work, only a few months old but already fairly widespread among internal teams, and...oh, they chose Python 2.7. We not only have Python 3 available but several versions of it, too. Python 2 doesn’t sound like an ancient, totally-different-language so people just adopt it because it was the version on their laptop or something and because it “works”. In reality, it’s inevitable that some major IT upgrade will finally throw out that interpreter (or, the existing one will fail to work for some obscure reason and no one will fix it because it’s “unsupported”). And at that time it will be non-trivial (to say the least) to fix every affected script and the entire downstream dependency chain because — as so many on HN know — Python 3 is a different language. Any ideas on how to present this to management as the crisis that it should be? It’s really quite a risk but it is hard to demonstrate the risk when everything “works” so “well” right now.
- jeffrallen 6y agoIt's not a crisis. If Python 2.7 works, people will keep using it. The real crisis is all the lost time dealing with porting to Python 3.
- zamadatix 6y agoMiddle English still works too doesn't mean it's not a problem to try to use it for a new project. Everything has trade offs, both staying on the old AND moving to the new. At some point everyone does move and managing the size of that transitional tail well is part of running a business well. There is not a one stop answer to the problem of when to migrate to the new and stop using the old but "always bleeding edge" and "always what we started with" are unlikely answers for most places.
- deleted 6y ago[deleted]
- monadic2 6y agoLost time? How do you figure?
- fizzled 6y agoIsn't 2.7 part of Catalina 10.15.6?
- Wowfunhappy 6y agoUp until the Coronavirus hit, I was a volunteer teacher at a Girls Who Code club, where we used Python. I spent our very last class before the universe collapsed introducing students to the concept of functions. Once we'd finished going over some example programs, I asked the kids to modify a quiz program they'd written previously with a different teacher. That program used copy-pasted lines of code in order to ask multiple questions, and I wanted the students to re-implement it with a single function instead. This was a pretty challenging assignment—the kids had never encountered functions before today, and I was purposefully not quite telling them what to do, only giving examples of functions used in other contexts. But one of the girls managed to get it, and I was really proud of her. Except her code wouldn't run because—I realized with horror—the original program she'd done with the other teacher was actually python 2 code. I am so damn frustrated that this happened! I was trying so hard to make these kids understand the concept of functions; I did not want to explain the differences between Python 2 and 3. It is, of course, primarily my fault—I should have coordinated better with the other teacher—although in my defense, we were both volunteers, and as it is I spent most of my Friday and Saturday planning this lesson. It also should just never have happened! I'm not aware of any other language where this type of confusion is so common, and it really makes me wonder if we'd be better off teaching something else. I'm not sure who is to blame for the situation, but it really sucks, and I don't think it's going to go away just because Python 2 is now technically EOL.
- Xylakant 6y agoRuby went through a similar period when transitioning from 1.8 to 1.9. Strings learned about encoding, breaking most libs handling strings, some syntax was added, some removed. It was possible to write 1.8 and 1.9 compatible code, but it took some effort. However, the big players in the community, rails etc. tackled that change head on. It was a point of pride for libraries to be 1.9 compatible. And everyone moved on. I’m always puzzled by how hard the python community ist stuck on 2.x
- pansa2 6y agoPython didn’t have a single big player like Rails to “lead the charge”. Instead, its ecosystem is made up of many smaller libraries. Because it’s not possible to run Python 2 and Python 3 code together, none of those libraries could upgrade until its dependencies had done so. This just led to everyone waiting for everyone else.
- ed25519FUUU 6y agoFor those that think migrating from python2 to 3 is easy: no. You’ve clearly never tried to migrate different companies/environments. Sure, the code now runs in the py3 interpreter, but guess what!? That was the easy part! Now go hunting down Byzantine build scripts and environments to find out how it was deployed and tested. Tested lol? Ugh and guess what? The code base has commits that we’re never deployed to prod. What do you do now? You basically own a service that hasn’t been deployed in 4 years and a branch that was never deployed ever.
- lolc 6y agoThe things you describe are real problems but they are orthogonal to the Python migration. You have to pay that cost eventually, with or without migrating. It's not just Python that moves.
- mixmastamyk 6y agoTechnical debt on your part is not an emergency on our part, or something like that. Get your house in order.
- aeturnum 6y agoI don't really understand all the grumpiness around Python releases. There are lots of programming languages that depend on interpreters or VMs (Java, Erlang / Elixir, Go [kinda]). Those languages have versions which are no longer supported and, as far as I know, that's not controversial. The old versions exist. They are not supported. You can choose to use them if you wish or use the latest. I don't see many complaints about the fact that Java SE 6 (or whatever) isn't getting updates anymore. I think the Python team fucked up the 2->3 transition, but that was 12 years ago! Do other people have explanations as to why old versions of the Python interpreter are associated with so much emotional investment?
- jeffrallen 6y agoGo 1.15 can compile Go 1.0 programs. That's why I'm grumpy with the Python team but not grumpy with the Go team. There's simply no more to be said about the situation than that.
- mixmastamyk 6y agoGo does a lot less language wise, and is a lot newer. Didn’t have to change 1991 design choices. Unicode was a big shift.
- t-writescode 6y agoIt's also "Go one point ten" and "Go one point fifteen". That's a minor version update. Backwards compatibility is common between minor version updates - in fact, it's part of a major version update that backwards compatibility breaks.
- jeffrallen 6y agoIt is minor because the Go team understands their responsibility not to make major changes. Which they learned in part from watching Python screw it up.
- 6y ago
- chishaku 6y agoDoes anyone know about Python 4? Is there anything particularly notable or exciting on the horizon?
- jeffrallen 6y ago2 to 3 was so traumatic, there will never be a 4.
- pansa2 6y ago“The plan is not to do 4.0 until 2.7 is barely a faint memory, and then we will consider how to handle the transition very carefully.” - Guido van Rossum https://mobile.twitter.com/gvanrossum/status/1285443278960123904 https://mobile.twitter.com/gvanrossum/status/128544327896012...
- true_religion 6y agoThat was Guido... but Python has moved to design by committee now so anything goes.
- duckerude 6y agohttps://www.python.org/dev/peps/pep-0563/ https://www.python.org/dev/peps/pep-0563/ was to become the default in Python 4, but that has been changed to 3.10 (see https://github.com/python/peps/commit/f1c3a99ad5df574489e877c0456c0c714b507357 https://github.com/python/peps/commit/f1c3a99ad5df574489e877..., https://bugs.python.org/issue38605 https://bugs.python.org/issue38605)
- TekMol 6y agoOn the current Debian (10), when I do this: $ apt install python $ python -V I get this: Python 2.7.16 So EOL for some definition of EOL. But probably not in terms of "Don't use it in production anymore". Because in many places, what is in the current stable Debian repos is what is used.
- mixmastamyk 6y agoDebian stable is well known to be behind.
- l3s2d 6y agoOn most Linux distros the `python` package corresponds to Python 2. Likewise, most distros have a `python3` package with a relatively recent Python 3 version. This is for compatibility reasons and won't change anytime soon. The most notable exception is probably Arch Linux, which has Python 3 available in the `python` package.
- afiori 6y agoOn fedora `python` runs Python 3.8
- drybjed 6y agoIn Debian, Python 3.x is packaged as `python3`, whth v3.7.3 packaged in Debian Buster. https://packages.debian.org/buster/python3 https://packages.debian.org/buster/python3
- heavyset_go 6y agoThis is kind of Debian stable's appeal, and shouldn't be a surprise. Python 3 is behind the python3 command. Linux distributions that appeal to those who like to be on the cutting edge have pointed the python command to python3 already. Debian stable will be there one day, too.
- neckardt 6y agoIt'll take a while. I'm on Debian 11 (testing) and I'm also getting python 2.7.18 for just `python`.
- satya71 6y agoI see a lot of comments about Python 3 was 12 years ago. Yes. But Python 3.0 - 3.4 were not usable. Most important third-party libraries were only ported Python 3.5 onward. So the real Python 3 start date should be 2015, not 2008.
- mixmastamyk 6y agoThe tools for upgrading code to Py3 paradigms started in 2.6 however. There was plenty of time to do it. Unless a project dealt heavily with unicode the transition was trivial if any effort was made.
- satya71 6y agoYes the translation tools existed, but they were not quite enough. Besides real world doesn't move in one swoop. You need co-existence. I very much wanted to move to Python 3, but critical libraries I was using were not there. And running both 2 and 3 at the same time was very unergonomic until python-future [1] became stable and widely-used. [1] http://python-future.org/ http://python-future.org/
- mixmastamyk 6y agoA decade is pretty good for free support. You are welcome to pay to continue as well. About five years ago I used six and it worked well enough. Now both obsolete.
- heavyset_go 6y agoI started a couple of green field projects in Python 3.3 and Python 3.4, and have to disagree. By that time most third party packages had moved to Python 3, and I had no trouble building large applications with it.
- CapriciousCptl 6y agoPython2 aside, judging by the rest of these posts, maybe it's just me but I haven't seen any problems with forwards compatibility in Python 3. That is, stuff written 5 years ago runs fine on 3.8. The only issues I've had is with virtual environments and pip freeze because some older Python versions relied on packages for features now in the Python standard library, but since we know how to spot those now that's not too bad of a fix. On the other hand, Python gives a growing and continuously maintained standard library and none of the headaches that, say the JS ecosystem gives. That said, not all of the features are great all the time. Async/await comes to mind, which adds a lot of complexity without the performance gains even senior programmers might expect. But overall, we're already using features in Python3.8 for projects, and have upgraded our instances to Python3.8 without issue. I guess it's possible we leave some pip dependencies in the dust because they may have some incompatible code with a future 3.x release, but we haven't had a problem before. Tests permitting, we'll do the same for 3.9 if we find something we like or might wait a few years.
- nickysielicki 6y ago> That is, stuff written 5 years ago runs fine on 3.8. The only exception to this that I can think of is the changes to generators introduced in PEP479. https://www.python.org/dev/peps/pep-0479/ https://www.python.org/dev/peps/pep-0479/ https://www.juandebravo.com/2018/11/09/python-37-stop-iteration/ https://www.juandebravo.com/2018/11/09/python-37-stop-iterat...
- robocat 6y ago> and none of the headaches that, say the JS ecosystem gives. ECMAScript is the language, and it is amazingly backwards compatible back 20 years to about the start of the century without any trouble, and plenty of tooling like TypeScript can target ECMAScript 3 released a score of years ago. Python could have added a ‘use strict’; in 3.0 to avoid a breaking change!? Sure, since then browser features have radically changed and frameworks have changed, but the language itself has been extremely solid. Conflating JS and the ecosystem is not a fair comparison. Also there have been many competing different implementations of JS engines, with amazing levels of compatibility between them (even Internet Explorer 5.5 released 2000 only had a few very minor known quibbles in the ECMAScript implementation). Edit: Of course Unicode is actually hard to deal with because ECMAScript uses UTF16 for strings and symbols, even though the source code is usually written in UTF8. And note that the u flag was added to RegExp expressions to deal with Unicode better in ES2015 (especially U+10000 and greater, which are generally difficult to deal with in ECMAScript code).
- mixmastamyk 6y agoString interpolation everywhere for the win! Commonly, unfortunately called “f-strings”. :D Ordered more efficient dicts was another win.
- leephillips 6y agoThe Fortran spec was published in 1957. Today’s Fortran has features that were not dreamt of then, such as array operations with automatic parallel execution. The changes are a bit more drastic than improving Unicode support. But I can take a Fortran program written in 1960 to run on a computer that needed its own building, that was fed into a machine without an operating system using punched cards, and compile and run it on my phone.
- beagle3 6y agoI don't remember the details, it's been nearly 30 years, but ... I had to fix Fortran-II (1960 or so) programs so that the fortran-77 compiler (on the same IBM VM/CMS 390 system) would agree to compile them. The changes weren't big, but they were needed. (I didn't write the original - I was just the maintainer at the time) I also needed to change a lot of things porting the same program a few years later to an IRIX based machine whose name I don't remember right now (Octane, perhaps?). And that was a well behaved program that did not try to change the value of 4. Python 0.9.1 programs (Earliest I used) required much fewer changes to run on 2.7 -- partly because I never used stuff like field access control (which was luckily dropped from the language). Python 3 requires a few more changes, but I suspect I can still compile Python 0.9.1 on modern hardware and run the original code.
- leephillips 6y agoThis is a common experience, but it arises because there were many slightly different versions of Fortran in actual use, taking advantage of the features of the many different compilers. But a program that stuck to the official standard generally never needed to be changed. (But I might be exaggerating about 1960. I don’t know when the standard settled down and the commitment to non-breaking changes was adopted. But it was a long time ago.)
- true_religion 6y ago> Python 0.9.1 programs (Earliest I used) This inspired me to download Python 0.9.1. to find out what field access control was. I did find it. https://www.python.org/download/releases/early/ https://www.python.org/download/releases/early/ And amazingly it compiles, and does so in just 1.5 seconds on an iMac (unlike my Typescript project which is compiling at 90 seconds and counting.... hmmm). Unfortunately, even now with access to the source code I can't find anything about field access control. What was it? How did you use it?
- ram_rar 6y agoI am soo glad, I pushed back on python migration in my team until 3.6 was released. We were running large amount of django code base in 2.X and 3.6 was the only version which had some reasonable improvements to upgrade to. I sincerely hope the python community has learnt it lesson and wont break backwards compatibility in 4.X releases.
- BlueTemplar 6y agoWhy would they call it 4.X then ?
- abiogenesis 6y agoWhy does Java call the latest version 15?
- nojvek 6y agoI would have been okay if the only breaking change in python 2 -> 3 was strings are Unicode by default. But they went with the logic of “if we’re gonna break, why not break a bunch of other things and take this opportunity for a different python” Needless to say, the folks in charge of python didn’t think things though. It’s a big fat breaking change with no real automated way to upgrade. A whole bunch of apis are now different. At my company even after a year it’s still a pain having some scripts only work in py2, while others in py3. Python3 pulled a google.