Full podcast episode: th-cam.com/video/-DVyjdw4t9I/w-d-xo.html Lex Fridman podcast channel: th-cam.com/users/lexfridman Guest bio: Guido van Rossum is the creator of Python programming language.
Python 3 is definitely way better than python 2 and a lot of its changes were necessary. I was lucky to start learning right after the transition so I decided to just focus my learning on python 3. It was difficult to get older scripts to run because every single print statement would be broken, but I didn't have to forget stuff and relearn it. But I feel bad for those with some years of experience python 2 having to rebuild a lot of things they knew
@AstroPenguin I want kill myself when I saw such. To migrate from Python 2 to 3 so many tools! And not just it, also you have new print function and so on using "from future import ...". And so many fast methods to migration from internet. If you are not author TH-cam project or something similar then even if you have a big project it's a one month working. Off course it's to my opinion
Yeah, I had a few libraries that needed to be written py2-3 compatible that sort of tight-rope nonsense was annoying. Bits of code that would crash get caught, comment that this is python 2 code and then do the other stuff.
May be that I'm not right. Two things may stop your migration. It's a huge codebase (tons of code) and playing with specific things like low level programming or so. Otherwise may be you try to migrate to fast. Not Python 2 -> Python 3.x, when x is 0-1. Python 3 changed a lot. More than 10 year, I'm writing Python 3. After Python 2.7 I'm not so happy in period of Python 3.0-3.5, but beginning from Python 3.5 is awesome.
I can not understand. Technically simple things like print "" to print("") not problem to migrate even to millions lines of code. Just use good tool. Harder migrate typing problem like strings from ascii to utf, you can't just swap code because string manipulation may be various. But we have a tool not for migrate, but code analyzer to see problematic code like that. In conference that I see many years ago such tools presents from mans who migrate there not little projects from Python 2.x. You may search Pycon early years
_> I feel bad for those with some years of experience python 2 having to rebuild a lot of things they knew_ I don't. Being a programmer means constantly having to learn new things. Some things stand the test if time, python 2 is not one of those things. If you are not willing to learn a better way, you are in the wrong business.
I'd love to see a no-GIL mode. Mind you half the extension maintainers would still ignore the warning that it's coming for several years unless half their users are using the no-GIL version. There's a battery icon program I really liked, but I finally had to stop using it because it never made the transition to Python 3...
no-GIL + compile-type reflection + easier C/C++/native ABI bindings are the killer features that Python 4 should have. All things that Nim has while being stable since 2019 though.
Is there a list of relatively complete software that never got a python 3 conversion? I could certainly see that as a reasonable set of projects since it's not too hard to see where the breaks are. I think bCNC was still py2 compatible (my svg parsing code is used there and I backported it here and there to py2 just for that project after I finished it up).
If there ever was a Python 4.0 ALL I want, the ONLY thing I want or care about is speed/ performance. I want to be able to write high performance Python code. However they can manage that, whatever they need to do to accomplish that, if they do that's what I would want.
You would need to do more than no gil to make python really performant. I would help for certain types of code in certain scenarios, but a big reason pyton is so slow is that 'everything is an object in Python' and every Python object is stored on heap (stack allocation is much faster and from a pure performance standpoiunt would be the default approach).
It is lolllll... Joking aside, the issue that happens in this video (backward compatibility) is handled gracefully in JS... New ecmascript specification never breaks backward compatibility
@@aburoach9268 if it was 5 years ago maybe stick with PHP for a easy backend setup, but with serverless, new better backend and CMS frameworks, typescript, ORMs, and databases that connect directly with JavaScript, node is the way to go. PHP main advantage now just seems to be WordPress in my opinion.
Any projects not willing to migrate have the choice between maintaining their own fork of python3 or dying. Like with JavaScript packages when the repo goes offline: Maintain your own copy (with all the bug patching that comes with it) or have things break live in production. Python is too mature for the "move fast and break things" approach, but it is not the responsibility of the Python devs to keep unmaintained projects alive long after the code monkey teams have been downsized for great customer benefit and shareholder value.
Python 3.7 made me believe the change was worth it, before then it was chaos (understandable, under the circumstances. It wasn't perfect, but nothing is, and I think you did a good job. The additions were invaluable; love the asyncio library, it's made life worth living again). 3.9 was the real sweet spot, imo. Still waiting for a lot of libraries to properly support .10 and .11, but most of them are getting there now.
its ok, Swift 2.0 -> 3.0 broke every app written in Swift and created many many job openings cuz people just bailed and quit it was ugly, but we managed
The transition from Python 2 to Python 3 seems like a special case. I can't recall any other version jump like that in any other programming language. I mean, C++ names their versions by whatever year it came out. For example, the current C++ version is C++23 for 2023. So by those standards, there's no reason why there ever needs to be a Python 4 because naming it as such will only bring back all the negative memories of the transition from Python 2 to 3.
I love the guy… translated without nuances he says “if we had known that users were so idiot, we would have engaged in a different design strategy” 😅… by the way, never used 2 and find 3 very intuitive, coming from Fortran and Matlab
2 was good too. I started learning with 3, but I had to translate some code from 2 to make it work on version 3 a few times, and it was fine. I don't agree that users were the problem. The transition was traumatic. Suddenly all of the experience one had was not that useful anymore and a lot of code code didn't work. It is easier to think that it shouldn't be hard to start using version 3 because it is more intuitive than v2 if we ignore that the problem was never that. The problem was the hours and hours of human work that had to be done because the changes were so big and numerous
The big problem with version 2 was the vagueness of the "str" type. People used it to represent both binary data and textual data and so when the time came to put a hard separation between the two, you were kinda screwed if you were trying to pass data from a python 2 to python 3 programs
@@nnirr1 And unicode, and basestring, it was a thing that needed a pretty hard break. Which means basically everything that deals with bytes and str needs some fallback when dealing with 2/3 code. It wasn't entirely the users fault, but also the tools to do the migrations were a bit hard since it's all ducktyped the bugs could sit there and hide super well until you called the right functions. With good code coverage you could probably find them all, but not that many programs had full good code coverage so it would just sort of linger there. And the entire ecosystem needed to migrate.
Even worse, some started projects in Python2 years after Python3 had already been widely available. There will always be legacy code. (Even RPG is still used in production, on emulated mainframes running CTSS to convert between EBCDIC dialects.) But why would anyone start something new in something that is already deprecated and has a much better replacement?
If they ever make python 4.0, I wish they'd at least turn the match statement into an expression with a return value like in scala... right now its only use is branching with pattern matching, but that renders the whole construct entirely useless in a functional style codebase...
Python's "match" works just like Haskell's pattern matching, and serves the same purpose. How is that not functional style? If you need match to return something, put it in a function. Of course if "match" were an expression (like "when" and "if" in Kotlin do, like "if" in Lisp does, like the trinary infix operator from C does), it could also be used in lambdas and comprehensions, except for the syntax that doesn't fit on one line. So a function it has to be. I wouldn't call that "completely useless for functional style", even if it is a bit more cumbersome than how you would do it in a Lisp dialect.
I started learning python 2 about a year before python 3 came out, so for me it was an immediate upgrade. I didn't have a huge corporate codebase to update so I had very little to rewrite. I came from a FORTRAN/Assembly (various)/BASIC/Pascal/C/C++/Java background and python is easily the nicest to use. However, I rarely develop systems with more than a couple of thousand lines of code.
I picked up python 2.6 in 2010 and made the transition to 3.6 in about 2015. PHP must have seen what happened with Python and decided against implementing fully integrated unicode.
Python 3.10 has broken all the type hinting in the program I develop at work, so Python isn't really against breaking changes. There can be a Python 4.0 if they think it will help the language with new features that can't be implemented otherwise
Also, they stopped allowing silent boxing of lossy numbers into C-hooks. So a float being fed into an int-sized hole would break and require overt casting. This broke most of wxPython until 4.2.
You should push a major version change just to fix the list comprehension ordering. [item for item in sublist for sublist in list] is the no-brainer ordering. I've got no idea what the language designers were thinking to make the order go from most-to-least-to-most nested instead.
PHP guy here. What is such a problem in not doing hard BC breaks? We always have deprecations in minor versions and removals in major. Theoretically it's not a problem to have PHP 5.3 code compatible with 8.0
Honestly, the main feature I'd want for python 4.0 is proper block scoping. It is insane to me that they didn't fix that in the 3.0 transition, when you run into issues because of it, it makes life SO much harder. And the inconsistency is especially awful for beginners, python's target audience. I know it'll never happen, but as long as we're dreaming.
@Fearless Joy some suggest to code in a VM to reduce libraries packaged. But I don't have that option, at least in my work pc we are not allowed to create VMs. I am using auto-py-to-exe so if you know how to reduce the size without installing a fresh VM let me know.
It could be introduced in the main branch, without breaking the compatibility. If you want strong types - use them, if you don't - leave as it is today. It'll be determined during a runtime (the very same way var or auto work in other languages). They did something similar with functions. I don't think it's a major change, not even so expected one. If I were a python programmer, I'd want more switching from interpretation to compilation.
@@evanbarnes9984 That's a standard in software versioning, not particular to python, Lex just doesn't have a clue and it shows throughout the interview multiple times
I wish there could be a work-around GIL. Not being able to use multi-threading is so much pain and multi-processing is so disgustingly buggy and causes so much platform issues and on top of that its eats so much RAM. GIL is the only reason why I am liking new languages like Julia etc. GIL is one of the most annoying blocker in python innovation.
My main concern is about python interacting with Vulkan API which is not the same language unless using this "Cython". Languages like c/c++, java, rust, and other "backend" languages including assembly seem to better support Vulkan than python. But is there a way to better interface with Vulkan and upgrade the Kivy "frontend" package to support Vulkan?
Python is a language that, in the year of our lord 2022, remains structurally and unavoidably single-threaded because all the memory management would burst into tears otherwise. So instead of solving the problem they force the whole thing to be single threaded at the interpreter level, largely because Guido likes to be wrong about everything.
For Python 4.0, I'd like more of a Golang approach if it's at all possible: compile AOT to any platform, simpler syntax, better support for concurrency, and better module imports. Or at the very least, be more like Julia or Elixir: have JIT compilation for much better performance.
@@HitBoxMaster I guess to be specific, I don't really care for some of the magic methods that are used. I don't think it helps with IDEs trying to figure out how your code is structured, at least VS Code struggles with that.
There should be a Python 4.0 because things are still a mess. Asyncio is painful for one. The library uses exceptions to indicate a task has successfully completed. Python is my daily driver, but there's a lot of room for improvements.
I think Python needs to incorporate native mobile framework libraries, which should be competitive like pyqt5, kivvy or similar frameworks, but, the performance would be closed to C++. As more & more developers needs to incorporate & build apps in various popular platforms. Also, it can take the advantage of existing data science, ai, ar/VR libraries.
Building in a more complete and native way to "compile" Python scripts into standalone executables, for use on machines without a Python interpreter installed (such as e.g. a business laptop without admin rights) -- even if it only works similar to the way AutoHotkey's ahk2exe tool does, where it "bundles" the basic interpreter with the script and potentially any imported modules into one file which can run itself.
That doesn't make sense. If you can install a static executable, why can't that be a python interpreter? It is almost always smaller and faster to run a script through a VM than to compile everything into a huge EXE.
@@davidwuhrer6704 The difference is between installing and running. I can run a standalone .exe. I cannot install a development environment with all its dependencies, etc.
@@FreihEitner _> I cannot install a development environment with all its dependencies_ I'm sorry to hear that. apt install build-essentials That installs a build environment with all its dependencies. That command works in most operating systems.
I'm an extension developer. And the python imports are a mess, if you even want to support python3.xx only versions.. I want to use importlib-resources and it's a joke. I don't agree with Guido. Keep minor versions compatible. And make major versions incomparable! Ever heard about semantic versioning?
I'm don't know someone else who gives so many years to migrate to Python 3 like Guido. 2022 and Python 2? Serious? Have a trouble with coding? Everybody have a trouble and brain split 😁
Python amounts to a glue language as the real code get's written as C in the extensions - contrast that to the Java eco system where 95 plus percent of the library code that exist is written in Java itself. So going to new edge devices, say in RISC-V, the first question to ask is are the required extensions ported to the target device before can proceed. Just having Python itself running is merely a first step. And the problem with those C extensions is one come a lot more face to face in graplling with platform differences, e.g., say one wants to support Linux POSIX, Windows, MacOS - and maybe even Android and iOS (then there are a plethera of embedded device runtimes)
Most of the code runs (or could be made to run) in the cloud. Needing some code to run on Linux POSIX, Windows, MacOS, Android and iOS is an extreme edge case in the modern world. If it's unavoidable I'd rather rewrite the needed C extensions myself for the corresponding platform than use greasy Java.
You could relearn how to use print() in like... 5 seconds ;-) Also, you could write script (in Python - why not?) that will replace all print "something" to print('something') pretty easily! The language must evolve so some changes could be incompatible. Sadly.
I'm not sure why you wouldn't add new stuff to this hypothetical python 4 as long as existing python 3 code doesn't get broken. I guess it would be a strong way to make sure nothing accidentally breaks the python 3 handling.
Maybe the Python2,3 extension interface was, were not all that future proof to begin with? This is *not* a blame, on the contrary: just a thought. And what is the correlation with GIL exactly?
If it had been future proof, there would have been no 3. The GIL guarantees that no two threads access data at the same time. Some extensions may rely on that, even unintentionally.
No. Impossible. It is in fact an unsolvable problem. For common use cases there may be migration patters that can be automated by scripts, no AI required. (Like putting parentheses around print parameters in the transition to 3.) But for the general case you would have to build a data flow graph (possible, every static type checker does that), and generate equivalent code that is identical even for pathological edge cases (which are almost certainly programming errors that should be eliminated, not recreated at great expense). And because of Rice's Lemma and Murphy's Law, you can bet that a lot of those pathological edge cases are unprovable, maybe even undecidable. (Race conditions can remain undetected in production for decades.) And now you want to train an AI to do what? Decide the undecidable? Based on what training data would you do that? Even if, by some miracle, you could kluge together a tool that transitions all code without programmer interaction, what are the chances that the people who wrote it and maintain it could still read it and understand it?
@@hiltonvarian3352 I like C# but it can't do everything: * You can't write drivers * It's not a good idea to make a game engine in C#. Unity is created in C++ - C# is only for scripting ;-) There is no perfect language xD
Python core developers are all smart people, so I quite don't understand how it is possible not to foresee the mess the non-backward compatible changes would create. IMO it is just BS. It's far more likely, that the perfectly valid criticism was just ignored or rationalized away. As a result almost 15 years later people still discuss which python version should be used. I have turned down Python several times just because I don't know what version of it my target system has.
Such a BS to change the meaning of certain syntax. I still don’t see any reason why the function of xrange had to be range in Python 3, ignoring that range exists in Python 2 and works slightly different but will break the source code. Why, just why? Or the mess with str vs bytes. Seriously that was all so absolutely unnecessary changes, and were a big pain for everyone!
Nobody expected RedHat to keep using Python2.7 more than a decade after it had already been abandoned. Newer isn't always better, but ever since Python3000 has been renamed to Python3, it was obvious that the days of Python2 were numbered. python3 has been available for a long time, in FreeBSD there is no Python2, only python.
@@joachim4568 Unicode has been a pain in Python2. Python3 fixed that in a way that not only makes strings easy to use, but also much faster. Rather than converting a "str" that is a byte array to a unicode string by decoding it as UTF-8, then having to encode it back into a byte array, "are" is now UTF-8, and byte arrays are "byte", and you can still convert to other encodings if you need to, but strings are no longer ambiguous and don't require imports to work correctly.
@@DjellowmanCorporate policy. "We need the new shiny" attitude. Kids that don't know any better leaving college not seeing this type of mess in the real world. Take your pick. Py2->3 has been the bane of my existence for the last 4 years. Deep down in the guts differences are KILLING us... Things like os.seek() hitting the disk differently between 2 & 3 caused a ton of pain. As someone coming from Perl, Python is a bad joke. If Perl could install modules as easily as Python it would still be on top... Perl 5. The same Perl from the 90's... Working just fine still... Multithreaded, OO support, semi-strong typed, arrays are called arrays...
No chance to No GIL Python, we love Python not running speed, but for speed development and clean code. It's to be cool, if we have a option. Special tool to translate Python code to something like WASM with all kind of validation. But stop, I'm already have a Cython and making binding to compiled libraries! I'm already happy! In Guido we trusted! (Sorry for not best English)
I can explain. Idea is a split development and production. In development we love clean and small codebase. But production need speed and safety, we not need read code. For debug and profiling we using tools. If it's possible to translate Python code to lower level then Python pseudo code is, something like new assembly (aka WASM) and VM for it. At the beginning little minimal VM and some time later someone build platform like JBoss for corporation and so on.
Python3 didn't make people leave Python for other languages; many projects died from a lack of maintenance. If that is a problem in data science, it won't leave for other languages either.
4.0 feature request: Speed up for loops please. And a veeeeerrrrrryyyyyyy far fetched request. Make it a machine compiled language (something like Go). I know never gonna happen. So, please don't get angry.
@@md.redwanhossain8822 no no no, I did mean typed language. Honestly, I do not care about statically typed vs dynamically typed or what have you. I just want more speed from Python. It’s a wonderful language, can do all sorts of things with it. It’s just tooooooo darn slow. It’s so slow that SOME of my O(n^2) time code in different languages runs faster than python’s O(logn). And comparing apples to apples (in terms of run time complexity), python is about 10x (on avg.) slower than some other languages. If I was running my own company, I would probably never use python; except of course for ML stuff and that too mainly because under the hood it uses c++ code.
@@appledore use numba with the slower loop. For example, counting to 1 billon takes 45+ second by while/for loop in python, but if you use numba with the loop it takes less than 1 second. Numba uses a JIT compiler behind the scene.
@@appledore and you are horribly wrong, it seems like you don't know how to speed up python. Udemy, instagram, and many others very high traffic website uses python django as the backend.
Perhaps with 4.0 we can get the package/venv situation sorted out? I want to like Python, but as soon as I have to share my work with anybody, eggs and versions constantly screw things up
One of the problems with python: Packages have versions, which is good, and can depend on specific versions and version ranges, which is great, but you can't have more than one version installed in your python path, which means that instead of dependency hell because of no versioning, you have many parallel instances of dependency hell. Which would easily be solved by allowing at least minor versions to be installed and used in parallel. But I don't know how to implement that in python. Where and how would you specify that in the import statement?
@@davidwuhrer6704 That does not work. It still requires the user to perform heavy lifting.. Checking manually the python version, deal with venv, issue the install command, etc... And it can still fail at the end of that
@@thelambdafunction As long as they don't have to edit the source code to get it to compile on their system, I wouldn't call that "heavy lifting". Setting up a python path, whether using venv, pyenv, anaconda, or their own home-grown shell scripts, and then running pip -i inside that, is not heavy lifting, that's just Python. If the Python version matters at all, there are packages available going back as far as 3.7, but why wouldn't you just use whatever ships with the OS? The current stable release of Debian ships with 3.8, FreeBSD with 3.9, OpenBSD with 3.9 and 3.10, … Would you rather distribute your scripts together with the interpreter? Ship a bootable ISO image of your development environment? (Debian makes that easy to do, but that won't help if someone using an amd64 wants to collaborate with someone using an M2.) Then what's the point of using Python in the first place?
Sometime in mid-90's I wanted to learn a new language for simple calc and utilitities. Java or Python? After some try-outs, I decided to go with python, whichI never regretted since. I was an one happy camper up until python 3.0 came about. I tried a transition but I didn't like it. No 'execfile', incompatible 'pickle', 'tkinter', etc. were more than annoying. Then I heard 2.7 would be the end of my good old python. Oh, well, who cares? I (a 72 going 73) is totally disenchanted with 3.x and I have no desire (or need) to switch from 2.7. I will stick with 2.7 until I go or lose interest in tinkering, whichever comes first. I hope someone forks python 2.7 and keep it nice and simple - until kingdom comes.
hahaha! he's basically saying "we had a good plan, but the users were too dumb for it." well, we are dumb, but you were too dumb to recognize that soon enough.
python is not a bad language. The problem is the ecosystem. The tools are fairly limited, especially package managers. Not sure why, but other languages have far better dependency management. Other languages have problems with versioning too, but people have built tools to transpile code and manage dependencies.
Python poetry is actually much better than regular requirements.txt. It’s even supported by IDEs now. Pretty good but not perfect. It does check version compatibility and allows ranges of versions, update commands, etc
Full podcast episode: th-cam.com/video/-DVyjdw4t9I/w-d-xo.html
Lex Fridman podcast channel: th-cam.com/users/lexfridman
Guest bio: Guido van Rossum is the creator of Python programming language.
Halflife 3 will be coded in Python 4.0
If it has AOT compilation and takes a Golang approach, I see this very possible
@@OzzyTheGiant I thought it was joke that as half life 3, python 4 is not gonna be there
Gold
So you actually believe it will be done...
Will python 4 have better vulkan support?
Python 3 is definitely way better than python 2 and a lot of its changes were necessary. I was lucky to start learning right after the transition so I decided to just focus my learning on python 3. It was difficult to get older scripts to run because every single print statement would be broken, but I didn't have to forget stuff and relearn it. But I feel bad for those with some years of experience python 2 having to rebuild a lot of things they knew
@AstroPenguin I want kill myself when I saw such. To migrate from Python 2 to 3 so many tools! And not just it, also you have new print function and so on using "from future import ...". And so many fast methods to migration from internet. If you are not author TH-cam project or something similar then even if you have a big project it's a one month working. Off course it's to my opinion
Yeah, I had a few libraries that needed to be written py2-3 compatible that sort of tight-rope nonsense was annoying. Bits of code that would crash get caught, comment that this is python 2 code and then do the other stuff.
May be that I'm not right. Two things may stop your migration. It's a huge codebase (tons of code) and playing with specific things like low level programming or so. Otherwise may be you try to migrate to fast. Not Python 2 -> Python 3.x, when x is 0-1. Python 3 changed a lot. More than 10 year, I'm writing Python 3. After Python 2.7 I'm not so happy in period of Python 3.0-3.5, but beginning from Python 3.5 is awesome.
I can not understand. Technically simple things like print "" to print("") not problem to migrate even to millions lines of code. Just use good tool. Harder migrate typing problem like strings from ascii to utf, you can't just swap code because string manipulation may be various. But we have a tool not for migrate, but code analyzer to see problematic code like that. In conference that I see many years ago such tools presents from mans who migrate there not little projects from Python 2.x. You may search Pycon early years
_> I feel bad for those with some years of experience python 2 having to rebuild a lot of things they knew_
I don't. Being a programmer means constantly having to learn new things. Some things stand the test if time, python 2 is not one of those things. If you are not willing to learn a better way, you are in the wrong business.
I'd love to see a no-GIL mode. Mind you half the extension maintainers would still ignore the warning that it's coming for several years unless half their users are using the no-GIL version. There's a battery icon program I really liked, but I finally had to stop using it because it never made the transition to Python 3...
no-GIL + compile-type reflection + easier C/C++/native ABI bindings are the killer features that Python 4 should have. All things that Nim has while being stable since 2019 though.
@@FrankHarwald Nim doesn't have nearly as big 3rd party support or userbase though. Python supporting these would be HUGE.
@@FrankHarwald You can already get easy C/C++ bindings if you use pybind11 Incredible easy to use and very tight and correct binding.
There's always nim that you could use instead
Is there a list of relatively complete software that never got a python 3 conversion? I could certainly see that as a reasonable set of projects since it's not too hard to see where the breaks are. I think bCNC was still py2 compatible (my svg parsing code is used there and I backported it here and there to py2 just for that project after I finished it up).
"Did you shed a tear?"
"No, we danced on its grave!"
If there ever was a Python 4.0 ALL I want, the ONLY thing I want or care about is speed/ performance. I want to be able to write high performance Python code. However they can manage that, whatever they need to do to accomplish that, if they do that's what I would want.
You would need to do more than no gil to make python really performant. I would help for certain types of code in certain scenarios, but a big reason pyton is so slow is that 'everything is an object in Python' and every Python object is stored on heap (stack allocation is much faster and from a pure performance standpoiunt would be the default approach).
Every time I come on this dudes video when he talks about programming, there's a hoard of javascript weirdos talking about how great js is.
It is lolllll... Joking aside, the issue that happens in this video (backward compatibility) is handled gracefully in JS... New ecmascript specification never breaks backward compatibility
@@farrellraafi1301 is it good enough, that if one is used to PHP for backend programming that the switch to node JS is worth it ?
Why would you come on a video like this? It's not remotely arousing
@@Djellowman ?????????? I'm not looking for porn...
@@aburoach9268 if it was 5 years ago maybe stick with PHP for a easy backend setup, but with serverless, new better backend and CMS frameworks, typescript, ORMs, and databases that connect directly with JavaScript, node is the way to go. PHP main advantage now just seems to be WordPress in my opinion.
Let‘s do Python 4 and break again the compatibility! 🎊🎉
Any projects not willing to migrate have the choice between maintaining their own fork of python3 or dying.
Like with JavaScript packages when the repo goes offline: Maintain your own copy (with all the bug patching that comes with it) or have things break live in production.
Python is too mature for the "move fast and break things" approach, but it is not the responsibility of the Python devs to keep unmaintained projects alive long after the code monkey teams have been downsized for great customer benefit and shareholder value.
They should bring in the Linq-like features in C# without any 3rd party packages in version 4.
This would be so awesome
Python 3.7 made me believe the change was worth it, before then it was chaos (understandable, under the circumstances. It wasn't perfect, but nothing is, and I think you did a good job. The additions were invaluable; love the asyncio library, it's made life worth living again). 3.9 was the real sweet spot, imo. Still waiting for a lot of libraries to properly support .10 and .11, but most of them are getting there now.
3.10 has some very interesting additions to asyncio
@@christopheroverbeck3662 could you please elaborate on what you find interesting about asyncio? I'm curious as I used that library quite often :)
@@alexkim5089 Mainly Task Group context manager.
@@christopheroverbeck3662 Thanks I'm gonna have to look into this version.
match sys.version.minor: case 9: ...
its ok, Swift 2.0 -> 3.0 broke every app written in Swift and created many many job openings cuz people just bailed and quit
it was ugly, but we managed
🤣
This is the way.
The transition from Python 2 to Python 3 seems like a special case. I can't recall any other version jump like that in any other programming language. I mean, C++ names their versions by whatever year it came out. For example, the current C++ version is C++23 for 2023. So by those standards, there's no reason why there ever needs to be a Python 4 because naming it as such will only bring back all the negative memories of the transition from Python 2 to 3.
Perl 5 to Perl 6 was the same. It was two different versions completely
Removing the GIL and still having the core API stay the same is probably the only thing that would justify a 4.0 release
3.13 tries to do that (and JIT compiler).
I love the guy… translated without nuances he says “if we had known that users were so idiot, we would have engaged in a different design strategy” 😅… by the way, never used 2 and find 3 very intuitive, coming from Fortran and Matlab
2 was good too. I started learning with 3, but I had to translate some code from 2 to make it work on version 3 a few times, and it was fine. I don't agree that users were the problem. The transition was traumatic. Suddenly all of the experience one had was not that useful anymore and a lot of code code didn't work. It is easier to think that it shouldn't be hard to start using version 3 because it is more intuitive than v2 if we ignore that the problem was never that. The problem was the hours and hours of human work that had to be done because the changes were so big and numerous
The big problem with version 2 was the vagueness of the "str" type. People used it to represent both binary data and textual data and so when the time came to put a hard separation between the two, you were kinda screwed if you were trying to pass data from a python 2 to python 3 programs
@@nnirr1 And unicode, and basestring, it was a thing that needed a pretty hard break. Which means basically everything that deals with bytes and str needs some fallback when dealing with 2/3 code. It wasn't entirely the users fault, but also the tools to do the migrations were a bit hard since it's all ducktyped the bugs could sit there and hide super well until you called the right functions. With good code coverage you could probably find them all, but not that many programs had full good code coverage so it would just sort of linger there. And the entire ecosystem needed to migrate.
Some monsters still use Python 2 in production code.
Even worse, some started projects in Python2 years after Python3 had already been widely available.
There will always be legacy code. (Even RPG is still used in production, on emulated mainframes running CTSS to convert between EBCDIC dialects.)
But why would anyone start something new in something that is already deprecated and has a much better replacement?
If they ever make python 4.0, I wish they'd at least turn the match statement into an expression with a return value like in scala... right now its only use is branching with pattern matching, but that renders the whole construct entirely useless in a functional style codebase...
I know right!
It is also nice to unpack things but yeah having it return something would be very nice
Because you should use if...else. there is no good reason to use match case except in pattern matching
I would love this
Python's "match" works just like Haskell's pattern matching, and serves the same purpose. How is that not functional style? If you need match to return something, put it in a function.
Of course if "match" were an expression (like "when" and "if" in Kotlin do, like "if" in Lisp does, like the trinary infix operator from C does), it could also be used in lambdas and comprehensions, except for the syntax that doesn't fit on one line. So a function it has to be.
I wouldn't call that "completely useless for functional style", even if it is a bit more cumbersome than how you would do it in a Lisp dialect.
I started learning python 2 about a year before python 3 came out, so for me it was an immediate upgrade. I didn't have a huge corporate codebase to update so I had very little to rewrite. I came from a FORTRAN/Assembly (various)/BASIC/Pascal/C/C++/Java background and python is easily the nicest to use. However, I rarely develop systems with more than a couple of thousand lines of code.
I picked up python 2.6 in 2010 and made the transition to 3.6 in about 2015. PHP must have seen what happened with Python and decided against implementing fully integrated unicode.
Python 3.10 has broken all the type hinting in the program I develop at work, so Python isn't really against breaking changes. There can be a Python 4.0 if they think it will help the language with new features that can't be implemented otherwise
I was also very surprised by that
Also, they stopped allowing silent boxing of lossy numbers into C-hooks. So a float being fed into an int-sized hole would break and require overt casting. This broke most of wxPython until 4.2.
Why did you scrub your interview of William MacAskill Effective Altruism (episode 84) from everywhere??
Because it's propaganda, like everything on TH-cam, the embarrassing stuff get's removed lest it cause people to ask questions.
No GIL, compiled and strongly typed Python with no changes to the syntax would be amazing.
So Scala basically
Have a look at nim then!
Julia, I would say
Python 3.13:
* No GIL (experimental)
* JIT Compiler (very experimental)
You can compile strongly typed python with mypyc !
You should push a major version change just to fix the list comprehension ordering. [item for item in sublist for sublist in list] is the no-brainer ordering. I've got no idea what the language designers were thinking to make the order go from most-to-least-to-most nested instead.
It would be cool to remove the GIL but I guess that will break many applications that implicitly rely on it today...
PHP guy here. What is such a problem in not doing hard BC breaks? We always have deprecations in minor versions and removals in major. Theoretically it's not a problem to have PHP 5.3 code compatible with 8.0
Python does occasionally break stuff. The changes between 2 and 3 were architectural.
Honestly, the main feature I'd want for python 4.0 is proper block scoping. It is insane to me that they didn't fix that in the 3.0 transition, when you run into issues because of it, it makes life SO much harder. And the inconsistency is especially awful for beginners, python's target audience.
I know it'll never happen, but as long as we're dreaming.
I have never had a problem that block scoping would solve. What practical problems have you run into?
Love Python, it helps me a lot.
Yeah lex ive been trying to listen to all your old stuff, and 84 is gone now, anywhere i can see it?
I just want a smaller one file package.
@Fearless Joy how
explain
@Fearless Joy some suggest to code in a VM to reduce libraries packaged. But I don't have that option, at least in my work pc we are not allowed to create VMs. I am using auto-py-to-exe so if you know how to reduce the size without installing a fresh VM let me know.
I would like Linus Torvalds to come up with a new version of C which is functional with imperative wrapper layer, and with a Assembly like syntax.
For Python 4.0 is Nim 2.0 I hope to see more widespread adoption of Nim, but I love both languages.
Add sort of goroutines to Nim, make it stable - and it would be the best lang ever ))
Python4 should be typed Python 3 and developed in parallel
It could be introduced in the main branch, without breaking the compatibility. If you want strong types - use them, if you don't - leave as it is today. It'll be determined during a runtime (the very same way var or auto work in other languages). They did something similar with functions. I don't think it's a major change, not even so expected one. If I were a python programmer, I'd want more switching from interpretation to compilation.
Isn’t mypy enough?
@@Barzi2001 no
That's Correct and why he hard to make truly 4.0 version,all of those C based modules will all rewrite.
Good news everyone!
Read changelog for 3.13
No types but JIT and no GIL ;-)
Lex as always no clue we are already passed 3.9😂
I was thrown off by the python numbering scheme. When I first saw 3.10, I was like, that's less than 3.9, did we go backwards?
@@evanbarnes9984 That's a standard in software versioning, not particular to python, Lex just doesn't have a clue and it shows throughout the interview multiple times
It’s literally a number. Who cares.
@@brydust computers care about numbers
its the AI making us think its human error
I wish there could be a work-around GIL. Not being able to use multi-threading is so much pain and multi-processing is so disgustingly buggy and causes so much platform issues and on top of that its eats so much RAM. GIL is the only reason why I am liking new languages like Julia etc. GIL is one of the most annoying blocker in python innovation.
My main concern is about python interacting with Vulkan API which is not the same language unless using this "Cython". Languages like c/c++, java, rust, and other "backend" languages including assembly seem to better support Vulkan than python. But is there a way to better interface with Vulkan and upgrade the Kivy "frontend" package to support Vulkan?
Can someone explain what is no guild mode in python?
Python is a language that, in the year of our lord 2022, remains structurally and unavoidably single-threaded because all the memory management would burst into tears otherwise. So instead of solving the problem they force the whole thing to be single threaded at the interpreter level, largely because Guido likes to be wrong about everything.
For Python 4.0, I'd like more of a Golang approach if it's at all possible: compile AOT to any platform, simpler syntax, better support for concurrency, and better module imports. Or at the very least, be more like Julia or Elixir: have JIT compilation for much better performance.
What part exactly you want a simpler syntax? Because python syntax is as simple as it gets already
@@HitBoxMaster I guess to be specific, I don't really care for some of the magic methods that are used. I don't think it helps with IDEs trying to figure out how your code is structured, at least VS Code struggles with that.
@@OzzyTheGiant Magic methods are kind of the point of using Python
I ONLY use Python with JIT compilation… be Numba or pypy… really fast.
@@OzzyTheGiant Which magic methods should be removed?
There should be a Python 4.0 because things are still a mess. Asyncio is painful for one. The library uses exceptions to indicate a task has successfully completed. Python is my daily driver, but there's a lot of room for improvements.
Yeah, Python completely underestimated the importance of compatibility. Something the Swift team didn't underestimate.
I think Python needs to incorporate native mobile framework libraries, which should be competitive like pyqt5, kivvy or similar frameworks, but, the performance would be closed to C++. As more & more developers needs to incorporate & build apps in various popular platforms. Also, it can take the advantage of existing data science, ai, ar/VR libraries.
Building in a more complete and native way to "compile" Python scripts into standalone executables, for use on machines without a Python interpreter installed (such as e.g. a business laptop without admin rights) -- even if it only works similar to the way AutoHotkey's ahk2exe tool does, where it "bundles" the basic interpreter with the script and potentially any imported modules into one file which can run itself.
That doesn't make sense. If you can install a static executable, why can't that be a python interpreter?
It is almost always smaller and faster to run a script through a VM than to compile everything into a huge EXE.
@@davidwuhrer6704 The difference is between installing and running. I can run a standalone .exe. I cannot install a development environment with all its dependencies, etc.
@@FreihEitner
_> I cannot install a development environment with all its dependencies_
I'm sorry to hear that.
apt install build-essentials
That installs a build environment with all its dependencies. That command works in most operating systems.
Thank you for this content. Many thanks.
I'm imagining the django developer, pandas, numpy and others, such pain to migrato to 4.0 hahah, imagine the error handlers and everything
I would like to see a new compression method for huge data files. like built-in ORC.
python 7 patch note: interpreter is now able to subjectively experience true love
I'm an extension developer. And the python imports are a mess, if you even want to support python3.xx only versions.. I want to use importlib-resources and it's a joke. I don't agree with Guido. Keep minor versions compatible. And make major versions incomparable! Ever heard about semantic versioning?
I'm don't know someone else who gives so many years to migrate to Python 3 like Guido. 2022 and Python 2? Serious? Have a trouble with coding? Everybody have a trouble and brain split 😁
@@GreyFoxTube Indeed. But OP's point is that Python seems to treat the minor version as a major version.
Python amounts to a glue language as the real code get's written as C in the extensions - contrast that to the Java eco system where 95 plus percent of the library code that exist is written in Java itself.
So going to new edge devices, say in RISC-V, the first question to ask is are the required extensions ported to the target device before can proceed. Just having Python itself running is merely a first step.
And the problem with those C extensions is one come a lot more face to face in graplling with platform differences, e.g., say one wants to support Linux POSIX, Windows, MacOS - and maybe even Android and iOS (then there are a plethera of embedded device runtimes)
Most of the code runs (or could be made to run) in the cloud. Needing some code to run on Linux POSIX, Windows, MacOS, Android and iOS is an extreme edge case in the modern world. If it's unavoidable I'd rather rewrite the needed C extensions myself for the corresponding platform than use greasy Java.
6:40 low on maintainers
imagine a python like code that runs as fast as c++, that'd be a a great python upgrade.
Google "Julia language" ;-)
If you really need Python and not "almost Python" - google "PyPy".
what change?? now we can
print "hello" OR
just
print hello
is it now backward compatible
p2 and p3 suck bcoz print is allready different
You could relearn how to use print() in like... 5 seconds ;-)
Also, you could write script (in Python - why not?) that will replace all print "something" to print('something') pretty easily!
The language must evolve so some changes could be incompatible. Sadly.
I'm not sure why you wouldn't add new stuff to this hypothetical python 4 as long as existing python 3 code doesn't get broken. I guess it would be a strong way to make sure nothing accidentally breaks the python 3 handling.
Usually those things would just be 3.x, python 4 would be specifically for breaking changes
@@lmao4982 exactly.
@@lmao4982 PHP is in version 8 but most 5.1 code would still run on it. CPP 2017 will still compile most ANSI C. It shouldn't break all changes.
@@ea_naseer good exception but lmao is correct, usually package names follow the following z.x.y - y minor fix, x new feature, z breaks previous z
Backwards compatibility is not magic.
Can't they just chill... I barely recovered from the switch to 3
They are NOT planning to make Python 4 any time soon! ;-)
Maybe the Python2,3 extension interface was, were not all that future proof to begin with? This is *not* a blame, on the contrary: just a thought. And what is the correlation with GIL exactly?
If it had been future proof, there would have been no 3.
The GIL guarantees that no two threads access data at the same time. Some extensions may rely on that, even unintentionally.
Something like cargo but for python (centralized tooling) would be a boon as well
dude pypi exists
I see you never used pip install.
I feel sorry for your fingers.
such a high quality weed...
lol everyone missed his point
oh you meant build and distribution systems?
we do have poetry tho
We’re still using 2.7 at our company 🤣.
Apologies for the 2.x users, but Python 3 was a bloody blessing
Packet management, Packet management, Damn Packet management. I can't install any projects in Debian. except dockerized.
Lol the initial response 🤣 Yeeaaahh.....
Can an AI take charge of changes like Python 3 to 4? I guess not too many years for such.
No. Impossible.
It is in fact an unsolvable problem. For common use cases there may be migration patters that can be automated by scripts, no AI required. (Like putting parentheses around print parameters in the transition to 3.)
But for the general case you would have to build a data flow graph (possible, every static type checker does that), and generate equivalent code that is identical even for pathological edge cases (which are almost certainly programming errors that should be eliminated, not recreated at great expense).
And because of Rice's Lemma and Murphy's Law, you can bet that a lot of those pathological edge cases are unprovable, maybe even undecidable. (Race conditions can remain undetected in production for decades.)
And now you want to train an AI to do what? Decide the undecidable? Based on what training data would you do that?
Even if, by some miracle, you could kluge together a tool that transitions all code without programmer interaction, what are the chances that the people who wrote it and maintain it could still read it and understand it?
Pithon 3.14159?
Next he should interview Garry Kasparov about Chess 2
make it compiler language
Agree!
The closest things that we have today are Rust and Go.
Go is more like Python tho. Both are compiled to machine code.
C# is A compiler Language to.Also an Object Orientated Program. Can do Anything. From Web Development to Game Development to Application Creation.
@@hiltonvarian3352 I like C# but it can't do everything:
* You can't write drivers
* It's not a good idea to make a game engine in C#. Unity is created in C++ - C# is only for scripting ;-)
There is no perfect language xD
@@igorthelight exactly, but Go syntax sucks ass
@@hiltonvarian3352 lol nooo, screw object oriented programing. You can use objects in Python but it doesn't forces you into it, as java and c# do.
Python 4.0 written in Rust.
Not patriotic, I' wanna to be seen next Rust written in Python x.x 😆. It's joke but ...
Python core developers are all smart people, so I quite don't understand how it is possible not to foresee the mess the non-backward compatible changes would create. IMO it is just BS. It's far more likely, that the perfectly valid criticism was just ignored or rationalized away. As a result almost 15 years later people still discuss which python version should be used. I have turned down Python several times just because I don't know what version of it my target system has.
Such a BS to change the meaning of certain syntax. I still don’t see any reason why the function of xrange had to be range in Python 3, ignoring that range exists in Python 2 and works slightly different but will break the source code. Why, just why? Or the mess with str vs bytes. Seriously that was all so absolutely unnecessary changes, and were a big pain for everyone!
Nobody expected RedHat to keep using Python2.7 more than a decade after it had already been abandoned.
Newer isn't always better, but ever since Python3000 has been renamed to Python3, it was obvious that the days of Python2 were numbered. python3 has been available for a long time, in FreeBSD there is no Python2, only python.
@@joachim4568 Unicode has been a pain in Python2. Python3 fixed that in a way that not only makes strings easy to use, but also much faster.
Rather than converting a "str" that is a byte array to a unicode string by decoding it as UTF-8, then having to encode it back into a byte array, "are" is now UTF-8, and byte arrays are "byte", and you can still convert to other encodings if you need to, but strings are no longer ambiguous and don't require imports to work correctly.
@L venv is not a sandbox.
Typeon. Typhon. Tython. 🧐
@@cpycpycpy Hahaha!
Kind of a click-bait title, they spent very little time on the idea of a 4.0, but good discussion!
What is "no guild Python"?
no GIL python
@@martinsjoborg4950 referring to "global interpreter lock"?
@@LOogt Yes
Mojo is the de facto Python 4.0
I'm still on python 2.7
Why tho?
@@igorthelight because Maya
Maya supports Python 3 now ;-)
Not sure for how long.
Rename id and hash and let us access function variables
He didn't realize the 2to3 transition would be painful especially for unmaintained projects? I been sayin' it fer ten damn years.
Why can't you just keep on using the python2 interpeter?
@@Djellowman really why you cannot keep using python2 interpreter?
@@stone8905 That was indeed my question.
@@Djellowman sorry dude, I should have tagged him not you.
@@DjellowmanCorporate policy. "We need the new shiny" attitude. Kids that don't know any better leaving college not seeing this type of mess in the real world. Take your pick. Py2->3 has been the bane of my existence for the last 4 years. Deep down in the guts differences are KILLING us... Things like os.seek() hitting the disk differently between 2 & 3 caused a ton of pain. As someone coming from Perl, Python is a bad joke. If Perl could install modules as easily as Python it would still be on top... Perl 5. The same Perl from the 90's... Working just fine still... Multithreaded, OO support, semi-strong typed, arrays are called arrays...
No chance to No GIL Python, we love Python not running speed, but for speed development and clean code. It's to be cool, if we have a option. Special tool to translate Python code to something like WASM with all kind of validation. But stop, I'm already have a Cython and making binding to compiled libraries! I'm already happy! In Guido we trusted! (Sorry for not best English)
I can explain. Idea is a split development and production. In development we love clean and small codebase. But production need speed and safety, we not need read code. For debug and profiling we using tools. If it's possible to translate Python code to lower level then Python pseudo code is, something like new assembly (aka WASM) and VM for it. At the beginning little minimal VM and some time later someone build platform like JBoss for corporation and so on.
Python 4 will be released when AI is intrinsic to it.
We need performance in python more then ever
Good news everyone!
Read changelog for 3.13 ;-)
Forget Python, when is BlackMamba coming out? Same as Python but even simpler and much faster.
I miss --> print "hello world"
I just found my new sound machine to sleep
He looks like Old Age Professor of Money Heist 😂
And will it be backwards compatible? 😭😭
Nogil 4.0 will make whole data science community leave python due to breaking cpyext. They'll probably move to nim and rust
Python3 didn't make people leave Python for other languages; many projects died from a lack of maintenance. If that is a problem in data science, it won't leave for other languages either.
@@davidwuhrer6704 good point, many left to go and node for a few years till python 3.8
Good news everyone!
Read changelog for 3.13 ;-)
Just hope python goes into the no GIL mode
Good news everyone!
Read changelog for 3.13 ;-)
Yes
What we need is a thirst for speed. Python is a bit sllooowwww....
You are right so after 4 years working with python i switch to Rust . It is true Rust is better than python
@@greekapostle4548 Apples and oranges
@@roganmorrow yeah it's a ridiculous comparison. It's like asking "what's better a hammer or a screw driver?"
😍
python is "faster when its uses librarys written in c. on my raspberry pi i switched to nodejs to get speed and less memory usage.
using multiple cores natively
Good news everyone!
Read changelog for 3.13 ;-)
I see python 4 with speed of Julia language.
4.0 feature request: Speed up for loops please.
And a veeeeerrrrrryyyyyyy far fetched request. Make it a machine compiled language (something like Go). I know never gonna happen. So, please don't get angry.
you don't need a typed language, a JIT compiler would be enough for python.
@@md.redwanhossain8822 no no no, I did mean typed language. Honestly, I do not care about statically typed vs dynamically typed or what have you. I just want more speed from Python. It’s a wonderful language, can do all sorts of things with it. It’s just tooooooo darn slow.
It’s so slow that SOME of my O(n^2) time code in different languages runs faster than python’s O(logn). And comparing apples to apples (in terms of run time complexity), python is about 10x (on avg.) slower than some other languages.
If I was running my own company, I would probably never use python; except of course for ML stuff and that too mainly because under the hood it uses c++ code.
@@md.redwanhossain8822 oh and I like your JIT point.
It can help in speed up a lot.
@@appledore use numba with the slower loop. For example, counting to 1 billon takes 45+ second by while/for loop in python, but if you use numba with the loop it takes less than 1 second. Numba uses a JIT compiler behind the scene.
@@appledore and you are horribly wrong, it seems like you don't know how to speed up python. Udemy, instagram, and many others very high traffic website uses python django as the backend.
Perhaps with 4.0 we can get the package/venv situation sorted out?
I want to like Python, but as soon as I have to share my work with anybody, eggs and versions constantly screw things up
One of the problems with python: Packages have versions, which is good, and can depend on specific versions and version ranges, which is great, but you can't have more than one version installed in your python path, which means that instead of dependency hell because of no versioning, you have many parallel instances of dependency hell. Which would easily be solved by allowing at least minor versions to be installed and used in parallel.
But I don't know how to implement that in python. Where and how would you specify that in the import statement?
To solve your problem, export a requirements list.
@@davidwuhrer6704 That does not work. It still requires the user to perform heavy lifting.. Checking manually the python version, deal with venv, issue the install command, etc... And it can still fail at the end of that
@@thelambdafunction As long as they don't have to edit the source code to get it to compile on their system, I wouldn't call that "heavy lifting".
Setting up a python path, whether using venv, pyenv, anaconda, or their own home-grown shell scripts, and then running pip -i inside that, is not heavy lifting, that's just Python.
If the Python version matters at all, there are packages available going back as far as 3.7, but why wouldn't you just use whatever ships with the OS? The current stable release of Debian ships with 3.8, FreeBSD with 3.9, OpenBSD with 3.9 and 3.10, …
Would you rather distribute your scripts together with the interpreter? Ship a bootable ISO image of your development environment? (Debian makes that easy to do, but that won't help if someone using an amd64 wants to collaborate with someone using an M2.)
Then what's the point of using Python in the first place?
Container? Surely, that solves the problem.
Sometime in mid-90's I wanted to learn a new language for simple calc and utilitities. Java or Python? After some try-outs, I decided to go with python, whichI never regretted since. I was an one happy camper up until python 3.0 came about. I tried a transition but I didn't like it. No 'execfile', incompatible 'pickle', 'tkinter', etc. were more than annoying. Then I heard 2.7 would be the end of my good old python. Oh, well, who cares? I (a 72 going 73) is totally disenchanted with 3.x and I have no desire (or need) to switch from 2.7. I will stick with 2.7 until I go or lose interest in tinkering, whichever comes first. I hope someone forks python 2.7 and keep it nice and simple - until kingdom comes.
Essentially what he is saying is that he has no confidence that the team can learn from their mistakes, so they simply won't try again.
Sometimes I think someone is stopping me using computers. LoL and I don't know who he is and where he is now. Does someone feel same as me.
hahaha!
he's basically saying "we had a good plan, but the users were too dumb for it."
well, we are dumb, but you were too dumb to recognize that soon enough.
python is not a bad language. The problem is the ecosystem.
The tools are fairly limited, especially package managers. Not sure why, but other languages have far better dependency management.
Other languages have problems with versioning too, but people have built tools to transpile code and manage dependencies.
Python poetry is actually much better than regular requirements.txt. It’s even supported by IDEs now. Pretty good but not perfect. It does check version compatibility and allows ranges of versions, update commands, etc
python without a GIL -> the dream!
Good news everyone!
Read changelog for 3.13 ;-)
Wtf his voice is serious af.
This guy is prodigy
Another Python "Great Reset". Can't fucking wait.... (:
Make python 4.0 based on rust
It would make removing the GIL easier because Rust is designed with thread-safety in mind.
but Rust is nothing like Python...
@@trex511ft "based on Rust" doesn't mean "Rust-like". It means "use Rust under the hood instead of C".
Yes - Python uses C under the hood!
@@igorthelight Ok, I got it now, thanks.
Pywhat?
Don't encourage him Lex!!
Native GUI
Python 4.0? That’s what I call my tiny 4” ….