Mark functions as
async. Call them with
await. All of a sudden, your program becomes asynchronous – it can do useful things while it waits for other things, such as I/O operations, to complete.
Code written in the
awaitstyle looks like regular synchronous code but works very differently. To understand how it works, one should be familiar with many non-trivial concepts including concurrency, parallelism, event loops, I/O multiplexing, asynchrony, cooperative multitasking and coroutines. Python’s implementation of
awaitadds even more concepts to this list: generators, generator-based coroutines, native coroutines,
yield from. Because of this complexity, many Python programmers that use
awaitdo not realize how it actually works. I believe that it should not be the case. The
awaitpattern can be explained in a simple manner if you start from the ground up. And that’s what we’re going to do today.
If you ask me to name the most misunderstood aspect of Python, I will answer without a second thought: the Python import system. Just remember how many times you used relative imports and got something like
ImportError: attempted relative import with no known parent package; or tried to figure out how to structure a project so that all the imports work correctly; or hacked
sys.pathwhen you couldn’t find a better solution. Every Python programmer experienced something like this, and popular StackOverflow questions, such us Importing files from different folder (1822 votes), Relative imports in Python 3 (1064 votes) and Relative imports for the billionth time (993 votes), are a good indicator of that.
The Python import system doesn’t just seem complicated – it is complicated. So even though the documentation is really good, it doesn’t give you the full picture of what’s going on. The only way to get such a picture is to study what happens behind the scenes when Python executes an import statement. And that’s what we’re going to do today.
Every year or so, I revisit the current best practices for Python packaging. I.e. the way you’re supposed to distribute your Python packages. The main source is packaging.python.org where the official packaging guidelines are. It is worth noting that the way you’re supposed to package your Python applications is not defined by Python or its maintainers, but rather delegated to a separate entity, the Python Packaging Authority (PyPA).
The PyCon US 2021 recordings are available on our YouTube channel. Be sure to subscribe to our channel for notifications of new content. This channel will be used for all future conferences in order to keep all content in one channel.
The recordings are synced with the available live captions taken during the event. There are some tutorials whose files did not align with the recordings for many unforeseen reasons. Please utilize the closed captions offered on YouTube for those without the caption files synced. There are three tutorials that needs some fine tuning and will be available next week:
Introduction to Decorators: Power UP Your Python Code / Geir Arne Hjelle
Effective Data Visualization / Husni Almoubayyed
A Hands-On Introduction to Multi-Objective Optimisation / Eyal Kazin
We can not mention enough times our heartfelt gratitude to all the presenters of the tutorials, talks, keynote addresses, posters, workshops, summits and lightning talks for their time and efforts in providing the content presented at PyCon US 2021. You have all helped to make this event a success.
As I’ve written about previously and elsewhere, I felt so badly burned by Apple’s laptop hardware design decisions of a few years ago that I’ve rather fallen out of love with that platform for my personal work. The latest hardware is much better, but I feel like the message has been sent and received, so I’m not rushing back any time soon.
My first choice was the Linux desktop, and after months of struggling, instability and accessibility issues I’ll admit I’ve been looking for stable, solid alternatives that are also powerful enough to get the job done and maybe even have something new to offer. As an old dog, sometimes it’s really nice to be taught some new tricks!
If you’ve tangoed with Windows in the past, and found yourself struggling against its rather byzantine UI, I’d urge you to read on and see if maybe it’s not time for another careful look.
Since choosing the right tools is all about your unique set of needs, I’ll use those as categories to drive the discussion and showcase how Windows is doing a great job of satisfying them.
In a Q&A, Python programming language creator Guido van Rossum said it was “almost taboo to talk about a Python 4 in a serious sense” following the troubled migration from Python 2.0 to Python 3.0.
For this post in my Python syntactic sugar series, I am going to cover
Now when I started to think about this post I was worried it was going to be rather long and arduous to research (although I believe
classis going to ultimately win that crown 😜), but then I remembered I had written a blog post about how
awaitworked in Python 3.5. As part of that post I went through the history of how Python got to that point of asynchronous programming, which meant I had already dived into the details of how Python evolved earlier syntax to what it has today! Thus this post is going to draw heavily from my
asynchistory post to save myself some time, so if you feel I skimmed over details then chances are it’s because I covered it in my other post.
Python is slow, and compiled languages like Rust, C, or C++ are fast. So when your application is too slow, rewriting some of your code in a compiled extension can seem like the natural approach to speeding things up.
Unfortunately, compiled extensions are sometimes actually slower than the equivalent Python code. And even when they’re faster, the performance improvement might be far less than you’d imagine, due to hidden overhead caused by two factors:
Function call overhead.
Let’s see where these hidden performance overheads comes from, and then see some solutions to get around them.
I’ve written in the past somewhat opaquely about certain programming languages and my complaints about them. One that I’m not afraid to complain about by name is Python. You can look in enough of my old posts to see this pattern keeps coming up. It never fails to make my life more interesting than it has to be.
So, with that said, one of the things I decided we needed at $COMPANY was something that would let us handle SEVs (you know, outages, site events, whatever?) well. What they had already when I arrived was, to put it mildly, cute. It was basically a wrapper around the Jira category they already had to track these things, plus it would blast out mails to extra places when someone commented in the tool. Unfortunately, those mails also tended to start full-on reply-to-all spam fests due to their scattershot nature. Every person was getting every update to every SEV.
Have you ever started on some creative work, and given yourself an arbitrary restriction within which to do it? Like making some pixel art, but you will only use black or white pixels. I think it’s quite a fun way to drive the creative and problem solving juices, to test the limits of the restriction and learn new techniques.
In the two most recent posts we focused on the Python object system. We learned what Python objects and Python types are, how they are defined and what determines their behavior. This discussion gave us a good understanding of how Python objects work in general. What we haven’t discussed is how particular objects, such as strings, integers and lists, are implemented. In this and several upcoming posts we’ll cover the implementations of the most important and most interesting built-in types. The subject of today’s post is
Python is my favourite programming language. Since I discovered it in 2004, programming in Python became my favourite hobby. I’ve tried to learn a few other languages and have never found one as friendly to beginners as Python. As readers of this blog know, these days I am particularly interested in tracebacks, and I am likely paying more attention than most to Python’s improvements in this area: Python is becoming more and more precise in the information that it provides to the users when something goes wrong…
People bash OO a lot these days, I’m increasingly coming to the opinion they’re right, at least in Python. My point here is not to argue that OO is bad per se, more that its introduction is simply unnecessary, AKA not useful.
Let’s see how we can create QR codes that look however we want, while preserving links. We’ll also show the world’s first working QR gif (as far as I know).
On November 29, version 1.7 of SymPy, a Python library for symbolic mathematics, was released. The new version brings a large number of enhancements and bug fixes, and some minor backward incompatibilities. While these are enumerated in detail in the release notes, we will take advantage of this opportunity to look at some of the things that can be done with SymPy and explore its interface options through several detailed examples.
Mypy is an optional static type checker for Python. It’s been around since 2012 and is gaining traction even since. One of the main benefits of using a type checker is getting errors at “compile time” rather than at run time.
Exhaustiveness checking is a common feature of type checkers, and a very useful one! In this article I’m going to show you how you can get mypy to perform exhaustiveness checking!