How Python Now Manages Its Evolution (techradar.com) 62
For roughly a year and a half software engineer Pablo Galindo has been one of five members on the Python Steering Council, which took the reins when language creator Guido van Rossum stepped down. "The Python Steering Council attempts to reflect the decisions of the community, weighing up all the advantages and disadvantages [of each proposal]," Galindo explains in TechRadar's look at how the language now manages its evolution. (Alternate URL here.)
"Our responsibility is to make sure everyone is represented in a decision. It's not about what we think personally, it's about the community mind." So while static typing would've benefited one specific sub-community, the article argues, the necessary changes were ultimately "deemed by the council to have an overall detrimental effect," the article points out, "and were therefore rejected." Given the popularity of Python and size of the application base, the Steering Council has to exercise considerable caution when deciding upon changes to the language. Broadly, the goal is to improve the level of performance and range of functionality in line with the demands of the community, but doing so is rarely straightforward. "There is an important distinction between making a new language fast, versus increasing the performance of a 30-year-old language without breaking the code," noted Galindo. "That is extremely difficult; I cannot tell you how difficult it is."
"There are a number of industry techniques that everyone uses [to improve performance], but Python is incompatible with these methods. Instead, we have to develop entirely new techniques to achieve only similarly good results."
Separately, the team has to worry about the knock-on effects of a poorly-implemented change, of which there could be many. As an example, Galindo gestured towards the impact of a drop-off in language performance on energy usage (and therefore carbon emissions). "When you make changes in the language, it can be daunting," he said. "How many CPU cycles will I cost the planet with a mistake...?"
Despite the various headwinds, the Python Steering Council has lofty ambitions for the language, with the next major release (version 3.11) set to go live in October. Apparently, speed is the first item on the agenda. Galindo told us the aim is to improve performance by up to 60% (depending on the workload) with Python 3.11 and again with version 3.12. In the longer term, meanwhile, the goal is to make the language between two and five times faster within the next decade.
The council will also continue to focus on improving the quality of error messages generated by the Python Interpreter in an effort to make debugging much simpler, a pet project of Galindo's and a major focus during his time on the council.
"Our responsibility is to make sure everyone is represented in a decision. It's not about what we think personally, it's about the community mind." So while static typing would've benefited one specific sub-community, the article argues, the necessary changes were ultimately "deemed by the council to have an overall detrimental effect," the article points out, "and were therefore rejected." Given the popularity of Python and size of the application base, the Steering Council has to exercise considerable caution when deciding upon changes to the language. Broadly, the goal is to improve the level of performance and range of functionality in line with the demands of the community, but doing so is rarely straightforward. "There is an important distinction between making a new language fast, versus increasing the performance of a 30-year-old language without breaking the code," noted Galindo. "That is extremely difficult; I cannot tell you how difficult it is."
"There are a number of industry techniques that everyone uses [to improve performance], but Python is incompatible with these methods. Instead, we have to develop entirely new techniques to achieve only similarly good results."
Separately, the team has to worry about the knock-on effects of a poorly-implemented change, of which there could be many. As an example, Galindo gestured towards the impact of a drop-off in language performance on energy usage (and therefore carbon emissions). "When you make changes in the language, it can be daunting," he said. "How many CPU cycles will I cost the planet with a mistake...?"
Despite the various headwinds, the Python Steering Council has lofty ambitions for the language, with the next major release (version 3.11) set to go live in October. Apparently, speed is the first item on the agenda. Galindo told us the aim is to improve performance by up to 60% (depending on the workload) with Python 3.11 and again with version 3.12. In the longer term, meanwhile, the goal is to make the language between two and five times faster within the next decade.
The council will also continue to focus on improving the quality of error messages generated by the Python Interpreter in an effort to make debugging much simpler, a pet project of Galindo's and a major focus during his time on the council.
Good luck! (Score:4, Insightful)
I have to use Python. But I find python to be designed in such a way that it is hard to use and be confident that nothing will blow up in your face.
Between the lack of typing and the braindead scoping of the language, I can't believe how popular the language is
I hope they'll be able to clean up the mess. But I don't think it is possible without breaking many codebases.
Re:Good luck! (Score:5, Interesting)
it is hard to use and be confident that nothing will blow up in your face.
Indeed. Many bugs that would be compile-time errors in C++ or Java are runtime errors in Python that can lie latent for years in code that is seldom executed, such as error handling code. The result can be data corruption or failed transactions.
Pylint can be helpful but it is no substitute for strict static types.
Too many people use Python for applications where it is inappropriate.
Re:Good luck! (Score:5, Interesting)
Pylint can be helpful but it is no substitute for strict static types.
Why would you want static typing/static type safety in Python? Dynamic typing is not a problem, it is a choice. It comes with advantages and disadvantages. If you cannot handle dynamic typing competently, you should probably stay away from Python.
Re: (Score:3)
Meh, there's a lot to complain about in Python, but I don't really think this is a major issue. I can't remember the last time I saw a type error in C. The most I ever get are missed down casts in Java, though those are always intentional, and wouldn't actually break anything if the compiler ignored them. Type errors are almost exclusively a problem for beginners.
It's funny. Lisp has dynamic typing, but you never hear anyone bring that up as a problem.
Too many people use Python for applications where it is inappropriate.
That seems to be most places. I'm not sure I've eve
Re: (Score:2)
Lisp has dynamic typing, but you never hear anyone bring that up as a problem.
As Bjarne Stroustrup said, "There are only two kinds of languages: the ones people complain about and the ones nobody uses."
Lisp is in the latter category. I have never seen it used in a large commercial application.
I'm not sure I've ever seen Python used and thought that it was the right choice.
Python is a scripting language. It is appropriate for small scripts from a few lines to a few pages.
It should not be used for anything that is either big or critical.
The world's least efficient language running on bottom-tier hardware... What were they thinking?
Most likely that Python is widely known and easy for non-techies to learn.
Re: (Score:3)
Most likely that Python is widely known and easy for non-techies to learn.
I disagree with that. In the past I've called Python superficially simple. I was involved in a STEM camp last year that tried to introduce programming using Python. We also had a foster kid at the time who was interested in it, so I gave him the same kit and resources we gave the kids at the camp (a pi 400 and accessories, a book, and other assorted resources) along with appropriate guidance. Kids, even those with some prior programming exposure, really struggled with the very things that Python is supp
Re: (Score:2)
I was involved in a STEM camp last year that tried to introduce programming using Python.
You should try Scratch [mit.edu]. I have used it successfully to teach programming to 4th, 5th, and 6th graders.
Scratch runs well on a Raspberry Pi and can also be run in-browser on a Chromebook.
There is an Arduino interface, but I haven't used it yet.
Re: (Score:2)
That's good to hear, it may be worth revisiting then. I didn't have good results with it before, so I've never tried it with a group. It was a while back though, the website still used Flash. Two of the kids I introduced to it tinkered with if for a few days before moving on. One kid really took to it, but stuck pretty exclusively to making animations and didn't make much progress beyond that.
If you used a particular curriculum or some activities you found worked well, I'd be interested to hear about th
Re: (Score:2)
Two of the kids I introduced to it tinkered with it for a few days before moving on
That's what should happen. Scratch is a toy language. You play with it to learn a few basics about programming, like if-else, loops, and subroutines. Then you move on to something real.
Just a few days is kinda short, but if you're using it for more than a month, you're doing it wrong.
Re: (Score:2)
(This is not an endorsement of Python)
If static typing is saving you any noticeable debugging time you need to stop programming and do something else for a living.
When people start raving about static typing I know I'm dealing with someone that doesn't factor their code well and has a poor grasp of scoping rules, or how creates too many variables, or all three.
Yeah, if you have functions that are pages long then static typing will save your bacon when you forget what's going on in the function, but that's n
Re: (Score:2)
"Cars shouldn't have seat belts. Instead, people should just drive carefully."
Re: (Score:2)
"Cars shouldn't have seat belts. Instead, people should just drive carefully."
"Cars should have outriggers like canoes have, because more stability is always a good thing."
Re: (Score:2)
(This is not an endorsement of Python)
If static typing is saving you any noticeable debugging time you need to stop programming and do something else for a living.
When people start raving about static typing I know I'm dealing with someone that doesn't factor their code well and has a poor grasp of scoping rules, or how creates too many variables, or all three.
Yeah, if you have functions that are pages long then static typing will save your bacon when you forget what's going on in the function, but that's not solving the fundamental problem.
This shows you didn't write anything larger than few pages of code in your life.
After few hours of coding it's easy to mix Matrix3d with Matrix4d while also using Point3d. People do simple mistakes all the time. If the project is small such bugs are easy to spot. Not so much if you have lot's of code.
Re: (Score:2)
Like I said, you probably aren't good at factoring your code properly and confuse yourself.
Re: Good luck! (Score:2)
Re: (Score:2)
Pylint can be helpful but it is no substitute for strict static types.
There is optional static type checking in modern Python using type annotations and a tool like mypy. An increasing number of libraries comes with type annotations.
I think type annotations help a lot in larger projects, not only because they can be checked statically but also as documentation. However, figuring out how to annotate code, especially code not originally written with static typing in mind, can eat up a lot of developer time. So I think it makes sense to keep this feature optional.
Not hard to see why (Score:1)
It's a step up from javascript and PHP. Those are even more popular.
Re: (Score:2)
It's a benefit. You get total control but you've got to know what you're doing. C'est la vie.
Re: (Score:2)
We used to say that of assembly. And we've pretty much decided it was a bad thing for 99.9% of development.
Re: (Score:2)
We used to say that of assembly. And we've pretty much decided it was a bad thing for 99.9% of development.
That tired old BS again. The problem with assembler is lack of portability, lack of standardized libraries and other language features, a need to know the hardware intimately and other problems. Now look at C, which is in many ways the improved "assembler" that fixes these things without sacrificing performance and control. Widely popular, you can successfully do massive, cross-platform projects with it (the Linux kernel, for example), it is available basically anywhere, scales from tiny to very large and i
Re:Good luck! (Score:4)
It's funny the number of people who want to turn Python into Java. If you want Java, use Java.
Re: (Score:2)
Amen to this. I've been a Python dev for the past 10 years and I'm yet to experience a week when I don't hear someone compare Python to other programming languages and name at least a handful features that should be backported to Python.
Re: (Score:1)
Re: (Score:2)
I have to use Python. But I find python to be designed in such a way that it is hard to use and be confident that nothing will blow up in your face.
Between the lack of typing and the braindead scoping of the language, I can't believe how popular the language is
I hope they'll be able to clean up the mess. But I don't think it is possible without breaking many codebases.
It is not a "mess". It is a tool for experts. Like with a chef's knive, you han hurt yourself with Python massively if you do not really understand what you are doing. In that sense, it is a lot like C. Given that people that know what they are doing are rare, and not only in coding, I agree that the popularity of Python is somewhat mystifying. I do like it a lot though (usually with embedded C modules if there is any heavy lifting) and I never ran into any real problems. May be because I tend to think befo
Re: (Score:2)
[Python] is not a "mess". It is a tool for experts.
Perl: "Hold my beer ..." :-)
Re: (Score:2)
[Python] is not a "mess". It is a tool for experts.
Perl: "Hold my beer ..." :-)
Well, Perl _is_ a mess. Usually. You can write clean Perl code and I have done so numerous times (confirmed by students that I gave the Perl code to as basis for their thesis work). But what Perl excels at is quick hacks that you throw away afterwards.
Re: (Score:2)
I guess I just disagree with you.
The language is a mess. And they understand that it is a mess because the community has developed linters to help you identify the patterns that are truly dangerous. The language is not flexible, it is overly lax for no good reason.
There is no good reason to enable this to work:
linters know that and
Re: (Score:2)
Re: (Score:2)
I agree it works as designed. My point is that the design sucks!
Note that you did not answer any of the question in the. Is there a case where that design is useful?
There are good reasons why it is designed this way. Mostly because historically it was designed that way and you can't fix the design without breaking past code. And that's a good reason not to change the design.
The language is designed in a way that is confusing and not helpful. PHP works as designed and its standard library is a mess of incons
Re: (Score:2)
I don't think it is possible without breaking many codebases.
It's okay. Python users are used to having all of their code break periodically.
Despite this, after several attempts, they still haven't managed to get 'print' working properly. I have no confidence that Python will improve. Even with Guido gone, the summary makes clear that the future of the language is in the hands of the users. Users who, against all reason, have chosen to invest heavily in Python.
I can't believe how popular the language is
You're not alone. If I had to guess, I'd say that what people really wanted was something like a modern
Re: (Score:2)
Re: (Score:2)
Care to contradict anything I've written then?
Re: (Score:1)
Re: (Score:2)
It actually started off better than it ended up. It wasn't a function, which was fine because you didn't need parenthesis. It always added a newline, which is annoying, but wasn't too bad as you could add a trailing comma to suppress the newline, not unlike the trailing ; in some versions of BASIC. The big annoyance here was that it (almost) always added a leading space after converting numbers or whatever to strings. The only way to stop this was to compose your string ahead of time.
Later, print was ch
They will fail; look at history (Score:2)
Every language "evolves" into a bigger mess or they seem to fall into obscurity where they may have reached perfection... The problem with perfection is that hardly anybody realizes perfection has been achieved and by definition, it's static or "dead" in that it can no longer adapt to changing expectations (this is also not always good!)
LOL Python thinking about waste and CPU cycles?
Python is for non-programmers to glue components together to do their job which is NOT a programming job. This is why it has
Now make the libraries consistent (Score:5, Interesting)
I've worked with languages where everything is consistent there is an order to function calls and the way data comes back from functions and everything across the language and libraries is consistent so you don't even have to think about how to call the function. This allows you to write code that you've never used before extremely fast.
This is what I'd ask of python to make libraries consistent in the way that they are called, I realize this will never happen, but as of these inconsistencies at sure sucks to use python.
Re: (Score:2)
Re: (Score:2)
You built your house upon the sand. Sorry about that. It's possible to escape, but it'll be time-consuming and expensive.
Re: (Score:2)
Re: (Score:2)
That's unusual. Is it possible for you to share those circumstances? (I know that can be tough sometimes without doxing yourself.)
I'll agree that stability is important for a language. I honestly don't know why people put up with endless breaking changes. Maybe they never have to maintain anything?
Still waiting for a fully integrated IDE/GUI plus (Score:2)
While I appreciate all those efforts, it would be wonderful if we had a fully functional RAD/IDE with ability to provision beautiful GUI applications. I am trying to develop a native database application with a programmable GUI where business logic can be implemented.
This is possible with present tools. The problem is the lack of that tight knit environment. Everything is disjointed. An update to one component creates mayhem!
Re: (Score:1)
Visual Studio and MFC was great at making complex IDEs, fully integrated into the code.
Then Microsoft gave up on MFC.
Re: (Score:2)
This is the danger of letting the fate of your code base rest with a single provider. Microsoft burned us around the turn of the century. That's a lesson I'll never forget.
Things were moving so fast in the 80's and 90's. Expectations were different, at least where in the spaces I was in, so 5 years seemed like a good lifetime for an application to have. 10 years was a lot longer then. Picture an app from 1993 in 2003 and the same from 2003 to 2013. In the former case, that app was hopelessly outdated
Change all the stuffs, call it Python 4.0... (Score:1)
Profit !
And millions of frustrated programmers put off your language for life.
Re: (Score:2)
That sort of happened in the Python2-Python3 transition. Which is why they kept Python2 going for a decade after Python3 was released. Presumably they'll handle Python4 the same way.
FWIW, the most frustrating thing to me about the Python2-Python3 transition is all the libraries that didn't switch. I'm not sure they've all switched even now.
OTOH, the MOST frustrating thing to me about Python is the lack of a standard balanced tree method. Dicts are great, but they don't allow you to search for a nearest
Re: (Score:2)
That sort of happened in the Python2-Python3 transition.
That's the joke.
I'm not sure they've all switched even now.
"cocos2d-x is a multi-platform framework for building 2d games, interactive books, demos and other graphical applications."
"Build Requirements: Python 2.7.5+(NOT Python 3)"
So much good stuff out there hasn't switched. A disaster for the language.
Re: (Score:2)
That sort of happened in the Python2-Python3 transition. Which is why they kept Python2 going for a decade after Python3 was released.
For me, what delayed my transition was that Python3 simply sucked when it first came out. It wasn't until 3.5 that it became tolerable and 3.6 before it actually started to become good. With 3.8 it's actually better than Python2 finally, and that's the minimal version I'll use for new python projects now.
Python for Workgroups? (Score:1)
CPU cycles (Score:3)
"How many CPU cycles will I cost the planet with a mistake...?"
If you value CPU cycles, you don't use Python.
Seriously, the level of marketing BS these days, even in the open source world, is getting pretty tiring. I pretty much stopped listening to all the Rust fanboys for this very reason.