Python is getting faster: Major performance tweaks on horizon The next version of the standard Python interpreter, CPython, is expected in October. It will include significant performance improvements and support for running inside the browser. Last week, the first Python language summit since 2019 took place in Salt Lake City. At the event, the language's development team announced …
Very popular, but that doesn't mean it's any good.
Of the four general purpose programming languages that I know well and I'm in current practice (LISP, C, JavaScript, Python), this one is by far my least preferred.
It was designed roof-first (let's have significant white space!) and when it gained traction it got stuff bolted into it without ever overcoming its fundamental limitations. To this day it cannot do multi threading or asynchronous execution properly. And its attempt at a library system, with "magic files" and search path weirdness was never really thought through.
Not to mention the terminological confusion between "lists" and arrays which, as other parts of the implementation, leave one with no doubt that this was not meant to be a serious project (and I don't think the author initially intended it that way).
As I said, I do actually use it (if you can't beat them, join them) and there is one aspect where it generally shines in terms of making life easier: prototyping or even writing Qt applications. The Qt bindings for Python are the best out there and Qt is a fine library as far as desktop applications go (and more). I also understand that it was meant to be a hobby project and so whimsical decisions can be expected, but in terms of popularity it's punching way above its weight.
In comparison, JavaScript gets a bad press, largely from older IT people (some programmers, most not) who think it's a web browser thing, but it's actually quite a decent tool these days.
Granted, it started off as a quick hack put together in a week or two to please the VC investor appointed marketing people at Netscape, so very serious "compromises" were made. I've always heard that Breich's preferred choice would have been to go with Scheme instead, which is what *should* have happened if we lived in a fair world.
But since ES6 onwards and with modern engines such as V8 and SpiderMonkey, it has turned into a very expressive and efficient tool that can do a lot of stuff and particularly shines at asynchronous I/O (OK, it's not Erlang by any stretch of the imagination, but it's much quicker to prototype stuff in) and general processing. It's also relatively easy to interface with C code when needed, and lends itself well to functional style programming (which as a Schemer, is what feels natural to me).
Also, prototype based programming is underrated (though I mostly use classes these days)
OMG! A lisper and a schemer saying sensible things about programming languages here! And mentioning Erlang, too! And I thought I was the last one to remember Greenspun's tenth rule... I am not alone!
Wait... Am I supposed to read something into the fact that both hide behind AC masks??? What have I done?
If you find yourself confused by the difference between Python lists and arrays then I would suggest reading some basic computer science books on data structures.
Python arrays are simply a library wrapper around a standard C array. If you write a C extension you can use the Python array as a C array. Python arrays have all the same numerical data types as the underlying C compiler, and indeed the definitions of those data types is based on whatever the C compiler decides they are.
Lists are simply dynamic arrays of pointers to objects, with those objects being of any arbitrary type. They are conceptually similar to C++ vectors or Java arraylists. If you're not familiar with either of those or similar languages then the concept may appear new to you but it's not something unique to Python although some of the details may be.
As for your apparent dislike of how import paths are handled, the standard system is very simple and easy to understand and suits what most people need. If for some reason you need to customize your import paths you can do that through the provided means. Read up on the relevant documentation to see what suits your situation.
As for "significant white space", white space is significant to how people reading the code understand it so the compiler should read and understand it the same way as a human does. Having humans apply one method in their minds and the computer using a completely different method of comprehending code is simply a recipe for entire classes of avoidable bugs. There have been enough Register articles on major security problems caused by this. Most professional environments have coding standards and in this one the preferred standard is enforced as part of the language syntax.
In my opinion there is no such thing as a one size fits all language that is best for all applications. Different languages are best used for different applications, which is why it's a good idea to learn several different languages of different types.
In my opinion Python is particularly good for applications where minimizing the implementation time and effort is critical, such as in custom business applications, scientific experiments, and the like. You can generally write a Python program in a fraction of the number of lines of code than most other languages require, and when time is money, that matters.
In a nutshell, Python is (largely) quick and easy to learn/code, which is the main reason why it has gained so much traction, but that comes with a cost.. It's just so damn slow and inefficient (comparatively), hopefully these upcoming changes will help with that.
I consider it more of a scripting language like PHP. A language where anyone can cobble something together.
Criticiscms of Python's speed are rarely grounded in fact. Yes, as an interpreted language it has an overhead in execution speed when compared with a compiled one: every run requires compilation; higher memory use, etc. However, in many situations where lots of work is being done, the work is being done by C, C++ or even Fortran libraries with the Python code just moving the data around. And this is the recommendation for anyone writing large systems in Python: prototype, profile and then write relevant extensions. It doesn't work in every situation but it works more often than not.
Bloomberg is onboard because the financial services industry has adopted Pandas and Jupyter over Excel, never known for its speed, en masse and Python has become the goto environment for machine learning.
The comparison with PHP is really limited to web stuff. It is the large number of great domain specific libraries (from biology to engineering to machine learning, etc.) in Python that make the difference.
> Criticiscms of Python's speed are rarely grounded in fact
This very article is about addressing python's poor performance and the author has been thoughtful enough to explain in the first couple of paragraphs the technical reason for it, which has nothing to do with it being interpreted (which is not true anyway as it gets compiled into byte code) and all to do with a fundamental design decision at the core of the language.
The article mainly covers issues related to the GIL, but these affect parallelism not speed. Much performance critical code is already in mainly C (eg. regex handling, XML parsing) with Python-specific overhead such as loops and function calls around 50% slower than C. This is good enough for the likes of CERN.
That said, the changes to the language as part of the move to Python 3 did slow things down, especially switching text from bytes to unicode. Things have improved with each release since about 3.4 but 3.11 is noticeably faster in general use.
Better support of multiprocessor architectures and asynchronous work are required to take advantage of modern CPUs, which are no longer really getting faster. Some of this is really hard to do but the improvements in both since Python 3.6 are impressive. Asyncio is getting more and more popular and better as a result.
Most of the people who were primarily using Visual Basic either kept on using it or switched to C#. Their language choice tended to be determined by a combination of vendor platform support (Microsoft and their various products), IDE familiarity (Visual Studio), familiarity with third party libraries, etc., rather than features of the language itself. They were mainly interested in developing software for desktop PCs running MS Windows.
Python users originally mainly came from a Linux/unix/BSD background and were interested in server side development for web servers, numerical processing on super computers, biology, machine learning, large scale system administration tools, etc. A large community and set of third party libraries grew up around this. The main competitors to Python were Perl and Ruby.
With the rise of the Internet and the smartphone / tablet, the focus of the overall software market shifted away from the PC to server side, and Python was well positioned to take advantage of it.
An increasing number of new people coming into the software development learned Python because it was already well established in those up and coming areas as the language for rapid development of applications. As the market shifted away from the PC, people working in that field were drawn to Python for the same reason. Educators noticed the trend as well and started using Python as a teaching language, but most were very late to change curricula and did so only years after the trend was well established.
So the trend to Python came about due to a number of large scale industry trends coming together over the past couple of decades. The features of the language may have determined why people picked Python over Perl or Ruby, but they would have picked something along those lines regardless.
> The features of the language may have determined why people picked Python over Perl or Ruby,
I do actually remember when it became popular, must have been 15-20 years ago. There was a sudden hype onslaught, not sure why, but that pushed Python into the spotlight for the next generation.
It's just the way it goes. Seems like people suddenly get tired of whatever they're using and jump onto some other bandwagon.
And of course you would pick *anything* over Perl! (Which was actually a nice language but by God, horrible grammar)
> I would suggest reading some basic computer science books on data structures.
I actually took a CS course that used Python as its instruction language, much to the lecturers' intense dislike. :)
I also own a by now rather tatty copy of SICP.
With that said, I do appreciate your making a reasoned rebuttal. It shows that you know your stuff and made an informed decision to use it.
As for the point at hand:
> Python arrays are simply a library wrapper around a standard C array
Sounds very much like you're describing NumPy arrays, which are not part of the language itself.
> Lists are simply dynamic arrays of pointers to objects
Exactly. So they're arrays of pointers not lists. Why would they call them lists?
> As for "significant white space", white space is significant to how people reading the code understand it
I'm aware of the arguments for it and I think they're tosh. You can always enforce that *if you choose to do so* by the use of linters and similar, but baking it into the language means that if for instance I paste Python code here (sorry can't do that right now) there's a good chance it's not going to run without rearranging the indentation at your end. And things such as the indentation of *blank lines* being significant is just mad. Sure you can get used to it, but it's still stupid.
> If for some reason you need to customize your import paths
You can jump through hoops and add "magic" files to directories and check what Python version you're running and what that version expects of you and you'll probably manage.
> Most professional environments have coding standards and in this one the preferred standard is enforced as part of the language syntax.
Why?
And in practical terms, have you tried writing non-trivial lambdas (without being complex enough to merit naming)?
> In my opinion there is no such thing as a one size fits all language that is best for all applications.
Which is why I write Python. Doesn't mean I have to like it or find it any good though. I also eat at McDonald's when the alternative is to go hungry or risk food poisoning, but I won't be taking my girlfriend there.
> In my opinion Python is particularly good for applications where minimizing the implementation time and effort is critical, such as in custom business applications
Agreed, I gave the example of Qt based applications above.
> You can generally write a Python program in a fraction of the number of lines of code than most other languages require
Also partially agreed, save that for brevity Lisps are hard to beat. For mathematical work I tend to use R, more or out of habit than anything else, and for everything else I find that JavaScript strikes a sweet spot between conciseness, clarity, performance (Node totally wipes the floor with Python), availability and convenience, while giving you such basic advantages as proper threading, asynchronous execution, a very efficient event loop and better adaptability to different programming models, such as continuation passing (also possible with Python, but more verbose) and prototype based programming.
Yet, Python gets a lot of undeserved hype, while useful tools such as Node or Racket don't get anywhere near the attention they deserve. The result is a net loss as we end up in an "everything is a nail" type of situation.
In someways I quite like the enforced white space. While it is annoying when all you want to do is hack something to work I've run into too way too many messy programmers that expect you to help them when you just can't see the start of a method, if, while, for or basically anything else.
Yes you can use IDEs and tools to reformat the code, however I've found that these indivduals seem unable to take advantage of these tools.
Either way I now have enforced clang-format setups on the IDEs we use at work and as pre-commit hooks on git as well as multiple static analysis tools and enforced warnings are errors on all compilers we use.
From my experience of teaching my daughter to use python the enforced whitespace helps with seeing the structure and helps with being a bit tidier in her coding.
TBH there are way more odd issues around python that I could go on about...
> TBH there are way more odd issues around python that I could go on about...
Yeah, significant white space is certainly not the worst problem with it. I could put up with that if the rest of the language was halfway well designed, which is not the case.
Don't get me wrong, I'm not so much blaming the language, which has its place, as blaming the people who swear by it blindly because they heard it's the cool kid on the block or because they fell for the hype and now try to justify their investment in it rather than cutting their losses.
Anonymous Coward said: "Sounds very much like you're describing NumPy arrays, which are not part of the language itself."
No, I'm talking about arrays, which are part of the standard library and have been for as long as I can remember. The library is called "array" and it provides array objects as well as a number of methods for manipulating them. You referred to arrays in your initial post so I assumed you meant the arrays which come with Python.
Numpy is a third party open source library which provides its own array object types along with a very comprehensive set of methods for doing a wide variety of mathematical manipulations on the contents.
It sounds like you could use to spend some time reading the documentation on the Python standard library as you are evidently not very familiar with it. The documentation is on line and is very good. Time spent reading over the Python standard library documentation is usually time well spent as it is very extensive and many problems that you may need to solve often have a solution in the standard library.
You mention that you happen to like NodeJS. The original creator of NodeJS said in a podcast interview that he took his inspiration from Python Twisted. He wanted something like Twisted but with a JIT, and at the time Pypy did not exist. He therefore took another event loop implementation and added Javavscript V8 to it. He picked Javascript because that's what was available to him at the time "off the shelf" as it were. Twisted is another long standing third party open source Python library which is worth getting to know.
Python *is* also a scripting language. It can be embedded and can embed code written other languages, and in ways that make such code accessible in a Pythonic manner.
Data scientists and those in AI for example need very fast processing, often provided by specific hardware whose vendors go to the trouble of integrating them with Python as a way of making their hardware accessible. Coders write Python for access to the speed they need.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
