

Python owes much of its development and growth to Google, which has been an avid user of the language. They even employed the Dutchman Guido Van Rossum (Python’s founder) for a long time.

“Python if we can, C if we must”, has been a slogan at Google for numerous years. The reason behind that is fairly obvious: the advantages of Python are crystal clear. It’s easy to learn and has clean and short syntax. That means its code is short and readable, and quickly written. Saving time writing code is one of the biggest advantages of Python.
What is Python used for?
As we mentioned above, Python is heavily used in AI and data science. Additionally, it’s also the better choice in DevOps and task automation. On the other hand, web development is a domain it’s taken Python some considerable time to become an obvious option. The main reason for this is probably because there’s a lot of competition in this area from languages like Java, PHP, Dotnet and NodeJS (= Javascript framework), with PHP and NodeJS being uniquely developed for websites. There’s also another important reason, which we will discuss later in this article.
Python is an interpreted language
Just like JavaScript, Python is an interpreted language. That means Python isn’t directly usable by a computer, but that it needs another program to execute the code. The advantage of this approach is that there’s no need for compilation, which saves time. However, this also comes with a downside: an interpreted language is a lot slower than a compiled language.
There are Python implementations like Cython and Jython, which convert your Python code to bytecode or C extensions. They are outside the scope of this article.
Although Python and Javascript are interpreted languages, Python is (was) in most cases the slowest. One of the reasons for this is that NodeJS was built for the web, has advanced multithreading abilities and is event driven. Python on the other hand is as old as the Internet (first released in 1991) and had to serve different purposes. Multithreading is not built into Python, but it is available in its toolbox.
Speeding up Python with concurrency
When developing websites or APIs in Python, there are a lot of frameworks to pick from. The most popular frameworks are Flask and Django. However, if you only need an API for your fancy React or Angular website, there’s a much better option: FastAPI. Currently at version 0.70.0, FastAPI is rapidly climbing up the popularity ranks. One of the reasons is that it does what it says: it’s fast. Not because it's lightweight, but because it has out-of-the-box support for concurrency (asynchronous functions, requires Python 3.6+).
Concurrency is the element speeding everything up. It’s all about optimizing CPU-bound or I/O-bound tasks, with the latter slowing your code down the most. For example, if your API depends on another API to collect some additional data, the HTTP request will take a considerably large amount of time (in comparison with CPU tasks). If you have multiple calls, that could slow down your code dramatically.
Let’s look at an example. The script below will download 50 websites without concurrency (synchronous).
import requests
import time
def download(url, session):
with session.get(url) as response:
print(f"Read {len(response.content)} from {url}")
def download_all(sites):
with requests.Session() as session:
for url in sites:
download(url, session)
if __name__ == "__main__":
sites = [
"https://www.python.org",
"https://www.jython.org",
"https://pypi.org/",
"https://fastapi.tiangolo.com/",
"https://flask.palletsprojects.com/en/2.0.x/"
] * 10
start_time = time.time()
download_all(sites)
duration = time.time() - start_time
print(f"Downloaded {len(sites)} in {duration} seconds")
If we execute this script, this is the result:
… output skipped …
Read 41381 from https://flask.palletsprojects.com/en/2.0.x/
Downloaded 50 sites in 5.598579168319702 seconds
5 seconds to download 50 websites is not bad, but we can improve this dramatically.
To speed things up, we can choose out of two ways Python can handle concurrency: threading and asyncio. Threading has been introduced in Python 3.2 and works very well. There are a few downsides though. Threads can interact in ways that are subtle and hard to detect. You’ll need to experiment with the number of threads, as that number varies depending on what you want to achieve. An even better way to speed things up is asyncio, introduced in Python 3.6. Asyncio gives you more control and is easier to implement than threading. The same code rewritten to use asyncio would look like this:
import asyncio
import time
import aiohttp
async def download(session, url):
async with session.get(url) as response:
print("Read {0} from {1}".format(response.content_length, url))
async def download_all(sites):
async with aiohttp.ClientSession() as session:
tasks = []
for url in sites:
task = asyncio.ensure_future(download(session, url))
tasks.append(task)
await asyncio.gather(*tasks, return_exceptions=True)
if __name__ == "__main__":
sites = [
"https://www.python.org",
"https://www.jython.org",
"https://pypi.org/",
"https://fastapi.tiangolo.com/",
"https://flask.palletsprojects.com/en/2.0.x/"
] * 10
start_time = time.time()
asyncio.get_event_loop().run_until_complete(download_all(sites))
duration = time.time() - start_time
print(f"Downloaded {len(sites)} sites in {duration} seconds")
If we execute this script, this is the result:
… output skipped …
Read 41381 from https://flask.palletsprojects.com/en/2.0.x/
Downloaded 50 sites in 1.0634150505065918 seconds
The same 50 websites are downloaded in 1 second, which is 5 times faster than the synchronous code!
In benchmarks with NodeJS, FastAPI is faster in almost all cases. Combine this with the development speed of Python, the tons of Python libraries available on the web and the built-in OpenAPI (Swagger) documentation and full-featured testing system and the choice is evident.

