Python

Django 4.0 has been released, so it’s time to plan the upgrade from 3.x. Here are some important things to note about the upgrade:

• The latest 3.x-release is 3.2, which will receive security and “data loss” fixes until April 2024. Any 3.x-release before 3.2 will no longer receive updates or fixes. It’s time to upgrade to 3.2!
• Django 4.0 drops support for Python version <= 3.7. Django 3.2 still supports Python 3.6 and 3.7
• Django 4.0 drops a number of features that have previous been deprecated in 3.x. More details about these features can be found in the “deprecated” section of the previous releases: Django 3.0 deprecated features, Django 3.1 deprecated features
• If you are using DeleteView with custom logic in delete(), you should make yourself familiar with the new logic.

More links to the official docs:

I have updated the script to support a new parameter. Here is my use case:

Why this update? When I generate a PDF from a web-page, the resulting PDF often contains the current date at the very top, before all other dates. However, that’s not the date that I am interested in. I introduced a new before-parameter that will return the first date that is before the given date.

I have updated the previous post with the changes. (Maybe it’s time to publish this as a github project, but it still feels like overkill.)

The recent PyCharm release (2021.3) adds a feature that enables a new kind of remote development workflow. This seems to be similar to what VS Code has been able to do, but since I am using PyCharm, this is exciting. Basically, the new feature allows you to run PyCharm locally and connect it to a “PyCharm server” running remotely. The PyCharm server is a headless version of IntelliJ that you connect to using your local PyCharm (or rather a special version of a locally installed PyCharm IDE, I believe). Note that this is different from the existing workflow were you connect the local debugger to a remote session.

Here is a quick one-off script that I created to extract a date from PDFs. (Actually, this is an updated version. Maybe it’s not a one-off script after all?)

• The script will look for dates in common German formats, like 31.12.2021, 31. Dezember 2021, 31 Dez 2021.
• It will print either the first date it finds, or nothing
• It will print the date using ISO 8601 date part, e.g. 2021-12-31
• Using an optional second parameter, you can make sure the printed date is before a certain date

Requirements

The script uses two external libraries for PDF and date parsing: pdfminer.six and dateparser

In my quest to better understand rxPY, I have written some short example scripts that use different operators. I have published these on GitHub as rxpy3-examples. In order to keep the examples as short as possible, I had omitted implementing on_error and on_completed. I thought that simple examples would be bloated by this, but that was actually a mistake.

When I implemented these calls, I noticed that I had made a couple of mistakes in my previous implementation of the custom observable called dequeue:

As I was adding a test for the examples/rx3_buffer_example.py I noticed that the endless while-loop was actually never called, because observable.connect() seems to be a blocking operation, until the stream finishes with on_error or on_complete.

To make this example testable, I changed the dequeue() from using an endless while-loop to emitting a list of items. The changes can bee seen in this commit.

In addition, I made a small change to the capture_stdout_as_list context-manager: I renamed the to_string()-method to __str__(), so that the context-manager’s result can be used in the test assertions using str(result) instead of result.to_string(). It does look a little nicer, and I guess that this could be called “more pythonic”.

Since I went through the effort of publishing my rxpy3-examples repository on GitHub, I thought it’s time to add tests.

I had already taken a look at the test-suite for the rxpy-library, thinking that I might get some inspiration from that. But looking at their code I quickly found that it is way too complicated to be helpful to a rxpy-beginner like myself. They have created their own DSL for test, which is fine if you work a project over long period of time. But if you want to learn how to use the library as a beginner – like myself – then that is an additional barrier to entry.

👉 I created a github-repository with this and other rxpy (version 3) examples. You can find it at rxpy3-examples on github.

When I first looked at the different buffer-operators, I was very surprised to find that none of seemed to provide a simple rolling (aka sliding) buffer. This seemed like something that is so basic that it should be part of the core library.

It turns out, I was just not reading the documentation close enough: buffer_with_count(count=buffer_size, skip=1) will give you a rolling buffer of size buffer_size.

I created a github-repository with the two rxpy3 examples from my previous blog-posts. You can find it at rxpy3-examples on github.

Postgres’ built-in pg_stat_activity-view shows the list of all open connections, including the current query from that connection in the query-column. What if that is not enough? How can you see not only the current query, but a list of recent queries?

That is what the pg_stat_statements extension is for.

Enabling the pg_stat_statements-extension

Unlike pg_stat_activity, which is active by default, pg_stat_statements needs to be enabled on the postgres server. There are two steps: