6 ms·
> Don't get your hopes up about Python 4.0 Who thinks like this? Computer numerologists? Surely what matters is feature support and quality, not big version nu
by svantana 5y ago
> Don't get your hopes up about Python 4.0
Who thinks like this? Computer numerologists? Surely what matters is feature support and quality, not big version numbers. I for one am glad that python is stabilizing and old(ish) code tends to work well.
- pansa2 5y agoPeople who want to see backwards-incompatible changes, e.g. GIL removal, language & stdlib cleanups, or even mandatory static typing?
- d3ckard 5y agoWhy GIL removal would be necessarily breaking?
- m_mueller 5y agoI imagine it would likely introduce subtle behavior changes in how concurrency works.
- rurban 5y agoNot behavior, but struct layouts. Since python (as well as most other such scripting toys) never thought about proper enhancement paths, their API works by exposing headers with the structs, and not many abstract types with functional interfaces, you cannot change much. With functions only it would have been easy
- pansa2 5y agoThe only way to remove the GIL without breaking existing multithreaded code is to replace it with multiple smaller locks. That approach is considered unacceptable because the small locks introduce substantial overhead.
- needusername 5y agoWhy? Java has no GIL and runs faster than Python.
- chrisseaton 5y agoJava has different semantics to Python. To make Python run fast without a GIL you'd have to change the semantics to be more like Java's, which would be a breaking change, which would mean Python 4.0, which is what they say we're unlikely to get.
- dekhn 5y agoIronPython, based on CLR and .NET, was faster than Python and didn't have a GIL.
- deleted 5y ago[deleted]
- pansa2 5y agoIIRC it included a JIT compiler, which was fast enough to offset the overhead of fine-granularity locking.
- zerkten 5y agoYou have to consider the use case in addition to the technology. The relatively simple implementation of CPython ensures you have fast startup, but trade-off other optimizations which affect long-running programs. Lots of Python scripts only run for a short time. Code in the REPL needs to return results really quickly. The .NET JIT added significant startup costs to the point where the IronPython team had to add an interpreted mode for first runs before handing off the JIT. This is complex and arguably takes time away from CPython compatibility work. It seems that the .NET team is coming around to the concerns around startup time, but I don't know if they have landed on an AOT solution. It probably will help executables running on .NET Core more than scripts running under IronPython. I've not kept up with JITs very much, but I don't think this pattern is limited to the .NET JIT, and is a general trade-off. I feel like JavaScript JITs may be closer to what IronPython would have wanted though.
- formerly_proven 5y agoThe GIL is baked into the C API. There's the performance argument as well, though that doesn't seem as fundamental to me (i.e. a sufficiently smart team of engineers might find a way around that).
- IgorPartola 5y agoSo people want Nim?
- pansa2 5y agoIs Nim particularly similar to Python? More than Go, which Guido recently described as being the new language that’s most Pythonic? https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1472s https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1472s
- IgorPartola 5y agoNim uses Python-like syntax but is statically typed. It explicitly lists Python as one of its main inspirations.
- nimmer 5y agoCompared to Go it really feels way closer to Python.
- monkeybutton 5y agoI just want to be able to deploy a flask app that responds to a lot of CPU-intensive requests (making inference from ML models) that takes advantage of modern CPUs that have a stupid number of cores, without having to pay the memory overhead of duplicating the entire process' memory space N-times. Native threads would totally fix this inefficiency but the GIL breaks it. Java and .Net would be more appropriate in this production environment but they don't have the same eco-system of packages and we also don't want to pay the development cost of re-writing people's notebooks into another language and all the problems that entails. So instead, our server VMs consume a ton of unnecessary memory. /rant
- d0mine 5y agoIs the interpreter own memory size a real concern in ML application?
- andrepd 5y agoThen consider writing your application in something other than a scripting language. If you're too “lazy” to write in a lower-level language don't complain when you're application is several times slower and takes several times more memory than it could.
- chrisseaton 5y ago> Who thinks like this? Computer numerologists? Surely what matters is feature support and quality, not big version numbers. I don't think anyone's interested literally because it's a bigger number - you're responding to an imaginary argument nobody made. People could be interested in Python 4 because they want another opportunity to make substantial breaking changes for the better, which you can only do on a major increment. An example could be something like removing the GIL. (Not saying that'd be a good idea or not.)
- formerly_proven 5y ago> I don't think anyone's interested literally because it's a bigger number - you're responding to an imaginary argument nobody made. Yet when some browser (Chrome) switched to Very Big Version Numbers, all other browsers followed suit and matched those version numbers very closely. So clearly there is marketing behind version numbers.
- viraptor 5y agoI don't think the browser change was due to marketing (or not only). They needed a steady release stream that people just accepted, rather than holding off on installing 5.0, because that's a big change from 4.19. They release often now with many internal changes each time and the version number became pretty much meaningless. Chrome now releases with "I don't care about your distro release schedule" cadence.
- svantana 5y ago> an imaginary argument The article is written like there are people that want python 4 regardless of what features it has. And I know from experience that there are plenty of people out there that want new shiny versions of software, but when asked what is wrong with the current release, they can't say.
- deleted 5y ago[deleted]
- 5y ago
- delaaxe 5y agoIt’s about breaking changes, not numbers per se
- dagw 5y agoSurely what matters is feature support and quality, not big version numbers Anybody else remember when Solaris jumped from version 2.6 to version 7 because they didn't want to have a smaller version number than Red Hat?
- pansa2 5y agoSee also Windows 10, so named because they didn’t want to have a smaller version number than macOS X. What will they do now Big Sur is macOS 11?
- MR4D 5y agoWe'll find out on the 24th https://www.theverge.com/2021/6/3/22466394/microsoft-windows-11-launch-teaser-rumors https://www.theverge.com/2021/6/3/22466394/microsoft-windows...
- pimlottc 5y agoDevelopers are always tempted by the idea of the Big Rewrite That Will Finally Fix Everything. Language designers are no different.