Want to speed up your Python development? Contact us to see how we can help!
Fun fact: there’s even Python on Mars

Did you know NASA used Python on the Perseverance Mars mission? The moment of landing itself was recorded by 5 cameras placed in different parts of the probe. Python scripts were used to process the images and transfer them to the flight control center. If NASA uses a programming language, it's probably trustworthy. 😉

What others have also read


Our Business expert in Energy Utilities Tom Claus headed to Energy Mission, and came back with some new insights… and a wake-up call for companies and (government) agencies.
Read more

Enlit is Europe's largest event on energy transition. Tom Claus and Sven Sambaer went on behalf of ACA Group to meet up with customers and partners, and to keep their eyes open for new ideas and the latest trends. A report on the energy trilemma, the car battery as guardian of the balance in the distribution network, and smart metering 2.0.
Read more

In software development, assumptions can have a serious impact and we should always be on the look-out. In this blog post, we talk about how to deal with assumptions when developing software. Imagine…you’ve been driving to a certain place A place you have been driving to every day for the last 5 years, taking the same route, passing the same abandoned street, where you’ve never seen another car. Gradually you start feeling familiar with this route and you assume that as always you will be the only car on this road. But then at a given moment in time, a car pops up right in front of you… there had been a side street all this time, but you had never noticed it, or maybe forgot all about it. You hit the brakes and fortunately come to a stop just in time. Assumption nearly killed you. Fortunately in our job, the assumptions we make are never as hazardous to our lives as the assumptions we make in traffic. Nevertheless, assumptions can have a serious impact and we should always be on the look-out. Imagine… you create websites Your latest client is looking for a new site for his retirement home because his current site is outdated and not that fancy. So you build a Fancy new website based on the assumption that Fancy means : modern design, social features, dynamic content. The site is not the success he had anticipated … strange … you have build exactly what your client wants. But did you build what the visitors of the site want? The average user is between 50 – 65 years old, looking for a new home for their mom and dad. They are not digital natives and may not feel at home surfing on a fancy, dynamic website filled with twitter feeds and social buttons. All they want is to have a good impression of the retirement home and to get reassurance of the fact that they will take good care of their parents. The more experienced you’ll get, the harder you will have to watch out not to make assumptions and to double-check with your client AND the target audience . Another well known peril of experience is “ the curse of knowledge “. Although it sounds like the next Pirates of the Caribbean sequel, the curse of knowledge is a cognitive bias that overpowers almost everyone with expert knowledge in a specific sector. It means better-informed parties find it extremely difficult to think about problems from the perspective of lesser-informed parties. You might wonder why economists don’t always succeed in making the correct stock-exchange predictions. Everyone with some cash to spare can buy shares. You don’t need to be an expert or even understand about economics. And that’s the major reason why economists are often wrong. Because they have expert knowledge, they can’t see past this expertise and have trouble imagining how lesser informed people will react to changes in the market. The same goes for IT. That’s why we always have to keep an eye out, we don’t stop putting ourselves in the shoes of our clients. Gaining insight in their experience and point of view is key in creating the perfect solution for the end user. So how do we tackle assumptions …? I would like to say “Simple” and give you a wonderful oneliner … but as usual … simple is never the correct answer. To manage the urge to switch to auto-pilot and let the Curse of Knowledge kick in, we’ve developed a methodology based on several Agile principles which forces us to involve our end user in every phase of the project, starting when our clients are thinking about a project, but haven’t defined the solution yet. And ending … well actually never. The end user will gain new insights, working with your solution, which may lead to new improvements. In the waterfall methodology at the start of a project an analysis is made upfront by a business analist. Sometimes the user is involved of this upfront analysis, but this is not always the case. Then a conclave of developers create something in solitude and after the white smoke … user acceptance testing (UAT) starts. It must be painful for them to realise after these tests that the product they carefully crafted isn’t the solution the users expected it to be. It’s too late to make vigorous changes without needing much more time and budget. An Agile project methodology will take you a long way. By releasing testable versions every 2 to 3 weeks, users can gradually test functionality and give their feedback during development of the project. This approach will incorporate the user’s insights, gained throughout the project and will guarantee a better match between the needs of the user and the solution you create for their needs. Agile practitioners are advocating ‘continuous deployment’; a practice where newly developed features will be deployed immediately to a production environment instead of in batches every 2 to 3 weeks. This enables us to validate the system (and in essence its assumptions) in the wild, gain valuable feedback from real users, and run targeted experiments to validate which approach works best. Combining our methodology with constant user involvement will make sure you eliminate the worst assumption in IT: we know how the employees do their job and what they need … the peril of experience! Do we always eliminate assumptions? Let me make it a little more complicated: Again… imagine: you’ve been going to the same supermarket for the last 10 years, it’s pretty safe to assume that the cereal is still in the same aisle, even on the same shelf as yesterday. If you would stop assuming where the cereal is … this means you would lose a huge amount of time, browsing through the whole store. Not just once, but over and over again. The same goes for our job. If we would do our job without relying on our experience, we would not be able to make estimations about budget and time. Every estimation is based upon assumptions. The more experienced you are, the more accurate these assumptions will become. But do they lead to good and reliable estimations? Not necessarily… Back to my driving metaphor … We take the same road to work every day. Based upon experience I can estimate it will take me 30 minutes to drive to work. But what if they’ve announced traffic jams on the radio and I haven’t heard the announcement… my estimation will not have been correct. At ACA Group, we use a set of key practices while estimating. First of all, it is a team sport. We never make estimations on our own, and although estimating is serious business, we do it while playing a game: Planning poker. Let me enlighten you; planning poker is based upon the principle that we are better at estimating in group. So we read the story (chunk of functionality) out loud, everybody takes a card (which represent an indication of complexity) and puts them face down on the table. When everybody has chosen a card, they are all flipped at once. If there are different number shown, a discussion starts on the why and how. Assumptions, that form the basis for one’s estimate surface and are discussed and validated. Another estimation round follows, and the process continues till consensus is reached. The end result; a better estimate and a thorough understanding of the assumptions surrounding the estimate. These explicit assumptions are there to be validated by our stakeholders; a great first tool to validate our understanding of the scope.So do we always eliminate assumptions? Well, that would be almost impossible, but making assumptions explicit eliminates a lot of waste. Want to know more about this Agile Estimation? Check out this book by Mike Cohn . Hey! This is a contradiction… So what about these assumptions? Should we try to avoid them? Or should we rely on them? If you assume you know everything … you will never again experience astonishment. As Aristotle already said : “It was their wonder, astonishment, that first led men to philosophize”. Well, a process that validates the assumptions made through well conducted experiments and rapid feedback has proven to yield great results. So in essence, managing your assumptions well, will produce wonderful things. Be aware though that the Curse of Knowledge is lurking around the corner waiting for an unguarded moment to take over. Interested in joining our team? Interested in meeting one of our team members? Interested in joining our team? We are always looking for new motivated professionals to join the ACA team! {% module_block module "widget_3ad3ade5-e860-4db4-8d00-d7df4f7343a4" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"View career opportunities"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":229022099665,"href":"https://25145356.hs-sites-eu1.com/en/jobs","href_with_scheme":null,"type":"CONTENT"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}
Read moreWant to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!

Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!

Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!

Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!


